Tiếp theo về Summer Performance Palooza 2013

Vào ngày 27 tháng 6, Chương trình Ảo về Hiệu suất PASS đã tổ chức Palooza Biểu diễn Mùa hè 2013 - một chương trình 24 Giờ PASS được thu nhỏ lại, nhưng chỉ tập trung vào các chủ đề liên quan đến hiệu suất. Tôi đã đưa ra một phiên thảo luận có tên "10 thói quen xấu có thể giết chết hiệu suất", đề cập đến 10 khái niệm sau:

1. CHỌN *
2. Chỉ mục mù
3. Không có tiền tố lược đồ
4. Tùy chọn con trỏ mặc định
tiền tố
5. sp_
6. Cho phép bộ nhớ cache phình ra
7. Các loại dữ liệu rộng
8. Máy chủ SQL mặc định
9. Lạm dụng các chức năng
10. "Hoạt động trên máy của tôi"

Bạn có thể nhớ một số chủ đề này từ các bài thuyết trình như bài nói chuyện "Thói quen xấu và phương pháp hay nhất" của tôi hoặc hội thảo trên web Điều chỉnh truy vấn hàng tuần mà tôi đã tổ chức cùng Kevin Kline từ đầu tháng 6 đến hết tuần này. (Nhân tiện, 6 video đó sẽ ra mắt vào đầu tháng 8 trên YouTube.)

Phiên của tôi có 351 người tham dự và tôi đã nhận được một số phản hồi tuyệt vời. Tôi muốn giải quyết một số vấn đề đó.

Đầu tiên, một vấn đề về cấu hình:Tôi đang sử dụng một micrô hoàn toàn mới và không biết rằng mỗi lần nhấn phím sẽ phát ra âm thanh như sấm sét. Tôi đã giải quyết vấn đề đó bằng cách bố trí tốt hơn các thiết bị ngoại vi của mình, nhưng tôi muốn gửi lời xin lỗi đến những người bị ảnh hưởng bởi điều đó.

Tiếp theo, tải xuống; bộ bài và các mẫu được đăng lên địa điểm tổ chức sự kiện. Chúng ở cuối trang, nhưng bạn cũng có thể tải chúng xuống ngay tại đây.

Cuối cùng, những gì sau đây là danh sách các câu hỏi đã được đăng trong phiên họp và tôi muốn đảm bảo rằng tôi đã giải quyết bất kỳ câu hỏi nào chưa được trả lời trong phần Hỏi &Đáp trực tiếp. Tôi xin lỗi vì tôi đã giải quyết vấn đề này chỉ trong vòng chưa đầy một tháng. , nhưng có đã rất nhiều câu hỏi và tôi không muốn xuất bản chúng thành từng phần.

A: Bạn sẽ phải tiếp cận vấn đề này theo từng trường hợp cụ thể, vì nó thực sự sẽ phụ thuộc vào nhiều yếu tố (bao gồm cả độ phức tạp của kế hoạch). Cũng lưu ý rằng bạn có thể biên dịch lại mức câu lệnh sao cho chỉ những câu lệnh bị ảnh hưởng mới phải thực hiện, trái ngược với toàn bộ mô-đun. Paul White đã nhắc tôi rằng mọi người thường 'sửa chữa' khả năng đánh hơi tham số bằng RECOMPILE , nhưng quá thường xuyên, điều đó có nghĩa là WITH RECOMPILE kiểu 2000 hơn là OPTION (RECOMPILE) tốt hơn nhiều , không chỉ giới hạn chính nó trong câu lệnh mà còn cho phép nhúng tham số, WITH RECOMPILE không làm. Vì vậy, nếu bạn định sử dụng RECOMPILE để ngăn chặn việc dò tìm tham số, hãy thêm nó vào câu lệnh, không phải mô-đun.

A: Như ở trên, điều này sẽ phụ thuộc vào chi phí và độ phức tạp của các kế hoạch và không có cách nào để nói, "Đúng, sẽ luôn có một thành công lớn." Bạn cũng phải chắc chắn so sánh cái đó với cái thay thế.

