Hiệu năng ứng dụng phụ thuộc vào rất nhiều yếu tố, trong đó có một yếu tố rất quan trọng đó là thời gian để máy chủ SQL xử lý câu lệnh T-SQL. Đôi khi thiết kế cơ sở dữ liệu và các yêu cầu truy vấn phức tạp làm cản trở tốc độ thực thi của các câu lệnh T-SQL.
Cách viết code từng câu lệnh T-SQL cũng có thể khiến máy chủ SQL phải làm việc nhiều hơn để xử lý truy vấn. Bài viết sau đây sẽ giới thiệu cho bạn những thói quen tốt nên tập luyện khi viết code T-SQL. Qua đó bạn có thể hiểu làm thế nào để viết các câu truy vấn tối ưu, tận dụng tốt tài nguyên máy chủ SQL và cải thiện hiệu suất.
Ghi rõ tên cột trong câu lệnh SELECT
SELECT * FROM MyTable;
Bạn đã từng viết câu lệnh như trên bao nhiêu lần?
Việc sử dụng dấu sao (*) cho cơ sở dữ liệu biết rằng bạn muốn trả về tất cả các cột từ bảng (hoặc các bảng) được khai báo trong mệnh đề FROM. Đây không phải là một thói quen tốt ngay cả khi bạn muốn tất cả các cột được trả về ứng dụng. Tốt hơn bạn nên ghi rõ tên từng cột trong bảng như sau:
SELECT ID, Description, DateModified FROM MyTable;
Việc khai báo rõ ràng tên các cột trong câu lệnh SELECT mang lại rất nhiều lợi ích. Thứ nhất, máy chủ SQL sẽ chỉ trả về dữ liệu cần thiết cho ứng dụng chứ không phải là một đống dữ liệu mà trong đó có nhiều thứ ứng dụng của bạn không hề cần đến. Bằng cách chỉ yêu cầu trả về những dữ liệu cần thiết, bạn đã góp phần tối ưu hóa khối lượng công việc máy chủ SQL cần thực hiện để thu thập tất cả các cột của thông tin bạn yêu cầu. Ngoài ra, nhờ không sử dụng dấu sao (*) nên bạn đã giảm thiểu lưu lượng truyền tải qua mạng (số byte) cần thiết để gửi các dữ liệu liên quan đến câu lệnh SELECT tới ứng dụng.
Trong trường hợp bạn dùng dấu sao (*) và có một ai đó thêm cột mới vào bảng, ứng dụng của bạn sẽ bắt đầu tiếp nhận dữ liệu cho cột này mà không thay đổi mã nguồn ứng dụng. Nếu ứng dụng của bạn chờ đợi số lượng cột nhất định được trả về, nó sẽ bị lỗi ngay khi có người bổ sung cột mới vào một trong các bảng tham chiếu. Bằng việc khai báo rõ ràng tên từng cột trong câu lệnh SELECT, ứng dụng sẽ luôn nhận được số lượng cố định các cột trả về, ngay cả khi có người thêm cột mới vào các bảng tham chiếu trong câu lệnh SELECT. Nhờ vậy, bạn đã giúp ứng dụng tránh khỏi những nguy cơ tiềm tàng liên quan đến các thay đổi cơ sở dữ liệu có thể xảy đến với bất kỳ bảng nào bạn tham chiếu tới trong câu lệnh SELECT.
Ghi rõ tên cột trong câu lệnh INSERT
Cũng giống như trên, bạn nên chỉ rõ tên từng cột bạn muốn chèn dữ liệu vào trong câu lệnh INSERT. Đừng viết câu lệnh INSERT như sau:
INSERT INTO MyTable VALUES (‘A’,’B’,’C’);
Khi bạn viết kiểu này, máy chủ SQL đòi hỏi chỉ đúng ba cột được định nghĩa trong bảng MyTable, và giá trị “A” sẽ được chèn vào cột đầu tiên, “B” vào cột thứ hai, “C” vào cột cuối. Nếu ai đó thêm mới một cột vào bảng MyTable, ứng dụng của bạn sẽ bị lỗi:
Msg 213, Level 16, State 1, Line 1
Column name or number of supplied values does not match table definition.
(Tên cột hoặc số lượng giá trị không khớp với bảng)
Vì thế, thay vì viết câu lệnh INSERT như trên, bạn nên viết như sau:
INSERT INTO MyTable(So1, So2, So3) VALUES (‘A’,’B’,’C’);
Bằng cách viết trên, khi ai đó thêm mới một cột tên là “So4” vào bảng MyTable, câu lệnh INSERT vẫn tiếp tục làm việc với điều kiện cột “So4” được tạo với giá trị mặc định DEFAULT hoặc cho phép NULL.
Thêm tiền tố cho wildcard để tăng tốc tìm kiếm
Sử dụng các ký tự thay thế (wildcard) thích hợp có thể cải thiện hiệu suất câu truy vấn. Chẳng hạn bạn muốn tìm kiếm trong bảng AdventureWorks.Person.Contact tất cả LastNames kết thúc bằng “sen”. Giả dụ rằng bạn đã xây dựng một chỉ mục trên cột LastName. Nếu bạn viết câu lệnh tìm kiếm như sau:
SELECT Distinct LastName
FROM Person.Contact
WHERE LastName LIKE ‘%sen’
Câu lệnh sử dụng ký tự phần trăm (%) để thay thế cho không hoặc nhiều ký tự được theo sau bởi chuỗi “sen” trong trường LastName. Điều này khiến máy chủ SQL thực hiện thao tác quét chỉ mục nhằm tìm kiếm tất cả các tên kết thúc bằng “sen” để giải quyết câu truy vấn. Việc này rất có ý nghĩa bởi cho đến khi toàn bộ bảng được quét, máy chủ SQL không thể đảm bảo rằng đã tìm ra toàn bộ các bản ghi có LastName kết thúc bằng “sen”.
Ngoài ra, nếu bạn đang tìm kiếm các bản ghi có LastName dài đúng sáu ký tự và kết thúc bằng “sen”, bạn có thể viết câu lệnh tìm kiếm như sau:
SELECT Distinct LastName
FROM Person.Contact
WHERE LastName LIKE ‘___sen’
Ở đây, câu lệnh sử dụng ký tự gạch dưới (_) để thay thế cho một ký tự đơn. Ví dụ này tương tự với ví dụ ở phần trên và sử dụng thao tác quét chỉ mục để giải quyết. Một lần nữa, máy chủ SQL biết rằng cần phải quét toàn bộ chỉ mục trước khi đảm bảo đã tìm thấy tất cả các tên dài sáu ký tự và kết thúc bằng “sen” trong bảng Person.Contact.
Máy chủ SQL có thể trả về kết quả nhanh hơn nếu nó không phải đọc toàn bộ chỉ mục bằng cách sử dụng cơ chế quét. Máy chủ SQL đủ thông minh để nhận biết khi bạn đặt thêm tiền tố trước ký tự thay thế (%, _, v.v..), nó có thể dùng một thao tác tìm kiếm chỉ mục để tiến hành giải quyết tiêu chí tìm kiếm. Sau đây là một ví dụ về câu lệnh tìm kiếm yêu cầu trả về tất cả bản ghi có LastName bắt đầu bằng ký tự “A” và kết thúc bằng “sen”:
SELECT Distinct LastName
FROM Person.Contact
WHERE LastName LIKE ‘A%sen’
Bằng cách đặt ký tự “A” phía trước dấu phần trăm (%) trong câu lệnh tìm kiếm, bạn đã cho máy chủ SQL biết rằng nó có thể sử dụng một thao tác tìm kiếm chỉ mục để giải quyết câu truy vấn. Một khi máy chủ SQL đọc tới bản ghi cuối cùng có LastName bắt đầu bằng ký tự “A”, nó biết rằng không còn bản ghi nào có LastName bắt đầu bằng ký tự “A” nữa và sẽ dừng lại.
Không phải tất cả ký tự thay thế đều cần thêm tiền tố để máy chủ SQL dùng một thao tác tìm kiếm chỉ mục nhằm giải quyết truy vấn. Sau đây là một ví dụ trong đó câu lệnh sử dụng biểu thức thể hiện một tập hợp ký tự thay thế và vẫn cho phép máy chủ SQL giải quyết câu truy vấn bằng cách dùng một thao tác tìm kiếm chỉ mục:
SELECT Distinct LastName
FROM Person.Contact
WHERE LastName LIKE ‘[A-M]%sen’
Câu lệnh T-SQL trên tìm kiếm toàn bộ LastName bắt đầu bằng một ký tự bất kỳ trong khoảng từ “A” đến “M” và kết thúc bằng “sen”. Các cú pháp sử dụng ký tự thay thế khác trong đó chỉ rõ tập hợp các ký tự cũng có thể gọi thao tác quét chỉ mục để giải quyết tiêu chí tìm kiếm.
Chỉ dùng DISTINCT khi cần
Đặt từ khóa DISTINCT trong câu lệnh SELECT sẽ loại bỏ các kết quả trùng lặp trong số những kết quả trả về của câu truy vấn. Nó khiến máy chủ SQL phải thực hiện thêm thao tác SORT để sắp xếp dữ liệu nhằm nhận biết và loại bỏ các bản trùng lặp. Vì thế, nếu bạn biết trước các kết quả trả về sẽ không trùng lặp thì không nên dùng từ khóa DISTINCT trong câu lệnh T-SQL. Với việc sử dụng từ khóa DISTINCT trong câu truy vấn, bạn đã yêu cầu máy chủ SQL thực hiện thao tác sắp xếp vào loại bỏ các kết quả trùng lặp. Đây là phần công việc phụ thêm của máy chủ SQL và không có ý nghĩa gì nếu tập hợp kết quả của bạn chỉ bao gồm những bản ghi độc nhất.
Chỉ dùng UNION khi cần
Cũng giống như trường hợp từ khóa DISTINCT, toán tử UNION đòi hỏi thêm thao tác SORT để máy chủ SQL có thể loại bỏ những kết quả trùng lặp. Nếu bạn biết trước danh sách kết quả trả về không có kết quả nào giống nhau thì thao tác sắp xếp mà máy chủ SQL phải thực hiện trở nên không cần thiết. Bởi vậy khi bạn cần dùng toán tử UNION để nối hai tập hợp bản ghi với nhau, trong đó các bản ghi là độc nhất không trùng lặp, tốt hơn bạn nên dùng toán tử UNION ALL. Toán tử UNION ALL không loại bỏ các bản ghi trùng lặp bởi vậy sẽ giảm nhẹ phần công việc cho máy chủ SQL trong quá trình xử lý do không phải thực hiện thao tác sắp xếp. Giảm bớt công việc cho máy chủ SQL đồng nghĩa với việc thao tác xử lý sẽ được thực hiện nhanh hơn.
Áp dụng các thói quen tốt để code nhanh hơn
Có rất nhiều lý do để tập luyện cho mình quen với lối viết code tối ưu. Khi bạn áp dụng thành thạo những thủ thuật nhỏ nêu trên và biến nó thành thói quen mỗi khi viết câu lệnh T-SQL, bạn sẽ tránh được rủi ro có thể xảy ra khi cơ sở dữ liệu thay đổi, đồng thời cải thiện hiệu suất làm việc của máy chủ nhờ giảm thiểu lưu lượng truyền tải qua mạng. Những thủ thuật rất đơn giản này còn giúp bạn tận dụng tốt hơn tài nguyên máy chủ trong quá trình xử lý câu lệnh.
Thủ tục lưu trữ đa năng
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.
