Gợi ý tối ưu hóa truy vấn SQL Server 2005/8

Tôi đang xem xét việc giáo dục một nhóm viết các truy vấn SQL Server tốt hơn và đang tự hỏi những gợi ý tốt nhất của mọi người là gì để cải thiện hiệu suất.

Chẳng hạn, tôi đã từng có một DBA, người đã khăng khăng rằng số đếm (*) sẽ hoạt động kém hơn số đếm (1) (Tôi không biết liệu cô ấy có đúng hay không, liệu nó có còn hợp lệ với các trình tối ưu hóa truy vấn mới nhất hay không).

Những điều đơn giản tôi nên nói với nhóm để thử và luôn luôn sử dụng hoặc tránh? Tôi lý tưởng tìm kiếm những thứ mà (a) có thể tạo ra sự khác biệt hợp lý và (b) thẳng tiến, 1 - 2 dòng để nêu.

Điều chỉnh truy vấn 101

Không có viên đạn bạc ma thuật để điều chỉnh truy vấn, mặc dù tôi có thể cung cấp cho bạn một số gợi ý và mẹo. Điều đầu tiên cần làm là hiểu những gì thực sự xảy ra đằng sau hậu trường. Nhận một cuốn sách nội bộ tốt như cuốn sách Hướng dẫn của bậc thầy thứ ba.

Các truy vấn thực hiện kém có xu hướng có hai loại cơ bản: Truy vấn giao dịch mất quá nhiều thời gian và nghiền các công việc hàng loạt (hoặc báo cáo) mất quá nhiều thời gian. Một dấu hiệu tốt của một truy vấn có vấn đề với nó là một mục duy nhất trong kế hoạch truy vấn chiếm 99% thời gian.

Truy vấn giao dịch

Trong hầu hết các trường hợp, một truy vấn giao dịch thực hiện kém là một trong một số điều:

• Một chỉ số còn thiếu. Bạn có thể thấy điều này trong kế hoạch truy vấn - quét bảng của các bảng lớn trên một phép nối nên rất chọn lọc (nghĩa là trả về vài hàng).

• Truy vấn không thể sử dụng một chỉ mục. Nếu bạn có điều kiện OR trong mệnh đề where, tham gia vào một giá trị được tính toán hoặc một số mục khác trong truy vấn không có khả năng sarg thì bạn có thể cần phải viết lại truy vấn. Tóm lại, sarg là các vị từ truy vấn có thể sử dụng các chỉ mục để loại bỏ các hàng. Logic VÀ, đẳng thức và bất đẳng thức (>,> =, <, <= và! =) Đều có khả năng. HOẶC theo truyền thống là không thể sarg. Tuy nhiên, bạn thường có thể dịch OR thành các vị từ có khả năng sarg bằng cách đảo ngược ý nghĩa từ các cấu trúc loại OR sang KHÔNG (foo và không bar).

• Vị ngữ không hiệu quả. Ví dụ: nếu bạn có where intham chiếu một truy vấn con lồng nhau, hãy xem liệu nó có thể được viết lại dưới dạng where existshoặc tham gia không. Điều này có thể dẫn đến các kế hoạch truy vấn hiệu quả hơn và đây là cách viết lại tiêu chuẩn khác mà bạn có thể thử. Một lần nữa, sách hướng dẫn của Đạo sư và những cuốn khác về chủ đề này là một điểm khởi đầu tốt.

Truy vấn hàng loạt

Truy vấn hàng loạt phức tạp hơn và có các vấn đề điều chỉnh khác nhau. Một số lời khuyên là:

• Lập chỉ mục. Điều này có thể tạo ra sự khác biệt lớn cho cùng một lý do với các truy vấn giao dịch. Thông thường, một dấu hiệu tốt của một chỉ mục bị thiếu là một hoạt động dài, nghiền (99% kế hoạch truy vấn) dường như không làm hỏng máy.

• Bảng tạm thời. Bạn có thể thấy tốt hơn khi chia một truy vấn thành một số truy vấn điền vào các bảng tạm thời. Các truy vấn lớn hơn cung cấp cho trình tối ưu hóa nhiều chỗ hơn để giải quyết, mặc dù đây không phải là vấn đề mà trước đây. Tạo các bảng tạm thời với select intothao tác này được ghi nhật ký tối thiểu (hoạt động nhật ký ít hơn nhiều), giúp giảm tải I / O.
  
  Lưu ý rằng các bảng tạm thời trong tempdb là cùng một cấu trúc dữ liệu mà trình tối ưu hóa sử dụng để lưu trữ kết quả tham gia trung gian, do đó không có hình phạt về hiệu năng khi thực hiện việc này. Bạn cũng có thể tạo một chỉ mục (bao gồm các chỉ mục được nhóm và bao trùm) trên một bảng tạm thời, điều này có thể cải thiện hiệu suất của các truy vấn đọc nó với cùng lý do là chúng cải thiện các truy vấn trên các bảng tĩnh.
  
  Đừng làm quá nhiều bảng tạm thời, vì chúng có thể khiến mọi thứ khó theo dõi hơn thông qua truy vấn. Đối với các bảng nhỏ hơn trong một thủ tục được lưu trữ, hãy kiểm tra xem các biến của bảng có giúp ích không. Đây là một cấu trúc dữ liệu trong bộ nhớ, vì vậy chúng có thể là một chiến thắng hiệu suất.