A: Tôi không chắc "có thể đọc được trong thế giới thực" nghĩa là gì. Nếu bạn muốn đầu ra ở một định dạng cụ thể, bạn thường nên chuyển đổi thành một chuỗi ở phía máy khách. C # và hầu hết các ngôn ngữ khác mà bạn có thể đang sử dụng ở cấp bản trình bày có nhiều khả năng định dạng đầu ra ngày / giờ từ cơ sở dữ liệu ở bất kỳ định dạng khu vực nào bạn muốn.

A: Hầu hết các DMV chỉ có hiệu lực kể từ lần dịch vụ cuối cùng bắt đầu, và thậm chí những DMV khác có thể được xả thường xuyên hơn (thậm chí theo yêu cầu - cả vô tình và cố ý). Tất nhiên, bộ nhớ cache kế hoạch luôn hoạt động liên tục và các kế hoạch AFAIK thoát ra khỏi bộ nhớ cache sẽ không duy trì số lượng trước đó của chúng nếu chúng xuất hiện trở lại. Vì vậy, ngay cả khi bạn nhìn thấy một kế hoạch trong bộ nhớ cache, tôi cũng không 100% tự tin rằng bạn có thể tin vào số lần sử dụng mà bạn tìm thấy.

Điều đó nói rằng, những gì bạn có thể đang tìm kiếm là sys.dm_exec_cached_plans.usecounts và bạn cũng có thể tìm thấy sys.dm_exec_procedure_stats.execution_count để giúp bổ sung thông tin cho các thủ tục trong đó các câu lệnh riêng lẻ trong các thủ tục không được tìm thấy trong bộ nhớ đệm.

A: Mối quan tâm chính xung quanh vấn đề này là khả năng sử dụng một số cú pháp nhất định, chẳng hạn như OUTER APPLY hoặc các biến với một hàm có giá trị bảng. Tôi không biết về bất kỳ trường hợp nào mà việc sử dụng khả năng tương thích thấp hơn có bất kỳ tác động trực tiếp nào đến hiệu suất, nhưng một số điều thường được khuyến nghị là xây dựng lại chỉ mục và cập nhật thống kê (và yêu cầu nhà cung cấp của bạn hỗ trợ mức độ tương thích mới hơn càng sớm càng tốt). Tôi đã thấy nó giải quyết được tình trạng suy giảm hiệu suất không mong muốn trong một số trường hợp đáng kể, nhưng tôi cũng đã nghe một số ý kiến ​​cho rằng làm như vậy là không cần thiết và thậm chí có thể là không khôn ngoan.

