Những bí kíp tối ưu SQL Server – trải nghiệm từ thực tế

Tối ưu hóa Cơ sở dữ liệu là một công việc thật sự thử thách, nhất là khi bạn làm việc trên các CSDL có quy mô đủ lớn. Lúc này ngoài yêu cầu về tính đúng đắn thì bài toán hiệu suất, thời gian thực thi của ứng dụng là rất quan trọng. Bạn không thể nói người dùng là do dữ liệu lớn nên họ buộc phải chờ, bạn phải có phương án xử lý. Bạn sẽ thấy mình không thể cứ nâng cấp CPU, RAM, đĩa cứng,… là giải quyết được tất cả mà đôi lúc chỉ cần thực hiện một số thay đổi nhỏ trong thuật giải, cách xử lý đọc-ghi-tính toán nhưng lại có tác động đáng kể đến hiệu suất, thời gian thực thi của hệ thống. Thường thì công việc này sẽ do các chuyên gia quản trị CSDL (DBA) thực hiện dựa trên quá trình kiểm soát vận hành của hệ thống CSDL. Tuy nhiên, bạn – developer cũng nên biết qua về những kiến thức này để có thể áp dụng một số kỹ thuật tối ưu hiệu suất CSDL ngay từ lúc phát triển ứng dụng, giúp ứng dụng xây dựng được hiệu quả hơn.

Chọn lựa và tối ưu hóa các chỉ mục (Index)

Chỉ mục (Index) thật sự là một cách tối ưu hóa CSDL hiệu quả nhưng lại thường bị developer bỏ qua trong quá trình xây dựng ứng dụng.
Index là bảng tra cứu đặc biệt chứa các con trỏ đến dữ liệu thật sự của bảng dữ liệu. Thông qua Index, hệ thống CSDL có thể tăng thời gian truy cập dữ liệu, tương tự như cách các bạn dùng mục lục trong một cuốn sách để có thể tra và tìm được nội dung cần nhanh hơn.
Trong một lần triển khai dự án xây dựng phần mềm quản lý đào tạo của một trường Đại học, chúng tôi đã cải tiến, tăng thời gian thực hiện in phiếu điểm của sinh viên từ 1 phút lên khoảng 2 giây chỉ bằng việc tạo thêm các chỉ mục cần thiết, ngoài chỉ mục mặc định mà hệ thống tạo ra dựa trên khai báo khóa chính của bảng dữ liệu. Bạn sẽ thấy trong các bài tập truy vấn CSDL, chỉ trong tích tắc bạn sẽ có kết quả ngay nên không quan tâm lắm đến điều này. Nhưng đó là trên dữ liệu chỉ chưa đến 100 dòng, còn trong thực tế, bảng dữ liệu với cả triệu mẫu tin thì tốc độ là vấn đề mà người dùng rất quan tâm.
Một số gợi ý sau giúp bạn cân nhắc khi quyết định tạo Index:
– Nếu các truy vấn của bạn có sử dụng mệnh đề JOIN dùng để kết khóa chính và khóa ngoại của 2 bảng. Mặc định hệ thống sẽ tạo chỉ mục trên khóa chính nhưng nếu chưa có, bạn nên tạo index trên cột khóa chính và khóa ngoại có tham gia vào mệnh đề JOIN để tăng tốc độ thực hiện các truy vấn kết JOIN này.
– Nếu các truy vấn WHERE thường xuyên xác định điều kiện lọc dữ liệu trên các cột nào, bạn nên tạo thêm index trên các cột đó. Ví dụ như với bài toán Quản lý sinh viên, bạn có thể tạo index trên cột Mã số sinh viên (09155666, 01657994) vì nhu cầu tra cứu điểm theo mã số SV là rất thường xuyên. Hay như bài toán quản lý đơn hàng thì bạn có thể tạo chỉ mục theo mã khách hàng vì khách hàng thường xuyên có nhu cầu tra cứu, kiểm tra đơn hàng theo mã khách hàng.
– Bạn cũng có thể cân nhắc tạo thêm index trên những cột hay được gom nhóm, sắp xếp trong các báo cáo, thống kê có tần suất sử dụng cao để tăng tốc độ thực hiện báo cáo.
 Tuy nhiên, bạn cũng nên lưu ý rằng nếu bảng của bạn thường xuyên có các thao tác cập nhật dữ liệu với cách lệnh và , thì Index sẽ làm tăng thời gian thực hiện các lệnh cập nhật dữ liệu. Lúc này, bạn sẽ phải cân nhắc sao cho tối ưu, không nên có quá nhiều Index trên bảng, còn nếu dữ liệu của bạn có tính ổn định cao, ít có thao tác cập nhật và thao tác đọc là chính thì bạn có thể dễ dàng tăng số lượng index.
Ngoài ra, để biết được cách SQL Server thực thi câu lệnh SQL như thế nào, chi tiết từng bước một, bạn có thể sử dụng công cụ Execution Plan. Bạn kích hoạt Excution Plan bằng cách nhấn Include Actual Execution Plan (CTRL + M) trong màn hình SQL Server Management Studio trước khi bạn chạy câu lệnh.
Quan sát kết quả thực hiện câu lệnh SQL với Excution Plan, bạn sẽ biết được ở mỗi bước hệ thống thực hiện lấy dữ liệu bằng cách sử dụng hay không sử dụng Index, thời gian thực hiện truy vấn nhiều nhất là ở bước nào để từ đó có cải tiến Index cho phù hợp.

