Thật dễ dàng để bắt đầu mày mò với các công cụ tối ưu hóa truy vấn SQL. Bạn mở SQL Server Management Studio (SSMS), theo dõi thời gian chờ, xem xét kế hoạch thực thi, thu thập thông tin đối tượng và bắt đầu tối ưu hóa SQL cho đến khi bạn chạy một máy được tinh chỉnh.
Nếu bạn đủ giỏi, bạn sẽ giành được chiến thắng nhanh chóng và quay trở lại với sự hỗn loạn thường xuyên theo lịch trình của mình. Nhưng nếu bạn điều chỉnh điều sai hoặc điều chỉnh điều đúng theo hướng sai, thì ngày thứ Tư của bạn đã đến.
Tối ưu hóa truy vấn SQL? Điều gì khiến bạn nghĩ rằng bạn cần nó?
Hầu hết thời gian, đó là sự gia tăng đột biến về vé gặp sự cố hoặc khiếu nại của người dùng. "Tại sao hệ thống quá chậm?" người dùng của bạn phàn nàn. “Chúng tôi mất nhiều thời gian để chạy các báo cáo thông thường của chúng tôi trong tuần này.”
Tất nhiên, đó là một mô tả khá mơ hồ. Sẽ thật tuyệt nếu họ có thể nói với bạn rằng “Mọi thứ diễn ra chậm chạp vì bạn đã có một chuyển đổi ngầm trong dòng 62 của CurrentOrderQuery5.sql. Cột là varchar và bạn đang chuyển vào một số nguyên. ” Nhưng không có khả năng người dùng của bạn có thể nhìn thấy mức độ chi tiết đó.
Ít nhất các vé rắc rối và các cuộc gọi điện thoại tạo nên một thước đo hoạt động:dễ phát hiện, dễ đo lường. Khi họ bắt đầu tham gia, bạn có thể chắc chắn một cách hợp lý rằng đã đến lúc điều chỉnh SQL.
Nhưng có những thước đo thụ động khác khiến nhu cầu trở nên ít rõ ràng hơn. Những thứ như doanh số bán hàng sụt giảm, có thể là do bất kỳ yếu tố nào. Có phải vì các truy vấn chậm đến mức đáng tiếc trong cửa hàng trực tuyến của bạn đang khiến khách hàng từ bỏ giỏ hàng của họ không? Có phải vì nền kinh tế đang trong tình trạng tồi tệ?
Hoặc nó có thể là những thứ như hiệu suất SQL Server chậm chạp. Có phải vì một truy vấn được viết kém đang gửi các lần đọc logic qua mái nhà không? Có phải do máy chủ sử dụng ít tài nguyên vật lý như bộ nhớ và bộ nhớ không?
Trong cả hai trường hợp, tối ưu hóa truy vấn SQL có thể trợ giúp với tùy chọn đầu tiên, nhưng không giúp ích cho tùy chọn thứ hai.
Tại sao lại áp dụng giải pháp đúng cho vấn đề sai?
Trước khi bạn đi xuống con đường tối ưu hóa, hãy đảm bảo rằng việc điều chỉnh là giải pháp phù hợp cho đúng vấn đề.
Điều chỉnh SQL là một quy trình kỹ thuật, nhưng mọi bước kỹ thuật đều bắt nguồn từ ý nghĩa kinh doanh tốt. Bạn có thể dành nhiều ngày để cố gắng rút ngắn thời gian thực thi xuống một vài mili giây hoặc giảm số lần đọc logic xuống năm phần trăm, nhưng liệu việc giảm này có xứng đáng với thời gian của bạn không? Đúng là việc đáp ứng các yêu cầu của người dùng là điều quan trọng, nhưng mọi nỗ lực cuối cùng đều dẫn đến kết quả giảm dần.
Hãy xem xét các vấn đề về hiệu suất truy vấn SQL này và bối cảnh kinh doanh xung quanh chúng:
- Hiệu suất có thể chấp nhận được - Một truy vấn mất 10 phút để chạy và người dùng muốn nó chạy trong một phút; đó có vẻ như là một sự chênh lệch hợp lý và một mục tiêu có thể đạt được để tối ưu hóa. Tuy nhiên, nếu truy vấn diễn ra qua đêm và người dùng nghĩ rằng nó sẽ chạy sau một phút, thì đó có thể là vấn đề điều chỉnh. Thứ nhất, bạn có thể phải hướng dẫn người dùng về khối lượng công việc mà truy vấn đang thực sự thực hiện. Mặt khác, đó có thể là vấn đề với cách thiết kế cơ sở dữ liệu hoặc cách viết ứng dụng khách.
- Tiện ích - Giả sử bạn chịu trách nhiệm quản lý cơ sở dữ liệu tài chính trong một công ty sản xuất. Vào cuối mỗi tháng, người dùng phàn nàn về hiệu suất kém. Bạn theo dõi vấn đề với một loạt các báo cáo cuối tháng do Kế toán thực hiện, mỗi báo cáo mất hàng giờ đồng hồ và chuyển thẳng vào tủ hồ sơ mà không ai phát hiện ra. Thay vì điều chỉnh, bạn giải thích vấn đề với người quản lý doanh nghiệp và xin phép xóa báo cáo.
- Dịch chuyển thời gian - Hoặc, giả sử những báo cáo tương tự là quan trọng đối với quản trị nhưng không cấp thiết đối với doanh nghiệp. Nếu chúng được chạy một lần mỗi tuần hoặc mỗi tháng, chúng có thể được lên lịch vào giờ thấp điểm bằng cách lưu trước tập dữ liệu vào bộ nhớ đệm và gửi kết quả vào một tệp. Điều đó loại bỏ nút thắt cổ chai đối với những người dùng doanh nghiệp khác và giải phóng người dùng Kế toán khỏi phải đợi báo cáo.
Khi bạn đưa bối cảnh kinh doanh vào quyết định tối ưu hóa, bạn có thể đặt các mức độ ưu tiên và dành thời gian cho mình.
Khi bạn tối ưu hóa các truy vấn SQL, hãy thử lập sơ đồ SQL
SSMS và các công cụ được tích hợp trong SQL Server cung cấp hầu hết những gì bạn cần để tối ưu hóa truy vấn SQL hiệu quả. Kết hợp các công cụ với cách tiếp cận có phương pháp theo các bước sau, như được mô tả trong sách điện tử “Hướng dẫn cơ bản để tối ưu hóa truy vấn SQL “:
- Theo dõi thời gian chờ
- Xem lại Kế hoạch Thực thi
- Thu thập Thông tin Đối tượng
- Tìm Bàn Lái xe
- Xác định các chất kìm hãm hiệu suất
Trong bước 4, mục tiêu của bạn là thúc đẩy truy vấn với bảng trả về ít dữ liệu nhất. Khi bạn nghiên cứu các phép nối và vị từ, đồng thời lọc sớm hơn trong truy vấn hơn là sau đó, bạn sẽ giảm số lần đọc logic. Đó là một bước tiến lớn trong việc tối ưu hóa truy vấn SQL.
Sơ đồ SQL là một kỹ thuật đồ họa để ánh xạ lượng dữ liệu trong các bảng và tìm bộ lọc nào sẽ trả về ít bản ghi nhất. Đầu tiên, bạn xác định bảng nào chứa thông tin chi tiết và bảng nào là bảng chính hoặc bảng tra cứu. Hãy xem xét ví dụ đơn giản của truy vấn này với cơ sở dữ liệu đăng ký trường đại học:
Bảng chi tiết là đăng ký. Nó có hai bảng tra cứu, học sinh và lớp học. Để lập sơ đồ các bảng này, hãy vẽ một cây lộn ngược kết nối bảng chi tiết (ở trên cùng) bằng các mũi tên (hoặc liên kết) đến các bảng tra cứu, như sau:
Bây giờ, hãy tính toán số lượng bản ghi tương đối cần thiết cho tiêu chí kết hợp (nghĩa là, tỷ lệ trung bình của các hàng liên quan giữa bảng chi tiết và các bảng tra cứu). Viết các số ở mỗi đầu của mũi tên. Trong ví dụ này, đối với mỗi học sinh có khoảng 5 bản ghi trong bảng đăng ký và đối với mỗi lớp học có khoảng 30 bản ghi trong bảng đăng ký. Điều đó có nghĩa là không bao giờ cần phải THAM GIA hơn 150 bản ghi (5 × 30) để nhận được kết quả cho bất kỳ sinh viên đơn lẻ nào hoặc bất kỳ lớp học nào.
Bài tập đó hữu ích nếu các cột tham gia của bạn chưa được lập chỉ mục hoặc nếu bạn không chắc rằng chúng đã được lập chỉ mục.
Tiếp theo, hãy xem các vị từ lọc để tìm bảng cần thúc đẩy truy vấn. Truy vấn này có hai bộ lọc:một bộ lọc khi đăng ký bị hủy =‘N’ và bộ lọc kia vào ngày signup_date giữa hai ngày. Để xem bộ lọc được chọn lọc như thế nào, hãy chạy truy vấn này khi đăng ký:
chọn số lượng (1) từ đăng ký mà bị hủy =‘N’
VÀ r.signup_date GIỮA:be_date VÀ:ngày_căn_được +1
Nó trả về 4.344 hồ sơ trong tổng số 79.800 hồ sơ đăng ký. Tức là, 5,43 phần trăm bản ghi sẽ được đọc bằng bộ lọc đó.
Bộ lọc khác trên lớp:
chọn số lượng (1) từ lớp có name =‘ENGLISH 101’
Nó trả về hai bản ghi trong số 1.000, hoặc 0,2 phần trăm, đại diện cho một bộ lọc chọn lọc hơn nhiều. Do đó, lớp là bảng điều khiển và là bảng để tập trung điều chỉnh SQL của bạn trước tiên.
Giọng nói của người dùng
Nếu bạn chắc chắn mình cần điều chỉnh SQL, thì “Hướng dẫn cơ bản để tối ưu hóa truy vấn SQL” cung cấp thêm thông tin chi tiết. Nó sẽ hướng dẫn bạn năm mẹo điều chỉnh hiệu suất với các truy vấn sao chép và dán và nghiên cứu điển hình, bao gồm cả những nghiên cứu được mô tả ở trên.
Bạn có thể sẽ thấy rằng công cụ tối ưu hóa truy vấn SQL quan trọng nhất chính là tiếng nói của người dùng. Tại sao? Bởi vì giọng nói đó cho bạn biết khi nào nên bắt đầu tối ưu hóa và nó cho bạn biết khi nào bạn đã tối ưu hóa đủ. Nó có thể đảm bảo rằng bạn bắt đầu điều chỉnh các bánh răng khi bạn cần và dừng lại khi bạn vẫn đang ở phía trước.