A: Không, ít nhất là về mặt hiệu suất, một ngoại lệ trong đó SELECT * không thành vấn đề khi được sử dụng bên trong EXISTS mệnh đề. Nhưng tại sao bạn lại sử dụng * đây? Tôi thích sử dụng EXISTS (SELECT 1 ... - trình tối ưu hóa sẽ xử lý những thứ đó giống nhau, nhưng theo cách nó tự ghi lại mã và đảm bảo rằng người đọc hiểu truy vấn con sẽ không trả về bất kỳ dữ liệu nào (ngay cả khi họ bỏ lỡ EXISTS lớn ở ngoài). Một số người sử dụng NULL và tôi không biết tại sao tôi bắt đầu sử dụng 1, nhưng tôi tìm thấy NULL hơi không trực quan.

* Lưu ý * bạn sẽ cần phải cẩn thận, nếu bạn cố gắng sử dụng EXISTS (SELECT * bên trong mô-đun bị ràng buộc giản đồ:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Bạn gặp lỗi này:

Tuy nhiên, thay đổi nó thành SELECT 1 hoạt động tốt. Vì vậy, có thể đó là một đối số khác để tránh SELECT * ngay cả trong trường hợp đó.

A: Có lẽ có hàng trăm ngôn ngữ khác nhau. Giống như các quy ước đặt tên, các tiêu chuẩn mã hóa là một điều rất chủ quan. Không quan trọng quy ước nào bạn quyết định phù hợp nhất với bạn; nếu bạn thích tbl tiền tố, bắt đầu đi! Thích Pascal hơn bigEndian, có nó. Muốn thêm tiền tố tên cột của bạn với kiểu dữ liệu, như intCustomerID , Tôi sẽ không ngăn cản bạn. Điều quan trọng hơn là bạn xác định một quy ước và sử dụng nó * một cách nhất quán. *

Điều đó nói lên rằng, nếu bạn muốn ý kiến ​​của tôi, tôi không thiếu chúng.

A: Tôi không biết có kế hoạch nào sẽ ngừng sử dụng XACT_ABORT vì vậy nó sẽ tiếp tục hoạt động tốt. Thành thật mà nói, tôi không thấy điều này được sử dụng thường xuyên vì bây giờ chúng tôi có TRY / CATCH (và THROW kể từ SQL Server 2012).

A: Tôi đã không kiểm tra điều này, nhưng trong nhiều trường hợp, việc thay thế một hàm vô hướng bằng một hàm có giá trị bảng nội tuyến có thể có tác động lớn đến hiệu suất. Vấn đề tôi nhận thấy là việc thực hiện chuyển đổi này có thể là một lượng lớn công việc trên hệ thống được viết trước APPLY đã tồn tại hoặc vẫn được quản lý bởi những người chưa chấp nhận cách tiếp cận tốt hơn này.

A: Bạn cần lưu ý đến hai điều:(1) độ trễ liên quan đến thời gian biên dịch hoặc (2) độ trễ liên quan đến lượng dữ liệu đang được tải để đáp ứng truy vấn và lần đầu tiên nó phải đến từ đĩa và không phải bộ nhớ. Đối với (1), bạn có thể thực hiện truy vấn trong SQL Sentry Plan Explorer và thanh trạng thái sẽ hiển thị cho bạn thời gian biên dịch cho các lần gọi đầu tiên và tiếp theo (mặc dù một phút có vẻ khá thừa cho việc này và không chắc). Nếu bạn không tìm thấy bất kỳ sự khác biệt nào, thì đó có thể chỉ là bản chất của hệ thống:không đủ bộ nhớ để hỗ trợ lượng dữ liệu bạn đang cố gắng tải với truy vấn này kết hợp với dữ liệu khác đã có trong vùng đệm. Nếu bạn không tin rằng một trong hai điều này là vấn đề, thì hãy xem liệu hai lần thực thi khác nhau có thực sự mang lại các kế hoạch khác nhau hay không - nếu có bất kỳ sự khác biệt nào, hãy đăng các kế hoạch lên answer.sqlperformance.com và chúng tôi sẽ sẵn lòng xem xét . Trên thực tế, việc nắm bắt các kế hoạch thực tế cho cả hai lần thực thi bằng cách sử dụng Plan Explorer trong mọi trường hợp cũng có thể cho bạn biết về bất kỳ sự khác biệt nào trong I / O và có thể dẫn đến việc SQL Server dành thời gian cho lần chạy đầu tiên, chậm hơn.

A: Không, tôi không nghĩ rằng cài đặt Tối ưu hóa cho khối lượng công việc đột xuất sẽ giúp ích cho trường hợp này, vì đánh giá tham số ngụ ý rằng các lần thực thi tiếp theo của cùng một kế hoạch được sử dụng cho các tham số khác nhau và với các hành vi hiệu suất khác nhau đáng kể. Tối ưu hóa cho khối lượng công việc đặc biệt được sử dụng để giảm thiểu tác động mạnh mẽ đến bộ đệm kế hoạch có thể xảy ra khi bạn có nhiều câu lệnh SQL khác nhau. Vì vậy, trừ khi bạn đang nói về tác động đến bộ nhớ cache kế hoạch của nhiều câu lệnh khác nhau, bạn đang gửi đến sp_executesql - điều này sẽ không được coi là đánh giá thông số - tôi nghĩ đang thử nghiệm với OPTION (RECOMPILE) có thể có kết quả tốt hơn hoặc nếu bạn biết các giá trị tham số * do * tạo ra kết quả tốt trên nhiều kết hợp tham số khác nhau, hãy sử dụng OPTIMIZE FOR . Câu trả lời này của Paul White có thể cung cấp cái nhìn sâu sắc hơn nhiều.

A: Chắc chắn, chỉ cần bao gồm OPTION (RECOMPILE) trong văn bản SQL động:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Kết quả:1 hàng hiển thị Sales.SalesOrderHeader truy vấn.

Bây giờ, nếu bất kỳ câu lệnh nào trong lô KHÔNG bao gồm OPTION (RECOMPILE) , kế hoạch có thể vẫn được lưu vào bộ nhớ cache, chỉ không thể sử dụng lại.

DBCC FREEPROCCACHE(0x06.....);