Những kỹ thuật chung nào có thể được áp dụng để tối ưu hóa các truy vấn SQL?

Question

Kỹ thuật nào có thể được áp dụng hiệu quả để cải thiện hiệu suất của các truy vấn SQL? Có quy tắc chung nào áp dụng không?

Answer 1

• Sử dụng khóa chính
• Tránh chọn *
• Hãy càng cụ thể càng tốt khi xây dựng báo cáo có điều kiện bạn
• Hủy chuẩn hóa thường có thể hiệu quả hơn
• Biến bảng và bảng tạm thời (nếu có) thường sẽ tốt hơn so với sử dụng bảng nguồn lớn
• quan điểm được chia
• chỉ số sử dụng và hạn chế

Answer 2

Tôi nghĩ rằng việc sử dụng trình phân tích truy vấn SQL sẽ là một khởi đầu tốt.

Answer 3

Trong Oracle, bạn có thể nhìn vào explain plan để so sánh các biến thể trên truy vấn của bạn

Answer 4

Hãy chắc chắn rằng bạn có các chỉ số ngay trên bàn. nếu bạn thường xuyên sử dụng cột làm cách để đặt hàng hoặc giới hạn tập dữ liệu của mình, chỉ mục có thể tạo ra sự khác biệt lớn. Tôi đã thấy trong một bài báo gần đây rằng chọn riêng biệt thực sự có thể làm chậm một truy vấn, đặc biệt là nếu bạn không có chỉ mục.

Answer 5

Tối ưu hóa rõ ràng cho các truy vấn SELECT là đảm bảo bạn có chỉ mục trên các cột được sử dụng cho các kết nối hoặc trong mệnh đề WHERE.

Vì việc thêm chỉ mục có thể làm chậm quá trình ghi dữ liệu, bạn cần theo dõi hiệu suất để đảm bảo bạn không giết hiệu suất ghi của DB, nhưng đó là nơi sử dụng công cụ phân tích truy vấn phù hợp.

Answer 6

Điều quan trọng nhất bạn có thể làm là tìm bảng quét trong máy phân tích truy vấn máy chủ sql (đảm bảo bạn bật "hiển thị kế hoạch thực hiện"). Nếu không thì có vô số bài báo tại MSDN và các nơi khác sẽ đưa ra lời khuyên tốt. Là một sang một bên, khi tôi bắt đầu học để tối ưu hóa các truy vấn tôi đã chạy sql máy chủ truy vấn hồ sơ đối với một dấu vết, nhìn vào SQL tạo ra, và cố gắng tìm ra lý do tại sao đó là một sự cải tiến. Trình lược tả truy vấn ở xa tối ưu, nhưng đó là một khởi đầu tốt.

Answer 7

• Chỉ số
• kê
• trên đống microsoft, Database Engine Tuning Advisor

Answer 8

Tìm hiểu những gì đang thực sự xảy ra dưới mui xe - bạn sẽ có thể hiểu được các khái niệm sau đây một cách chi tiết:

• Chỉ mục (không chỉ là những gì chúng thực sự là cách chúng hoạt động).
• Chỉ mục được nhóm và bảng được phân bổ heap.
• Tra cứu văn bản và nhị phân và khi chúng có thể được xếp hàng.
• Fill factor.
• Làm thế nào các bản ghi bị mờ để cập nhật/xóa.
• Khi chia tách trang xảy ra và tại sao.
• Thống kê và cách chúng ảnh hưởng đến tốc độ truy vấn khác nhau.
• Trình hoạch định truy vấn và cách hoạt động cho cơ sở dữ liệu cụ thể của bạn (ví dụ trên một số hệ thống "chọn *" chậm, trên MS-Sql DB hiện đại, người lập kế hoạch có thể xử lý nó).

Answer 9

Có một vài điều bạn có thể xem để tối ưu hóa hiệu suất truy vấn của mình.

1. Đảm bảo rằng bạn chỉ có tối thiểu dữ liệu. Đảm bảo bạn chỉ chọn các cột bạn cần. Giảm kích thước trường xuống mức tối thiểu.

2. Cân nhắc de-bình thường hóa cơ sở dữ liệu của bạn để giảm kết hợp

3. Tránh vòng lặp (ví dụ: lấy con trỏ), dính vào thiết lập hoạt động.

4. Triển khai truy vấn dưới dạng thủ tục được lưu trữ vì thao tác này được biên dịch trước và sẽ thực thi nhanh hơn.

5. Đảm bảo rằng bạn đã thiết lập chỉ mục chính xác. Nếu cơ sở dữ liệu của bạn được sử dụng chủ yếu để tìm kiếm thì hãy xem xét nhiều chỉ mục hơn.

6. Sử dụng kế hoạch thực hiện để xem cách xử lý được thực hiện. Những gì bạn muốn tránh là một bảng quét vì điều này là tốn kém.

7. Đảm bảo rằng Thống kê tự động được đặt thành bật. SQL cần điều này để giúp quyết định thực thi tối ưu. Xem bài đăng tuyệt vời của Mike Gunderloy để biết thêm thông tin. Basics of Statistics in SQL Server 2005

8. Đảm bảo các chỉ mục của bạn không bị phân mảnh. Reducing SQL Server Index Fragmentation

9. Đảm bảo bảng của bạn không bị phân mảnh. How to Detect Table Fragmentation in SQL Server 2000 and 2005

Answer 10

Sử dụng với statment để xử lý lọc truy vấn. Giới hạn mỗi truy vấn phụ xuống số hàng tối thiểu có thể. rồi tham gia các truy vấn phụ.