Tránh các truy vấn tương quan (correlated subquery) 

Truy vấn tương quan là dạng truy vấn con trong đó có sử dụng các giá trị từ các truy vấn cha. Ví dụ như:
 Đây là loại truy vấn có xu hướng chạy từng dòng một, tức là cứ mỗi hàng được trả về bởi các truy vấn bên ngoài và truy vấn con sẽ thực hiện, và do đó làm giảm hiệu suất truy vấn SQL. Có nhiều developer lựa chọn cách viết này vì dễ viết.
Bạn sẽ thấy truy vấn con được gọi nhiều lần, tương ứng với số dòng kết quả của truy vấn cha và đó là lý do mà tốc độ thực hiện truy vấn khá chậm. Bạn có thể hoàn toàn có cách viết khác thông qua  JOIN cho kết quả đúng như vậy nhưng hiệu suất được cải tiến lên rất nhiều.
Lúc này, bảng Cong_ty chỉ phải duyệt một lần, hiệu quả hơn rất nhiều, đặc biệt khi bạn thực hiện truy vấn trên bảng có dữ liệu lớn.

Chỉ chọn các cột dữ liệu cần thiết 

Một lời khuyên trong tối ưu hóa SQL đáng lưu ý nữa là bạn nên tránh lấy hết các cột của bảng với cú pháp SELECT.*. Bạn nên xác định rõ các cột nào bạn cần, chỉ lấy những dữ liệu nào bạn cần vì dữ liệu chính là tài nguyên, là bộ nhớ, là dung lượng trên đường truyền,… Bạn sẽ mất thời gian nếu lấy quá nhiều dữ liệu mà thật sự không cần thiết. Bạn sẽ thấy chẳng có vấn đề gì nếu là dữ liệu ít, nhưng hãy xem xét một bảng với hàng trăm cột và hàng triệu dòng dữ liệu. Bạn có thật sự cần hết tất cả với câu lệnh SELECT.*. Đó thật sự là một sự lãng phí lớn !

Nên sử dụng EXISTS() để kiểm tra truy vấn có trả về dữ liệu không?

Kỹ thuật tối ưu hóa SQL này liên quan đến việc sử dụng . Nếu bạn muốn kiểm tra xem kết quả truy vấn có dữ liệu theo điều kiện nào đó không, bạn nên sử dụng  thay cho . Lý do là vì khi bạn dùng , toàn bộ bảng dữ liệu sẽ được quét và đếm tất cả các dòng thỏa điều kiện bạn đưa vào. Trong khi đó, lệnh  sẽ thoát ngay khi nó thấy kết quả thỏa điều kiện. Như vậy, rõ ràng sử dụng lệnh    sẽ hiệu quả hơn nhiều so mà còn giúp cho mã lệnh của bạn cũng rõ ràng, dễ hiểu hơn.

Tránh dùng cursor khi cần xử lý từng dòng dữ liệu

Dữ liệu SQL trả về thường là tập hợp dữ liệu, gồm dòng và cột. Tuy nhiên, trong một số tình huống chúng ta cần xử lý dữ liệu từng dòng như trong bài toán xử lý số liệu nhập-xuất-tồn kho của hàng hóa (hàng có nhập – không xuất, có xuất – không nhập, hàng có tồn đầu kỳ nhưng không có nhập xuất trong kỳ) , bài toán tính đạt/không đạt trên phiếu điểm của sinh viên (tương ứng với mỗi môn học là quy tắc khác nhau),… Trong trường hợp đó, thông thường chúng ta có thể lựa chọn kiểu cursor để duyệt và xử lý từng dòng dữ liệu. Bạn sẽ thấy trên CSDL dữ liệu nhỏ, cùng một thời điểm không có nhiều người dùng cùng cập nhật trên bảng thì cursor làm rất tốt các xử lý này. Nhưng mọi chuyện sẽ khác khi dữ liệu đủ lớn và cần xử lý khóa tranh chấp vì lúc này cursor sẽ khóa dòng dữ liệu cho đến khi dòng đó được duyệt và xử lý xong. Ngoài ra, trong quá trình xử lý của cursor nếu có một xử lý khác muốn cập nhật bảng dữ liệu nguồn của cursor thì hệ thống sẽ báo lỗi.
Có nhiều cách để bạn có thể dùng thay thế cho cursor như dùng bảng tạm, kết hợp truy vấn UNION và truy vấn con, sử dụng truy vấn CASE,… Nhưng thực tế qua nhiều dự án cho thấy, chúng tôi nhận thấy bạn hoàn toàn có thể sử dụng bảng tạm thay thế cho cursor và đặc biệt bảng tạm giúp cho tốc độ xử lý được cải tiến đáng kể, đặc biệt khi làm việc trên CSDL đủ lớn.
Cám ơn các bạn đã quan tâm!
Những bí kíp tối ưu SQL Server – trải nghiệm từ thực tế
5 (100%) 10 votes

Nhận xét