• Phân cụm và bao gồm các chỉ số. Chúng có thể cải thiện hiệu năng của một truy vấn khi chúng buộc địa phương tham chiếu trên đĩa dựa trên một số nhóm nhóm. Một chỉ mục được nhóm có thể tạo ra một sự khác biệt lớn đối với hiệu suất của một công việc hàng loạt.

• Vị ngữ không hiệu quả. Những điều này có thể gây ra vấn đề với sarg và các tối ưu hóa phụ khác theo cách tương tự như chúng làm với các truy vấn giao dịch.

• Bảng quét là bạn của bạn. Trái với niềm tin phổ biến, quét bàn không phải là xấu xa. Nói chung, chúng là một dấu hiệu của một cái gì đó sai trong truy vấn giao dịch, nhưng chúng thường là cách hiệu quả nhất để thực hiện một hoạt động hàng loạt lớn. Nếu bạn đang làm một cái gì đó với hơn một vài phần trăm hàng trong một bảng, quét bảng thường là cách hiệu quả nhất để che bảng.

• Các vòng lặp lồng nhau tham gia. Hãy xem những gì trình tối ưu hóa đang làm ở cả hai phía của sự tham gia. Chúng có thể không hiệu quả nếu bạn (ví dụ: quét hai bảng lớn ở cả hai phía của một vòng lặp lồng nhau. Hãy xem xét sử dụng các chỉ mục được nhóm hoặc order bycố gắng thay đổi thao tác thành một phép nối hợp nhất hoặc gợi ý để thúc đẩy phép nối băm nếu một bên là đủ nhỏ để làm điều này với.

Khóa

Khóa cũng có thể gây ra vấn đề hiệu suất. Nếu hệ thống của bạn hoạt động kém khi tải, hãy nhìn vào bộ đếm profiler và perfmon liên quan đến khóa và kiểm tra xem có bất kỳ sự tranh chấp đáng kể nào không. sp_who2có một cột 'BlkBy' trong tập kết quả sẽ hiển thị nếu một truy vấn bị chặn và những gì đang chặn nó. Ngoài ra, các cấu hình có sự kiện 'biểu đồ khóa chết' (nếu bạn có truy vấn khóa chết) và các sự kiện liên quan đến khóa có thể hữu ích để khắc phục sự cố khóa.

Gợi ý tốt nhất: Sử dụng SQL Server 2008 và chạy Trình giám sát hoạt động trong khi các bài kiểm tra của bạn đang chạy. Lưu ý các truy vấn mất nhiều thời gian nhất / có nhiều I / O nhất, v.v. Nhấp chuột phải vào các truy vấn đó để xem truy vấn và / hoặc kế hoạch thực hiện.

Tiếp theo: học cách hiểu kế hoạch thực hiện.

Tiếp theo: Sử dụng thuật sĩ điều chỉnh cơ sở dữ liệu.

Các bước này sẽ giúp bạn tạo ra "gợi ý tốt nhất" của riêng bạn.

Một ebook tuyệt vời có sẵn từ RedGate về cách làm việc và hiểu các kế hoạch thực thi máy chủ SQL

http://www.red-gate.com/specials/Grant.htmlm?utm_content=Grant080623

Không biết cắm, tôi tham khảo các tài liệu điều chỉnh hiệu suất trên blog của mình trong Hiệu suất máy chủ SQL .

Khi bạn đã có cơ hội để tiêu hóa một số tài liệu này, xin vui lòng gửi bài ở đây hoặc liên hệ trực tiếp với tôi với các câu hỏi cụ thể.

Đầu tiên, lập chỉ mục. Nhiều người không nhận ra rằng khóa ngoại không tự động lấy chỉ mục. Vì chúng được sử dụng trong các phép nối nên hầu như luôn luôn có một chỉ mục.

Kiểm tra chặt chẽ tất cả các con trỏ để xem liệu chúng có thể được thay thế bằng mã dựa trên tập hợp thay thế hay không. Tôi đã thay đổi mã chạy hàng giờ thành giây bằng cách làm điều này.

Tránh các truy vấn con. Nếu bạn có chúng trong mã, hãy thay thế chúng bằng các phép nối hoặc nối với các bảng dẫn xuất.

Hãy chắc chắn rằng mệnh đề where của bạn có thể mở rộng.

Học cách đọc kế hoạch thực hiện.

Hãy chắc chắn rằng văn phòng có một vài cuốn sách hay về điều chỉnh hiệu suất.

Các biến bảng tốt hơn các bảng tạm thời trong một số trường hợp và các bảng tạm thời hoạt động tốt hơn trong các bảng khác, Nếu bạn cần sử dụng chúng, hãy thử cả hai và xem cái nào hoạt động tốt hơn trong trường hợp cụ thể đó.