Tải bản đầy đủ (.pdf) (5 trang)

Những thói quen tốt khi viết câu lệnh T-SQL (Phần 3) docx

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 (168.89 KB, 5 trang )

Những thói quen tốt khi viết câu lệnh T-SQL (Phần 3)

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 thủ tục cùng lúc không?
Khoảng trống các sơ đồ lưu cache sử dụng là bao nhiêu? Trên đây là một
số câu hỏi bạn cần trả lời để chắc rằng bạn đã tối ưu hóa cache thủ tục và
giảm thiểu số lượng sơ đồ lưu cache mà ứng dụng tạo ra. Có một vài vấn
đề nhỏ trong cách viết câu lệnh T-SQL của bạn là nguyên nhân khiến
máy chủ SQL phải thực hiện thêm nhiều việc để biên dịch và lưu cache
các sơ đồ thực thi cho cùng một đoạn code.
Trước khi máy chủ SQL có thể tiến hành xử lý đoạn code T-SQL, nó cần
tạo một bản sơ đồ thực thi. Để tạo bản sơ đồ thực thi, trước tiên máy chủ
SQL phải tiêu tốn những nguồn tài nguyên giá trị như CPU nhằm biên
dịch code T-SQL. Khi sơ đồ được tạo xong, nó sẽ được lưu cache để có
thể tái sử dụng khi ứng dụng gọi cùng một câu lệnh T-SQL nhiều hơn
một lần. Bạn có thể cải thiện hiệu suất máy chủ SQL nếu bạn viết câu
lệnh T-SQL để tăng cường tái sử dụng sơ đồ lưu cache với những đoạn T-
SQL thường xuyên được thực thi.
Với sự xuất hiện của SQL Server 2005, Microsoft cung cấp các DMV
(Dynamic Management Views - Cửa sổ quản lý động) cho phép bạn
khám phá các sơ đồ lưu. Bằng cách sử dụng các DMV, bạn có thể tìm
hiểu được nhiều điều về các sơ đồ lưu cache. Sau đây là danh sách tóm tắt
những thứ bạn có thể nhận biết:


 Các đoạn text liên quan tới sơ đồ lưu cache
 Số lần sơ đồ lưu cache được thực thi
 Kích cỡ sơ đồ lưu cache
Ở đoạn sau của bài viết, tôi sẽ hướng dẫn các bạn cách sử dụng DMV để
tìm hiểu thông tin sơ đồ lưu cache.
Tạo nhiều sơ đồ vì các ghi chú hoặc khoảng trắng thừa
Tôi chắc rằng các bạn đều ủng hộ ý tưởng đặt code vào các thủ tục lưu trữ
(Stored Procedure - SP). Chúng ta thực hiện việc này nhằm tăng khả năng
tái sử dụng code trong khuôn khổ một ứng dụng đơn lẻ hoặc trên nhiều
ứng dụng. Tuy nhiên, không phải tất cả các đoạn code được thực thi bởi
máy chủ SQL đều nằm trong các SP. Vài ứng dụng có thể được viết bằng
các lệnh T-SQL dạng in-line (lệnh thô). Nếu bạn đang viết các đoạn mã
T-SQL dạng thô, bạn cần phải cẩn thận khi ghi chú hoặc đặt khoảng trắng
bởi nó có thể là nguyên nhân khiến máy chủ SQL tạo nhiều sơ đồ lưu
cache cho cùng một đoạn code T-SQL.
Sau đây là một ví dụ gồm hai câu lệnh T-SQL khác nhau:
SELECT * FROM AdventureWorks.Production.Product
GO
SELECT * FROM AdventureWorks.Production.Product -
- return records
GO
Như bạn thấy, tôi có hai câu lệnh T-SQL giống nhau. Cả hai đều trả về tất
cả bản ghi từ bảng AdventureWorks.Production.Product. Vậy bạn nghĩ
máy chủ SQL sẽ tạo ra bao nhiêu sơ đồ lưu cache khi chạy đoạn mã trên?
Để trả lời câu hỏi này, tôi sẽ tìm hiểu thông tin sơ đồ lưu cache bằng cách
sử dụng các DMV trong SQL Server 2005 và SQL Server 2008. Để xem
các sơ đồ tạo bởi hai câu lệnh T-SQL trên, tôi sẽ chạy đoạn code sau:
DBCC FREEPROCCACHE
GO
SELECT * FROM AdventureWorks.Production.Product

GO
SELECT * FROM AdventureWorks.Production.Product -
- return records
GO
SELECT stats.execution_count AS exec_count,
p.size_in_bytes as [size],
[sql].[text] as [plan_text]
FROM sys.dm_exec_cached_plans p
outer apply sys.dm_exec_sql_text (p.plan_handle)
sql
join sys.dm_exec_query_stats stats ON
stats.plan_handle = p.plan_handle
GO
Trong đoạn code trên, trước tiên tôi giải phóng cache thủ tục bằng cách
chạy lệnh DBCC FREEPROCCACHE. Lệnh này xóa bỏ toàn bộ sơ đồ
thực thi trong bộ nhớ. Tuy nhiên tôi cũng xin có lời lưu ý rằng bạn không
nên sử dụng lệnh này khi làm việc trong doanh nghiệp bởi nó sẽ xóa bỏ
toàn bộ sơ đồ lưu cache. Điều này có thể gây ra những tác động to lớn tới
công việc của bạn do những sơ đồ thường dùng đều bị biên dịch lại. Sau
khi giải phóng cache thủ tục, tôi chạy tiếp hai câu lệnh SELECT khác
nhau. Cuối cùng, tôi liên kết thông tin từ các DMV lại để trả về thông tin
sơ đồ lưu cache của hai câu lệnh SELECT. Sau đây là kết quả nhận được
khi chạy đoạn code trên:
exec_count size plan_text

