Những thói quen tốt khi viết câu lệnh T-SQL- P6 pptx
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (284.76 KB, 5 trang )
“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
