Tối ưu hóa truy vấn trong SQL Server là gì? Đó là một chủ đề lớn. Mỗi kỹ thuật hoặc vấn đề cần một bài báo riêng để đề cập đến các cơ sở. Nhưng khi bạn mới bắt đầu nâng cấp trò chơi của mình bằng các truy vấn, bạn cần một thứ gì đó đơn giản hơn để dựa vào. Đây là mục tiêu của bài viết này.
Bạn có thể nói rằng các truy vấn của bạn là tối ưu, mọi thứ hoạt động tốt và người dùng hài lòng. Tất nhiên, hiệu suất không phải là tất cả. Kết quả cũng phải chính xác. Cho dù đó là một phép nối, một truy vấn con, một từ đồng nghĩa, một CTE, một lượt xem hay bất cứ thứ gì, nó phải hoạt động ở mức chấp nhận được.
Và vào cuối ngày, bạn có thể về nhà với người dùng của mình. Bạn không muốn ở lại văn phòng để sửa các truy vấn chạy chậm qua đêm.
Trước khi chúng ta bắt đầu, hãy để tôi đảm bảo với bạn rằng cuộc hành trình sẽ không khó khăn. Đây sẽ chỉ là một lớp sơn lót. Chúng tôi sẽ có những ví dụ không quá xa lạ với bạn. Cuối cùng, khi bạn đã sẵn sàng để nghiên cứu sâu hơn, chúng tôi sẽ giới thiệu một số liên kết mà bạn có thể kiểm tra.
Hãy bắt đầu.
1. Tối ưu hóa truy vấn SQL bắt đầu từ thiết kế và kiến trúc
Ngạc nhiên? Tối ưu hóa truy vấn SQL không phải là một suy nghĩ muộn màng hay một biện pháp hỗ trợ khi có điều gì đó bị hỏng. Truy vấn của bạn chạy nhanh như thiết kế của bạn cho phép. Chúng ta đang nói về các bảng chuẩn hóa, các loại dữ liệu phù hợp, việc sử dụng chỉ mục, lưu trữ dữ liệu cũ và bất kỳ phương pháp hay nhất nào mà bạn có thể nghĩ đến.
Một thiết kế cơ sở dữ liệu tốt hoạt động đồng bộ với phần cứng và cài đặt SQL Server phù hợp. Bạn đã thiết kế nó để chạy trơn tru trong vài năm và vẫn cảm thấy như mới? Đó là một giấc mơ lớn, nhưng chúng tôi chỉ có một khoảng thời gian nhất định (thường - ngắn) để nghĩ về nó.
Nó sẽ không hoàn hảo vào ngày đầu tiên trong quá trình sản xuất, nhưng chúng tôi lẽ ra phải đề cập đến các cơ sở. Chúng tôi sẽ giảm thiểu nợ kỹ thuật. Nếu bạn đang làm việc với một nhóm, điều đó thật tuyệt vời so với buổi biểu diễn một người. Bạn có thể bao gồm nhiều chuông và còi.
Tuy nhiên, điều gì sẽ xảy ra nếu cơ sở dữ liệu đang chạy trực tiếp và bạn gặp sự cố về hiệu suất? Dưới đây là một số mẹo và thủ thuật tối ưu hóa truy vấn SQL.
2. Truy vấn có vấn đề với báo cáo chuẩn của máy chủ SQL
Khi bạn đang viết mã, bạn có thể dễ dàng nhận ra một loạt mã dài hoặc một quy trình được lưu trữ. Bạn có thể gỡ lỗi từng dòng một. Dòng bị trễ là dòng cần khắc phục.
Nhưng điều gì sẽ xảy ra nếu bộ phận trợ giúp của bạn ném một tá vé vì quá chậm? Người dùng không thể xác định vị trí chính xác trong mã và bộ phận trợ giúp cũng không. Thời gian là kẻ thù tồi tệ nhất của bạn.
Một giải pháp không yêu cầu viết mã là kiểm tra các báo cáo tiêu chuẩn của Máy chủ SQL. Nhấp chuột phải vào máy chủ cần thiết trong SQL Server Management Studio > Báo cáo > Báo cáo Chuẩn . Điểm quan tâm của chúng tôi có thể là Trang tổng quan về hiệu suất hoặc Hiệu suất - Truy vấn hàng đầu theo Tổng số I / O . Chọn truy vấn đầu tiên hoạt động kém. Sau đó, bắt đầu tối ưu hóa truy vấn SQL hoặc điều chỉnh hiệu suất SQL từ đó.
3. Điều chỉnh truy vấn SQL với STATISTICS IO
Sau khi xác định chính xác truy vấn được đề cập, bạn có thể bắt đầu kiểm tra các lần đọc logic trong STATISTICS IO. Đây là một trong những công cụ tối ưu hóa truy vấn SQL.
Có một vài điểm I / O, nhưng bạn nên tập trung vào các bài đọc logic. Số lần đọc logic càng cao, hiệu suất truy vấn càng có vấn đề.
Bằng cách giảm 3 yếu tố sau, bạn có thể tăng tốc các truy vấn điều chỉnh hiệu suất trong SQL:
- lần đọc logic cao,
- lần đọc logic LOB cao,
- hoặc các lần đọc logic WorkTable / WorkFile cao.
Để nhận thông tin về các lần đọc logic, hãy bật STATISTICS IO trong cửa sổ truy vấn SQL Server Management Studio.
ĐẶT THỐNG KÊ IO ON
Bạn có thể lấy đầu ra trong tab Tin nhắn sau khi truy vấn xong. Hình 2 hiển thị kết quả đầu ra mẫu:
Tôi đã viết một bài báo riêng về việc giảm số lần đọc logic trong 3 Thống kê I / O Nasty làm Trễ Hiệu suất Truy vấn SQL. Hãy tham khảo nó để biết các bước chính xác và các mẫu mã với số lần đọc logic cao và các cách để giảm bớt chúng.
4. Điều chỉnh truy vấn SQL với kế hoạch thực thi
Chỉ đọc logic sẽ không cung cấp cho bạn bức tranh toàn cảnh. Chuỗi các bước được chọn bởi trình tối ưu hóa truy vấn sẽ kể câu chuyện về tập hợp kết quả của bạn. Tất cả bắt đầu như thế nào sau khi bạn thực hiện truy vấn?
Hình 3 dưới đây là sơ đồ những gì sẽ xảy ra sau khi bạn kích hoạt thực thi cho đến thời điểm bạn nhận được tập hợp kết quả.
Việc phân tích cú pháp và ràng buộc sẽ diễn ra trong nháy mắt. Phần tuyệt vời là giai đoạn tối ưu hóa, là trọng tâm của chúng tôi. Ở giai đoạn này, trình tối ưu hóa truy vấn đóng một vai trò quan trọng trong việc chọn kế hoạch thực thi tốt nhất có thể. Mặc dù phần này cần một số tài nguyên, nhưng nó tiết kiệm rất nhiều thời gian khi nó chọn một kế hoạch thực thi hiệu quả. Điều này xảy ra động, vì cơ sở dữ liệu thay đổi theo thời gian. Bằng cách này, người lập trình có thể tập trung vào cách tạo ra kết quả cuối cùng.
Mỗi kế hoạch mà trình tối ưu hóa truy vấn xem xét có chi phí truy vấn của nó. Trong số nhiều phương án, người tối ưu sẽ chọn phương án có chi phí hợp lý nhất. Lưu ý :Chi phí hợp lý không bằng chi phí ít nhất. Nó cũng cần phải xem xét kế hoạch nào sẽ tạo ra kết quả nhanh nhất. Kế hoạch với chi phí ít nhất không phải lúc nào cũng là kế hoạch nhanh nhất. Ví dụ:trình tối ưu hóa có thể chọn sử dụng một số lõi bộ xử lý. Chúng tôi gọi đây là thực thi song song. Điều này sẽ tiêu tốn nhiều tài nguyên hơn nhưng chạy nhanh hơn so với thực thi nối tiếp.
Một điểm cần xem xét là số liệu thống kê. Trình tối ưu hóa truy vấn dựa vào nó để tạo các kế hoạch thực thi. Nếu thống kê đã lỗi thời, đừng mong đợi quyết định tốt nhất từ trình tối ưu hóa truy vấn.
Khi kế hoạch được quyết định và tiến hành thực hiện, bạn sẽ thấy kết quả. Làm gì bây giờ?
Kiểm tra kế hoạch thực thi truy vấn trong SQL Server
Khi bạn tạo một truy vấn, bạn muốn xem kết quả trước tiên. Kết quả phải chính xác. Khi xong, bạn đã hoàn tất.
Có phải vậy không?
Nếu bạn đang thiếu thời gian và công việc đang bị đe dọa, bạn có thể đồng ý với điều đó. Bên cạnh đó, bạn luôn có thể quay lại. Tuy nhiên, nếu các vấn đề khác phát sinh, bạn có thể quên chúng đi nhiều lần. Và sau đó, bóng ma của quá khứ sẽ săn lùng bạn.
Bây giờ, điều tốt nhất nên làm sau khi nhận được kết quả chính xác là gì?
Kiểm tra Kế hoạch thực thi thực tế hoặc Thống kê truy vấn trực tiếp !
Cách sau là tốt nếu truy vấn của bạn chạy chậm và bạn muốn xem điều gì xảy ra mỗi giây khi các hàng được xử lý.
Đôi khi, tình huống sẽ buộc bạn phải kiểm tra kế hoạch ngay lập tức. Để bắt đầu, nhấn Control-M hoặc nhấp vào Bao gồm kế hoạch thực thi thực tế từ thanh công cụ của SQL Server Management Studio. Nếu bạn thích dbForge Studio cho SQL Server, hãy đi tới Hồ sơ truy vấn - nó cung cấp cùng một thông tin + một số chuông và còi mà bạn không thể tìm thấy trong SSMS.
Chúng tôi đã thấy Kế hoạch thực thi thực tế . Hãy tiếp tục.
Có Thiếu Chỉ mục hoặc Đề xuất Chỉ mục không?
Chỉ mục bị thiếu rất dễ phát hiện - bạn sẽ nhận được cảnh báo ngay lập tức.
Để nhận mã tức thì để tạo chỉ mục, hãy nhấp chuột phải vào Chỉ mục bị thiếu tin nhắn (hộp màu đỏ). Sau đó chọn Thiếu chi tiết chỉ mục . Một cửa sổ truy vấn mới với mã để tạo chỉ mục bị thiếu sẽ xuất hiện. Tạo chỉ mục.
Phần này rất dễ làm theo. Đó là một điểm khởi đầu tốt để đạt được tốc độ thực thi nhanh hơn. Nhưng trong một số trường hợp, sẽ không có tác dụng. Tại sao? Một số cột mà truy vấn của bạn cần không có trong chỉ mục. Do đó, nó sẽ hoàn nguyên về chế độ Quét chỉ mục theo cụm.
Bạn cần kiểm tra lại kế hoạch thực thi sau khi tạo chỉ mục để xem liệu các cột Bao gồm có cần thiết hay không. Sau đó, điều chỉnh chỉ mục cho phù hợp và chạy lại truy vấn của bạn. Sau đó, hãy kiểm tra lại kế hoạch thực thi.
Nhưng nếu không có chỉ mục nào bị thiếu thì sao?
Đọc Kế hoạch Thực thi
Bạn cần biết một số điều cơ bản để bắt đầu:
- Người điều hành
- Thuộc tính
- Hướng đọc
- Cảnh báo
NGƯỜI VẬN HÀNH
Trình tối ưu hóa truy vấn sử dụng một số loại chương trình nhỏ được gọi là toán tử. Bạn đã thấy một số trong số chúng trong Hình 4 - Tìm kiếm chỉ mục theo cụm , Quét chỉ mục theo cụm , Vòng lặp lồng nhau và Chọn .
Để có được danh sách đầy đủ với tên, biểu tượng và mô tả, bạn có thể kiểm tra tài liệu tham khảo này từ Microsoft.
TÍNH CHẤT
Sơ đồ đồ họa không đủ để hiểu những gì đang xảy ra đằng sau hậu trường. Bạn cần tìm hiểu sâu hơn về các thuộc tính của từng toán tử. Ví dụ: Quét chỉ mục theo cụm trong Hình 4 có các Thuộc tính sau:
Nếu bạn kiểm tra kỹ, hãy Quét chỉ mục theo cụm nhà điều hành là khủng khiếp. Như Hình 5 cho thấy, nó đọc 31.465 hàng, nhưng tập hợp kết quả cuối cùng chỉ là 5 hàng. Đó là lý do tại sao có một đề xuất chỉ mục trong Hình 4 để giảm số lượng hàng được đọc. Số lần đọc hợp lý của truy vấn cũng cao và điều này giải thích tại sao.
Để biết thêm về các thuộc tính này, hãy xem danh sách các thuộc tính toán tử phổ biến và thuộc tính kế hoạch.
HƯỚNG DẪN ĐỌC
Nói chung, nó giống như đọc truyện tranh Nhật Bản - từ phải sang trái. Đi theo các mũi tên chỉ sang trái. Dưới đây là một ví dụ đơn giản từ dbForge Studio dành cho SQL Server.
Như Hình 6 minh họa, mũi tên trỏ sang trái từ toán tử Tìm kiếm chỉ mục đến toán tử CHỌN.
Tuy nhiên, đọc từ phải sang trái có thể không phải lúc nào cũng chính xác. Xem Hình 7 với một ví dụ từ SSMS:
Nếu bạn đọc nó từ phải sang trái, bạn sẽ thấy rằng Quét lập chỉ mục đầu ra của toán tử là 1 trong 1 hàng. Làm thế nào nó có thể biết chỉ 1 hàng để tìm nạp? Đó là vì Hàng đầu nhà điều hành. Điều này sẽ khiến chúng ta bối rối nếu chúng ta đọc nó từ phải sang trái.
Để hiểu rõ hơn trường hợp này, hãy đọc nó là “toán tử CHỌN sử dụng Hàng đầu để tìm nạp 1 hàng bằng cách sử dụng Quét chỉ mục”. Đó là từ trái sang phải.
Chúng ta nên sử dụng những gì? Từ phải sang trái hay từ trái sang phải?
Đó là cả hai - tùy chọn nào giúp bạn hiểu được kế hoạch.
Trong khi mũi tên cung cấp cho chúng ta hướng của luồng dữ liệu, độ dày của nó cho chúng ta một số gợi ý về kích thước của dữ liệu. Hãy tham khảo lại Hình 4.
Quét chỉ mục theo cụm đi tới Vòng lặp lồng nhau có một mũi tên dày hơn so với những cái khác. Thuộc tính chi tiết về Quét chỉ mục trong Hình 5 cho chúng tôi biết tại sao nó lại dày (31.465 hàng được đọc cho kết quả cuối cùng là 5 hàng).
CẢNH BÁO
Biểu tượng cảnh báo xuất hiện trong toán tử kế hoạch thực thi cho chúng ta biết rằng có điều gì đó tồi tệ đã xảy ra trong toán tử đó. Điều này có thể cản trở việc tối ưu hóa truy vấn SQL của bạn bằng cách tiêu tốn nhiều tài nguyên hơn.
Bạn có thể thấy cảnh báo trong toán tử CHỌN. Di chuột đến nhà điều hành đó sẽ hiển thị thông báo cảnh báo. An TooiveGrant đã gây ra cảnh báo này.
TooiveGrant xảy ra khi bộ nhớ được sử dụng ít hơn so với bộ nhớ dành riêng cho truy vấn. Để biết thêm thông tin, hãy tham khảo tài liệu Microsoft này.
Hình 8 cho thấy truy vấn được sử dụng như một INNER JOIN của một khung nhìn tới một bảng. Bạn có thể loại bỏ cảnh báo bằng cách tham gia các bảng cơ sở thay vì chế độ xem.
Bây giờ bạn đã có ý tưởng cơ bản về việc đọc các kế hoạch thực thi, làm thế nào để xác định điều gì làm cho truy vấn của bạn chậm?
Biết 5 lỗi sai của nhà điều hành kế hoạch chung
Sự chậm trễ trong việc thực thi truy vấn của bạn giống như một tội ác. Bạn cần phải đuổi theo và bắt giữ những tên lừa đảo này.
1. Quét chỉ mục theo cụm hoặc không theo nhóm
Trò lừa đảo đầu tiên mà mọi người biết đến là Clustered hoặc Quét chỉ mục không theo cụm . Kiến thức phổ biến của nó trong tối ưu hóa truy vấn SQL rằng quét là xấu và tìm kiếm là tốt. Chúng tôi đã thấy một trong Hình 4. Do thiếu chỉ mục, nên Quét chỉ mục theo cụm đọc 31,465 để có 5 hàng.
Tuy nhiên, nó không phải luôn luôn như vậy. Hãy xem xét 2 truy vấn trên cùng một bảng trong Hình 9. Một truy vấn sẽ tìm kiếm và một truy vấn khác có quét.
Nếu bạn chỉ dựa trên tiêu chí về số lượng bản ghi, quá trình quét chỉ mục sẽ thắng với chỉ 5 bản ghi so với 120,180. Tìm kiếm chỉ mục sẽ mất nhiều thời gian hơn để thực thi.
Đây là một trường hợp khác mà việc quét hoặc tìm kiếm hầu như không quan trọng. Chúng trả về 6 bản ghi giống nhau từ cùng một bảng. Các lần đọc logic giống nhau và thời gian trôi qua bằng 0 trong cả hai trường hợp. Bảng rất nhỏ chỉ có 6 bản ghi. Bao gồm Kế hoạch thực thi thực tế và chạy các câu lệnh bên dưới.
-- Run this with Include Actual Execution Plan
USE AdventureWorks
GO
SET STATISTICS IO ON
GO
SELECT AddressTypeID, Name
FROM Person.AddressType
WHERE AddressTypeID >= 1
ORDER BY AddressTypeID DESC
Sau đó, lưu kế hoạch thực hiện để so sánh sau này. Nhấp chuột phải vào kế hoạch thực thi> Lưu kế hoạch thực thi dưới dạng .
Bây giờ, hãy chạy truy vấn bên dưới.
SELECT AddressTypeID, Name
FROM Person.AddressType
ORDER BY AddressTypeID DESC
SET STATISTICS IO OFF
GO
Tiếp theo, nhấp chuột phải vào Kế hoạch thực thi và chọn So sánh kế hoạch trình chiếu . Sau đó, chọn tệp bạn đã lưu trước đó. Bạn sẽ có đầu ra giống như trong Hình 10 bên dưới.
MemoryGrant và QueryTimeStats giống nhau. 128KB Bộ nhớ biên dịch được sử dụng trong Tìm kiếm chỉ mục theo cụm so với 88KB của Quét chỉ mục theo cụm hầu như không đáng kể. Nếu không có những số liệu này để so sánh, việc thực hiện sẽ giống nhau.
2. Tránh quét bảng
Điều này xảy ra khi bạn không có chỉ mục. Thay vì tìm kiếm các giá trị bằng cách sử dụng chỉ mục, SQL Server sẽ quét từng hàng một cho đến khi nhận được những gì bạn cần trong truy vấn của mình. Điều này sẽ tụt hậu rất nhiều trên các bảng lớn. Giải pháp đơn giản là thêm chỉ mục thích hợp.
Dưới đây là ví dụ về kế hoạch thực thi với Quét bảng toán tử trong Hình 11.
3. Quản lý Hiệu suất Sắp xếp
Vì nó xuất phát từ tên, nó thay đổi thứ tự của các hàng. Đây có thể là một hoạt động tốn kém.
Nhìn vào các đường mũi tên béo đó từ bên phải và bên trái của Sắp xếp nhà điều hành. Vì trình tối ưu hóa truy vấn quyết định thực hiện Hợp nhất kết hợp , a Sắp xếp bắt buộc. Cũng lưu ý rằng nó có chi phí phần trăm cao nhất trong tất cả các nhà khai thác (55%).
Sắp xếp có thể rắc rối hơn nếu SQL Server cần sắp xếp các hàng nhiều lần. Bạn có thể tránh toán tử này nếu bảng của bạn được sắp xếp trước dựa trên yêu cầu truy vấn. Hoặc bạn có thể chia một truy vấn thành nhiều truy vấn.
4. Loại bỏ các tra cứu chính
Trong Hình 4 trước đó, SQL Server khuyến nghị thêm một chỉ mục khác. Tôi đã làm được, nhưng nó không mang lại cho tôi chính xác những gì tôi muốn. Thay vào đó, nó đã cho tôi Tìm kiếm chỉ mục vào chỉ mục mới được ghép nối với Tra cứu khóa nhà điều hành.
Vì vậy, chỉ mục mới đã thêm một bước bổ sung.
Cái gì Tra cứu chìa khóa này nhà điều hành làm gì?
Bộ xử lý truy vấn đã sử dụng chỉ mục không phân cụm mới được đóng hộp màu xanh lục trong Hình 13. Vì truy vấn của chúng tôi yêu cầu các cột không có trong chỉ mục mới, nên nó cần lấy những dữ liệu đó với sự trợ giúp của Tra cứu khóa từ chỉ mục được phân nhóm. Làm sao chúng ta biết được điều này? Di chuột đến Tra cứu phím tiết lộ một số thuộc tính của nó và chứng minh quan điểm của chúng tôi.
Trong Hình 14, hãy chú ý đến Danh sách đầu ra. Chúng tôi cần truy xuất 3 cột bằng PK_SalesOrderHeader_SalesOrderID chỉ số cụm. Để loại bỏ điều này, bạn cần đưa các cột này vào chỉ mục mới. Đây là kế hoạch mới sau khi các cột này được bao gồm.
Trong Hình 14, chúng ta đã thấy 4 Vòng lặp lồng nhau . Cái thứ tư là cần thiết cho Tra cứu khóa được thêm vào . Nhưng sau khi thêm 3 cột làm cột Được bao gồm vào chỉ mục mới, chỉ có 3 Vòng lặp lồng nhau vẫn còn và Tra cứu khóa bị xóa. Chúng tôi không cần thêm bất kỳ bước nào.
5. Song song trong kế hoạch thực thi SQL Server
Cho đến nay, bạn đã thấy các kế hoạch thực thi trong quá trình thực thi nối tiếp. Nhưng đây là kế hoạch thúc đẩy thực hiện song song. Điều này có nghĩa là nhiều hơn 1 bộ xử lý được sử dụng bởi trình tối ưu hóa truy vấn để chạy truy vấn. Khi chúng tôi sử dụng thực thi song song, chúng tôi thấy Song song các toán tử trong kế hoạch và cả những thay đổi khác.
Trong Hình 16, 3 Song song các toán tử đã được sử dụng. Cũng lưu ý rằng Bảng quét biểu tượng toán tử hơi khác một chút. Điều này xảy ra khi thực thi song song được sử dụng.
Tính song song vốn dĩ không phải là xấu. Nó làm tăng tốc độ của các truy vấn bằng cách sử dụng nhiều lõi xử lý hơn. Tuy nhiên, nó sử dụng nhiều tài nguyên CPU hơn. Khi nhiều truy vấn của bạn sử dụng song song, nó sẽ làm chậm máy chủ. Bạn có thể muốn kiểm tra ngưỡng chi phí cho cài đặt song song trong SQL Server của mình.
5. Các phương pháp hay nhất để tối ưu hóa truy vấn SQL
Cho đến nay, chúng tôi đã xử lý tối ưu hóa truy vấn SQL bằng các phương pháp tìm ra các vấn đề khó phát hiện. Nhưng có nhiều cách để phát hiện ra nó trong mã. Dưới đây là một số mùi mã trong SQL.
Sử dụng SELECT *
Đang vội? Sau đó, nhập * có thể dễ dàng hơn so với việc chỉ định tên cột. Tuy nhiên, có một điểm khó khăn. Các cột bạn không cần sẽ làm chậm truy vấn của bạn.
Có bằng chứng. Truy vấn mẫu mà tôi đã sử dụng cho Hình 15 là:
USE AdventureWorks
GO
SELECT
d.FirstName
,d.MiddleName
,d.LastName
,d.Suffix
,a.OrderDate
,a.ShipDate
,a.Status
,b.ProductID
,b.OrderQty
,b.UnitPrice
FROM sales.SalesOrderHeader a
INNER JOIN sales.SalesOrderDetail b ON a.SalesOrderID = b.SalesOrderID
INNER JOIN Sales.Customer c ON a.CustomerID = c.CustomerID
INNER JOIN Person.Person d ON c.PersonID = d.BusinessEntityID
WHERE a.ShipDate = '07/11/2011'
Chúng tôi đã tối ưu hóa nó. Nhưng hãy thay đổi nó thành CHỌN *
USE AdventureWorks
GO
SELECT *
FROM sales.SalesOrderHeader a
INNER JOIN sales.SalesOrderDetail b ON a.SalesOrderID = b.SalesOrderID
INNER JOIN Sales.Customer c ON a.CustomerID = c.CustomerID
INNER JOIN Person.Person d ON c.PersonID = d.BusinessEntityID
WHERE a.ShipDate = '07/11/2011'
Nó ngắn hơn cũng được, nhưng hãy kiểm tra Kế hoạch thực thi bên dưới:
Đây là kết quả của việc bao gồm tất cả các cột, ngay cả những cột bạn không cần. Nó trả về Tra cứu chìa khóa và rất nhiều Compute Scalar . Tóm lại, truy vấn này có tải nặng và kết quả là sẽ bị trễ. Cũng lưu ý đến cảnh báo trong toán tử CHỌN. Nó không có ở đó trước đây. Thật lãng phí!
Các hàm trong Mệnh đề WHERE hoặc THAM GIA
Một mùi mã khác là có một chức năng trong mệnh đề WHERE. Xét 2 câu lệnh SELECT sau đây có cùng một tập kết quả. Sự khác biệt là ở mệnh đề WHERE.
SELECT
D.FirstName
,D.MiddleName
,D.LastName
,D.Suffix
,a.OrderDate
,a.ShipDate
,a.Status
,b.ProductID
,b.OrderQty
,b.UnitPrice
FROM sales.SalesOrderHeader a
INNER JOIN sales.SalesOrderDetail b ON a.SalesOrderID = b.SalesOrderID
INNER JOIN Sales.Customer c ON a.CustomerID = c.CustomerID
INNER JOIN Person.Person d ON c.PersonID = D.BusinessEntityID
WHERE YEAR(a.ShipDate) = 2011
AND MONTH(a.ShipDate) = 7
SELECT
D.FirstName
,D.MiddleName
,D.LastName
,D.Suffix
,a.OrderDate
,a.ShipDate
,a.Status
,b.ProductID
,b.OrderQty
,b.UnitPrice
FROM sales.SalesOrderHeader a
INNER JOIN sales.SalesOrderDetail b ON a.SalesOrderID = b.SalesOrderID
INNER JOIN Sales.Customer c ON a.CustomerID = c.CustomerID
INNER JOIN Person.Person d ON c.PersonID = D.BusinessEntityID
WHERE a.ShipDate BETWEEN '07/1/2011' AND '07/31/2011'
Câu lệnh SELECT đầu tiên sử dụng các hàm ngày YEAR và MONTH để chỉ ra ngày giao hàng trong tháng 7 năm 2011. Câu lệnh SELECT thứ hai sử dụng toán tử BETWEEN với các ký tự ngày.
Câu lệnh SELECT đầu tiên sẽ có một kế hoạch thực thi tương tự như Hình 4 nhưng không có khuyến nghị chỉ mục. Hình thứ hai sẽ có một kế hoạch thực hiện tốt hơn tương tự như Hình 15.
Cái được tối ưu hóa tốt hơn là điều hiển nhiên.
Sử dụng Ký tự đại diện
Các ký tự đại diện có thể ảnh hưởng đến việc tối ưu hóa truy vấn SQL của chúng ta như thế nào? Hãy lấy một ví dụ.
Truy vấn cố gắng tìm kiếm sự hiện diện của một chuỗi trong Họ ở bất kỳ vị trí nào. Do đó, Họ LIKE ‘% va%’ . Điều này không hiệu quả trên các bảng lớn vì các hàng sẽ được kiểm tra từng hàng một về sự hiện diện của chuỗi đó. Đó là lý do tại sao Quét chỉ mục Được sử dụng. Vì không có chỉ mục nào bao gồm Tiêu đề , một Tra cứu khóa cũng được sử dụng.
Điều này có thể được khắc phục theo thiết kế.
Ứng dụng gọi điện có yêu cầu điều đó không? Hay chỉ sử dụng LIKE ‘va%’ là đủ?
LIKE ‘va%’ sử dụng Tìm kiếm chỉ mục vì bảng có chỉ mục trên họ , tên đầu tiên và tên đệm .
Bạn cũng có thể thêm nhiều bộ lọc hơn trong mệnh đề WHERE để giảm số lượng bản ghi được đọc không?
Câu trả lời của bạn cho những câu hỏi này sẽ giúp bạn cách khắc phục truy vấn này.
Chuyển đổi ngầm định
SQL Server thực hiện chuyển đổi ngầm ẩn đằng sau hậu trường để điều hòa các kiểu dữ liệu khi so sánh các giá trị. Ví dụ:thật tiện lợi khi gán một số cho một cột chuỗi mà không có dấu ngoặc kép. Nhưng có một cơ hội. Hiệu ứng tương tự khi bạn sử dụng một hàm trong mệnh đề WHERE.
SELECT
NationalIDNumber
,JobTitle
,HireDate
FROM HumanResources.Employee
WHERE NationalIDNumber = 56920285
NationalIDNumner là NVARCHAR (15) nhưng được tương đương với một số. Nó sẽ chạy thành công vì chuyển đổi ngầm định. Nhưng hãy lưu ý kế hoạch thực hiện trong Hình 19 bên dưới.
Chúng tôi thấy 2 điều tồi tệ ở đây. Đầu tiên, cảnh báo. Sau đó, Quét chỉ mục . Quá trình quét chỉ mục đã xảy ra do chuyển đổi ngầm định. Do đó, hãy đảm bảo đặt các chuỗi trong dấu ngoặc kép hoặc kiểm tra các giá trị theo nghĩa đen có cùng kiểu dữ liệu với cột.
Các phương pháp tiếp cận tối ưu hóa truy vấn SQL
Đó là nó. Những điều cơ bản về tối ưu hóa truy vấn SQL có khiến bạn cảm thấy sẵn sàng cho các truy vấn của mình không? Hãy tóm tắt lại.
- Nếu bạn muốn các truy vấn của mình được tối ưu hóa, hãy bắt đầu với một thiết kế cơ sở dữ liệu tốt.
- Nếu cơ sở dữ liệu đã được sản xuất, hãy phát hiện các truy vấn có vấn đề bằng cách sử dụng các báo cáo tiêu chuẩn của SQL Server.
- Tìm hiểu mức độ ảnh hưởng của truy vấn chậm với các lần đọc logic từ STATISTICS IO.
- Tìm hiểu sâu hơn câu chuyện về truy vấn chậm của bạn với Kế hoạch thực thi.
- Xem 4 mùi mã làm chậm các truy vấn của bạn.
Có các mẹo tối ưu hóa truy vấn SQL khác để làm cho một truy vấn chậm chạy nhanh. Như tôi đã nói lúc đầu, đây là một chủ đề lớn. Vì vậy, hãy cho chúng tôi biết trong phần Nhận xét chúng tôi đã bỏ lỡ điều gì khác.
Và nếu bạn thích bài đăng này, hãy chia sẻ nó trên các nền tảng mạng xã hội yêu thích của bạn.
Tối ưu hóa truy vấn SQL khác từ các bài viết trước
Nếu bạn cần thêm ví dụ, đây là một số bài đăng hữu ích liên quan đến kỹ thuật tối ưu hóa truy vấn trong SQL Server.
- Các truy vấn phụ có hiệu suất kém không? Xem Hướng dẫn đơn giản về cách sử dụng truy vấn con trong SQL Server .
- Sử dụng HierarchyID so với thiết kế cha / con - cái nào nhanh hơn? Truy cập Cách sử dụng SQL Server HierarchyID thông qua các ví dụ dễ dàng .
- Các truy vấn cơ sở dữ liệu đồ thị có thể hoạt động tốt hơn các truy vấn tương đương quan hệ của chúng trong hệ thống đề xuất thời gian thực không? Xem Cách sử dụng các tính năng của cơ sở dữ liệu đồ thị SQL Server .
- Cái nào nhanh hơn:COALESCE hay ISNULL? Tìm hiểu trong Các câu trả lời hàng đầu cho 5 câu hỏi nhức nhối về Hàm COALESCE trong SQL .
- CHỌN TỪ Chế độ xem so với CHỌN TỪ Bảng Cơ sở - Cái nào sẽ Chạy nhanh hơn? Truy cập 3 mẹo hàng đầu bạn cần biết để viết chế độ xem SQL nhanh hơn .
- CTE so với Bảng tạm thời so với Truy vấn con. Biết cái nào sẽ thắng trong Mọi thứ bạn cần biết về SQL CTE tại một điểm .
- Sử dụng SQL SUBSTRING trong mệnh đề WHERE - Bẫy hiệu suất? Hãy xem điều đó có đúng không với các ví dụ trong Cách phân tích cú pháp chuỗi giống như một chuyên gia bằng cách sử dụng hàm SUBSTRING () của SQL?
- SQL UNION ALL nhanh hơn UNION. Biết lý do tại sao trong SQL UNION Cheat Sheet với 10 mẹo dễ dàng và hữu ích .