1 40960 SELECT * FROM
AdventureWorks.Production.Product return
records
1 40960 SELECT * FROM
AdventureWorks.Production.Product

Như bạn thấy, hai câu lệnh SELECT trên tạo ra hai sơ đồ lưu cache khác
nhau và mỗi sơ đồ được thực thi 1 lần (exec_count number). Sở dĩ
chuyện này xảy ra là vì hai câu lệnh SELECT không hoàn toàn giống
nhau. Câu lệnh SELECT thứ hai hơi khác một chút vì có thêm ghi chú.
Ngoài ra, các bạn hãy để ý kích cỡ sơ đồ: 40960 byte - kích cỡ bộ nhớ
quá lớn dành cho một câu lệnh T-SQL rất đơn giản. Vì thế, bạn nên cẩn
thận khi thêm ghi chú vào code, tránh để máy chủ tạo ra nhiều sơ đồ thừa.
Một nguyên nhân khác dẫn đến việc tạo ra nhiều sơ đồ lưu cache cho
những câu lệnh T-SQL giống nhau đó là các khoảng trắng. Sau đây là hai
câu lệnh giống nhau ngoại trừ các khoảng trắng:
SELECT * FROM AdventureWorks.Production.Product
GO
SELECT * FROM
AdventureWorks.Production.Product
GO
Như bạn thấy, câu lệnh thứ hai có chứa vài khoảng trắng thừa giữa
FROM và tên đối tượng. Các khoảng trắng thừa này là nguyên nhân
khiến máy chủ SQL nghĩ rằng đây là hai câu lệnh khác nhau, từ đó dẫn
đến việc tạo ra hai sơ đồ lưu cache khác nhau cho hai câu lệnh. Trong
trường hợp này, hiển nhiên bạn dễ dàng nhận ra sự khác biệt giữa hai câu
lệnh bởi lẽ các khoảng trắng nằm ở giữa câu lệnh. Thế nhưng nếu bạn vô
tình thêm khoảng trắng phía trước mệnh đề SELECT hoặc phía cuối câu
lệnh, bạn sẽ không thể nhận ra các khoảng trắng và câu lệnh sẽ trông
giống hệt nhau. Tuy nhiên, máy chủ SQL thì có thể nhìn thấy, và thế là
nó tạo ra nhiều sơ đồ lưu cache vì các khoảng trắng thừa đó.
Khi máy chủ SQL nhìn vào đoạn code, nó sẽ đem so sánh với các sơ đồ
sẵn có trong cache thủ tục. Nếu xác định đoạn code giống hệt sơ đồ lưu
cache sẵn có, máy chủ SQL không cần biên dịch và lưu sơ đồ vào bộ nhớ
nữa. Máy chủ SQL sẽ tái sử dụng các sơ đồ có trong cache đối với những
đoạn code giống nhau. Để tối ưu hóa mã nguồn, bạn cần đảm bảo việc tái

sử dụng sơ đồ lưu cache bất cứ khi nào có thể.

Khi bạn đang xây dựng mã nguồn ứng dụng trong đó có sử dụng các câu
lệnh T-SQL mà không dùng SP, bạn cần phải cẩn trọng để đảm bảo nhận
được sơ đồ có khả năng tái sử dụng cao nhất có thể. Chúng ta thường
dùng phương pháp copy - paste khi muốn sử dụng cùng một đoạn code
trong các phần khác nhau của ứng dụng. Tuy nhiên như bạn thấy trong
các ví dụ trên, bạn cần cẩn thận khi thực hiện thao tác này. Chỉ cần một
vài khoảng trắng thừa hoặc một ghi chú nhỏ cũng khiến máy chủ SQL tạo
ra nhiều sơ đồ lưu cache khác nhau.
Nâng hiệu suất lên tối đa và giảm thiểu bộ nhớ
Để tối ưu hóa mã nguồn, nếu chỉ quan tâm đến thiết kế cơ sở dữ liệu thôi
thì chưa đủ, bạn còn cần để ý đến từng chi tiết nhỏ hơn chẳng hạn như
các khoảng trắng và ghi chú. Nếu bạn không lưu tâm đến những chi tiết
quanh các câu lệnh T-SQL giống nhau, bạn có thể khiến máy chủ SQL
tạo ra nhiều sơ đồ lưu cache. Có thể việc có vài sơ đồ lưu cache thừa
trong bộ nhớ không phải quá quan trọng, tuy nhiên là một lập trình viên,
chúng ta cần cố gắng hết khả năng để nâng cao hiệu suất máy chủ và
giảm thiểu tài nguyên sử dụng. Và một trong những cách để thực hiện
mục tiêu trên, đó là tránh tạo ra nhiều sơ đồ lưu cache cho các câu lệnh T-
SQL giống nhau.

×