2011-12-21 40 views
8

Tôi có một dịch vụ web, do đó, trình xử lý được gọi nhiều lần đồng thời tất cả thời gian.hiệu suất kém với sqlparameter

Bên trong tôi tạo SqlConnection và SqlCommand. Tôi phải thực hiện khoảng 7 lệnh khác nhau. lệnh khác nhau đòi hỏi các thông số khác nhau, vì vậy tôi chỉ cần thêm chúng một lần:

command.Parameters.Add(new SqlParameter("@UserID", userID)); 
command.Parameters.Add(new SqlParameter("@AppID", appID)); 
command.Parameters.Add(new SqlParameter("@SID", SIDInt)); 
command.Parameters.Add(new SqlParameter("@Day", timestamp.Date)); 
command.Parameters.Add(new SqlParameter("@TS", timestamp)); 

Sau đó, trong quá trình thực tôi chỉ cần thay đổi CommandText prorerty và sau đó gọi ExecuteNonQuery(); hoặc ExecuteScalar();

Và tôi gặp vấn đề về hiệu suất. Ví dụ: các chương trình gỡ lỗi và lược tả nhỏ, lệnh đó

command.CommandText = "SELECT LastShowTS FROM LogForAllTime WHERE UserID = @UserID"; 

mất khoảng 50ms trong avarage. Nếu tôi thay đổi nó thành:

command.CommandText = "SELECT LastShowTS FROM LogForAllTime WHERE UserID = '" + userID.Replace("\'", "") + "'"; 

thì chỉ mất 1ms trong avarage!

Tôi không thể tìm được đầu mối để điều tra sự cố.

+1

Bạn có thể nêu rõ: loại 'userID' được định nghĩa trong C# là gì và loại xác định của cột' UserID' trong cơ sở dữ liệu là gì? –

+0

Bạn có chắc đây là nút cổ chai hiệu suất của bạn không? Bạn đã lược tả mọi thứ chưa? – asawyer

+0

userID là một chuỗi, trong DB nó là varchar (20) và là một PK –

Trả lời

13

Có vẻ như nó đã lưu trong bộ nhớ cache kế hoạch truy vấn cho giá trị @UserID không điển hình (một trong những giá trị đầu tiên) và đang sử dụng lại kế hoạch kém cho các truy vấn sau này. Đây không phải là một vấn đề trong trường hợp thứ hai kể từ khi mỗi có một kế hoạch riêng biệt. Tôi nghi ngờ bạn chỉ cần thêm:

OPTION (OPTIMIZE FOR UNKNOWN) 

vào truy vấn, điều này sẽ làm cho việc sử dụng lại kế hoạch trở nên ít quan tâm hơn.


lý thuyết thay thế:

Bạn có thể có sự không phù hợp giữa các loại userID (trong C#) và loại UserID (trong cơ sở dữ liệu). Điều này có thể đơn giản như unicode so với ANSI hoặc có thể là int vs varchar[n], v.v. Nếu nghi ngờ, hãy rất cụ thể khi định cấu hình tham số, để thêm nó với đúng loại và kích thước phụ.

Làm rõ

Trên thực tế, có vẻ như vấn đề ở đây là sự khác biệt giữa một C# string (unicode) và cơ sở dữ liệu đó là varchar(n) (ANSI). Do đó, SqlParameter nên được thêm một cách rõ ràng (DbType.AnsiString).

+0

Điều đó có thực sự tạo ra sự khác biệt cho mệnh đề đơn giản như vậy? – SLaks

+0

@SLaks nếu dữ liệu không đồng đều, có; hãy tưởng tượng: truy vấn đầu tiên chạy cho một người dùng mẫu không có (hoặc rất ít) dữ liệu - trình tối ưu hóa truy vấn sử dụng thống kê và quyết định về một kế hoạch truy vấn được tối ưu hóa cho số lượng hàng nhỏ. Điều này sau đó phát nổ rất nhiều khi phải đối mặt với 200k hàng. Tôi đã nhìn thấy những trường hợp tương tự, tuyệt đối. Cách duy nhất để tìm ra là thử mặc dù không có gợi ý, p –

+0

Vâng, đây là tính năng thú vị mà tôi chắc chắn sẽ điều tra chi tiết hơn. Liên kết tốt đẹp có tại đây http://blogs.msdn.com/b/sqlprogrammability/archive/2008/11/26/optimize-for-unknown-a-little-known-sql-server-2008-feature.aspx Vì vậy, Tôi đã thử: CHỌN LastShowTS TỪ LogForAllTime WHERE UserID = @UserID tùy chọn (OPTIMIZE FOR (@UserID UNKNOWN)) Không có hiệu lực ... –

0

Bạn đang gửi dữ liệu gấp bảy lần đến máy chủ, vì vậy dữ liệu sẽ chậm hơn.

Ngoài ra, nếu các chuỗi userID của bạn có độ dài khác nhau, việc đặt độ dài rõ ràng trong tham số SQL sẽ cho phép nó sử dụng lại truy vấn tốt hơn.

+0

Điều đó không tính toán; điều này sẽ chỉ áp dụng nếu các thông số là rất lớn và các vấn đề băng thông là nút cổ chai; Tôi rất nghi ngờ đây là trường hợp ở đây. Thời gian để gửi một vài thông số cơ bản là tầm thường, và bao la lớn hơn bởi độ trễ (thay vì băng thông) trong hầu hết các trường hợp. –

+0

@MarcGravell: Bạn đang giải quyết đoạn đầu tiên của tôi hay đoạn thứ hai của tôi? – SLaks

+0

Dòng đầu tiên - Tôi sẽ không nghĩ rằng để tính đến bước nhảy 50ms. Có lẽ độ lệch 0.1ms (giả sử không có giá trị lớn). –

Các vấn đề liên quan