WITH 
master AS 
(
    SELECT SSN, FIRST_NAME, LAST_NAME 
    FROM MASTER_SSN 
    WHERE STATE = 'PA' AND 
      GENDER = 'M' 
), 
taxReturns AS 
(
    SELECT SSN, RETURN_ID, GROSS_PAY 
    FROM MASTER_RETURNS 
    WHERE YEAR < 2003 AND 
      YEAR > 2000 
) 
SELECT * 
FROM master, 
    taxReturns 
WHERE master.ssn = taxReturns.ssn 

Một truy vấn con trong câu lệnh có thể kết thúc giống như chế độ xem nội tuyến, hoặc bảng tạm thời được tạo tự động. Tôi tìm thấy trong công việc tôi làm, dữ liệu bán lẻ, khoảng 70-80% thời gian, có một lợi ích hiệu suất.

100% thời gian, có một lợi ích bảo trì.

Answer 11

Một số điểm khác (Mine được dựa trên SQL server, vì mỗi db backend có nó hiện thực của riêng họ có thể hoặc không thể giữ đúng đối với tất cả các cơ sở dữ liệu):

Tránh truy vấn con tương quan trong phần lựa chọn của một tuyên bố, chúng chủ yếu là con trỏ.

Thiết kế bảng của bạn để sử dụng đúng kiểu dữ liệu để tránh phải áp dụng các chức năng trên chúng để lấy dữ liệu. Nó là khó khăn hơn để làm toán ngày khi bạn lưu trữ dữ liệu của bạn như là varchar ví dụ.

Nếu bạn thấy rằng bạn thường xuyên tham gia có các chức năng trong đó, thì bạn cần suy nghĩ về việc thiết kế lại các bảng của mình.

Nếu điều kiện WHERE hoặc JOIN của bạn bao gồm câu lệnh OR (chậm hơn), bạn có thể nhận được tốc độ tốt hơn bằng cách sử dụng câu lệnh UNION.

UNION ALL nhanh hơn UNION nếu (Và chỉ khi) hai thống kê loại trừ lẫn nhau và trả về cùng một kết quả theo cách đó.

NOT EXISTS thường là nhanh hơn NOT IN hoặc sử dụng một trái tham gia với một mệnh đề WHERE ID = null

Trong một truy vấn UPDATE thêm một WHERE điều kiện để đảm bảo bạn không cập nhật giá trị mà đã bằng nhau. Sự khác biệt giữa việc cập nhật 10.000.000 bản ghi và 4 có thể khá đáng kể!

Cân nhắc tính trước một số giá trị nếu bạn sẽ truy vấn chúng thường xuyên hoặc cho các báo cáo lớn. Một tổng các giá trị trong một lệnh chỉ cần được thực hiện khi lệnh được thực hiện hoặc điều chỉnh, thay vì khi bạn đang tóm tắt kết quả của 10.000.000 triệu đơn hàng trong một báo cáo. Việc tính toán trước nên được thực hiện trong trình kích hoạt để chúng luôn được cập nhật là những thay đổi dữ liệu cơ bản. Và nó không phải chỉ là số, chúng tôi đã tính toán trường kết hợp các tên mà chúng tôi sử dụng trong các báo cáo.

Hãy cảnh giác với UDF vô hướng, chúng có thể chậm hơn so với đặt mã trong dòng.

Bảng tạm thời có xu hướng nhanh hơn cho các tập dữ liệu lớn và các biến bảng nhanh hơn cho các tập dữ liệu nhỏ. Ngoài ra, bạn có thể lập chỉ mục các bảng tạm thời.

Định dạng thường nhanh hơn trong giao diện người dùng so với trong SQL.

Không trả lại nhiều dữ liệu hơn bạn thực sự cần.

Điều này có vẻ hiển nhiên nhưng bạn sẽ không tin rằng tần suất tôi kết thúc việc sửa lỗi này. Không tham gia vào các bảng mà bạn không sử dụng để lọc các bản ghi hoặc thực sự gọi một trong các trường trong phần chọn của câu lệnh. Tham gia không cần thiết có thể rất tốn kém.

Một ý tưởng rất tồi tệ khi tạo chế độ xem gọi các chế độ xem khác gọi các chế độ xem khác. Bạn có thể thấy bạn đang tham gia cùng một bảng 6 lần khi bạn chỉ cần một lần và tạo 100.000,00 bản ghi ở chế độ xem cơ bản để nhận được 6 kết quả trong kết quả cuối cùng của bạn.

Khi thiết kế cơ sở dữ liệu, hãy suy nghĩ về báo cáo không chỉ giao diện người dùng để nhập dữ liệu. Dữ liệu là vô ích nếu nó không được sử dụng, vì vậy hãy suy nghĩ về cách nó sẽ được sử dụng sau khi nó nằm trong cơ sở dữ liệu và cách dữ liệu đó sẽ được duy trì hoặc kiểm toán. Điều đó thường sẽ thay đổi thiết kế. (Đây là một trong những lý do tại sao nó là một ý tưởng tồi để cho ORM thiết kế các bảng của bạn, nó chỉ nghĩ về một trường hợp sử dụng cho dữ liệu.) Các truy vấn phức tạp nhất ảnh hưởng đến hầu hết dữ liệu đang được báo cáo. có thể tăng tốc độ truy vấn (và đơn giản hóa chúng) một cách đáng kể.

Triển khai cơ sở dữ liệu cụ thể của các tính năng có thể nhanh hơn sử dụng SQL chuẩn (Đó là một trong những cách họ bán sản phẩm của họ), để biết các tính năng cơ sở dữ liệu của bạn và tìm hiểu nhanh hơn.

Và vì không thể nói quá thường xuyên, hãy sử dụng chỉ mục chính xác, không quá nhiều hoặc quá ít. Và làm cho mệnh đề WHERE của bạn sargable (Có thể sử dụng các chỉ mục).