“quét chỉ mục” để xử lý truy vấn. Điều đó có nghĩa nó phải đọc lần lượt toàn bộ chỉ mục trước khi có thể hoàn thành yêu cầu truy vấn và trả về bản ghi chứa một giá trị SalesOrderID. Ngược lại, phiên bản V2 của SP lưu trữ đa năng có thể sử dụng thao tác “tìm kiếm chỉ mục” với khóa chỉ mục cụm trên bảng SalesOrderDetail để lấy trực tiếp những bản ghi nhất định có chứa SalesOrderID bằng 43659 một cách nhanh chóng. Thao tác “tìm kiếm chỉ mục” tối ưu hơn thao tác “quét chỉ mục” rất nhiều, nhưng cụ thể nhiều như thế nào? Việc đánh giá khoản I/O tiết kiệm được nhờ dùng phiên bản SP lưu trữ đa năng V2 có thể thực hiện bằng nhiều cách. Ta sẽ chạy đoạn T-SQL sau đây: SET STATISTICS IO ON GO EXEC JackOfAllTrades @SalesOrderID = 43659 GO EXEC JackOfAllTrades_V2 @SalesOrderID = 43659 GO Ở đây tôi sử dụng lệnh “SET STATISTICS IO ON” nên kết quả của 2 SP đang thực thi sẽ hiển thị số lượng I/O mỗi lệnh đòi hỏi để xử lý truy vấn. Dưới đây là kết quả nhận được: (12 row(s) affected) Table 'SalesOrderDetail'. Scan count 1, logical reads 264, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. (1 row(s) affected) (12 row(s) affected) Table 'SalesOrderDetail'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. (1 row(s) affected) Khi nhìn kết quả trên, ta có thể thấy hiệu suất của SP lưu trữ đa năng đầu tiên là 1 lần quét và 264 lần đọc logic. Ngược lại phiên bản V2 có cùng số lần quét chỉ mục nhưng chỉ cần thực hiện 3 lần đọc logic để xử lý truy vấn. Khoản I/O tiết kiệm đc là 261. Con số này có vẻ không thấm tháp gì, tuy nhiên với trường hợp bạn phải gọi đi gọi lại SP trong một vòng lặp nào đó chẳng hạn, hiệu suất sẽ được cải thiện một cách rõ rệt giữa hai phiên bản SP. Cải thiện lượng I/O nhờ sử dụng SQL động được thông số hóa Sau khi đọc hết phần này, bạn cần hiểu được lý do vì sao máy chủ SQL lại đưa ra bản sơ đồ thực thi kém hiệu quả. Trên đây máy chủ SQL đã coi logic “@PARM IS NULL” như một hằng số. Bởi vậy nó quyết định cần phải thực hiện thao tác “quét chỉ mục” để xử lý phiên bản thủ tục lưu trữ đa năng đầu tiên. Như chúng ta đã biết, thao tác quét (SCAN) luôn chậm hơn thao tác tìm kiếm (SEEK). Bằng cách viết lại phiên bản SP lưu trữ đa năng V2 có sử dụng T- SQL động, tôi đã loại bỏ được biểu thức hằng số trong mệnh đề WHERE của câu lệnh T-SQL. Nhờ vậy máy chủ SQL đã tìm được phương pháp đúng đắn hơn đó là sử dụng thao tác “tìm kiếm chỉ mục cụm”. Nếu trang web của bạn có sử dụng thủ tục lưu trữ đa năng, hãy thử viết lại nó bằng SQL động được thông số hóa và chờ xem hiệu suất sẽ được cải thiện thế nào. Trong phần ba này, bài viết sẽ giới thiệu cho bạn cách viết câu lệnh T-SQL để đẩy mạnh việc tái sử dụng sơ đồ lưu cache (bộ nhớ đệm). Hiểu rõ vấn đề các khoảng trắng và ghi chú tác động thế nào tới việc tạo sơ đồ mới lưu cache hay tái sử dụng sơ đồ sẵn có sẽ giúp bạn giảm thiểu số lượng sơ đồ mà ứng dụng của bạn phải lưu cache. Khám phá sơ đồ lưu bộ nhớ đệm Bạn đã tận dụng được lợi thế từ việc lưu sơ đồ trên bộ nhớ đệm chưa? Bạn đã khai thác các sơ đồ lưu cache đến mức nào? Ứng dụng của bạn chỉ sử dụng chúng một lần hay tận dụng nhiều lần? Bạn có nhiều sơ đồ lưu cache cho cùng một truy vấn trong cache . năng, hãy thử viết lại nó bằng SQL động được thông số hóa và chờ xem hiệu suất sẽ được cải thiện thế nào. Trong phần ba này, bài viết sẽ giới thiệu cho bạn cách viết câu lệnh T-SQL để đẩy. tác tìm kiếm (SEEK). Bằng cách viết lại phiên bản SP lưu trữ đa năng V2 có sử dụng T- SQL động, tôi đã loại bỏ được biểu thức hằng số trong mệnh đề WHERE của câu lệnh T-SQL. Nhờ vậy máy chủ. JackOfAllTrades_V2 @SalesOrderID = 43659 GO Ở đây tôi sử dụng lệnh “SET STATISTICS IO ON” nên kết quả của 2 SP đang thực thi sẽ hiển thị số lượng I/O mỗi lệnh đòi hỏi để xử lý truy vấn. Dưới đây là kết