Tối ưu hóa: Di chuyển khai báo biến lên đầu thủ tục của bạn

Trong khi làm việc để tối ưu hóa một số thủ tục được lưu trữ, tôi đã ngồi xuống với DBA và trải qua một số thủ tục được lưu trữ với tính năng chặn cao và / hoặc hoạt động đọc / ghi cao.

Một điều mà DBA đã đề cập là tôi nên khai báo tất cả các biến (đặc biệt là các biến TABLE) ở đầu thủ tục được lưu trữ để tránh biên dịch lại.

Đây là lần đầu tiên tôi nghe về điều này và đang tìm kiếm một số xác nhận trước khi xem lại tất cả các thủ tục lưu trữ khác nhau mà chúng tôi có. Ông đã gọi nó là "xem mã muộn" và biên dịch lại đang khóa lược đồ sẽ giải thích cho việc chặn.

Việc di chuyển tất cả các khai báo biến lên đầu thủ tục được lưu trữ của bạn có làm giảm biên dịch lại không?

Không.

Điều này đã từng đúng trong một thời gian dài trước đây (và không còn nữa, ít nhất là kể từ SQL Server 2000), hoặc nó không bao giờ đúng và DBA của bạn chỉ nhầm lẫn đề xuất của anh ta với câu sau :

Điều quan trọng là nhóm tất cả các câu lệnh DDL (như tạo các chỉ mục) cho các bảng tạm thời khi bắt đầu một thủ tục được lưu trữ. Bằng cách đặt các câu lệnh DDL này cùng với các phần tổng hợp không cần thiết do thay đổi lược đồ có thể tránh được.

Bạn có thể tìm thấy một lời giải thích khác về lý do đằng sau khuyến nghị này trên trang này .

Nếu chúng ta xem Microsoft KB này , chúng ta sẽ thấy rằng nguyên nhân của quá trình biên dịch lại thủ tục được lưu trữ có thể là một trong những điều sau đây (SQL Server 2005+):

1. Lược đồ thay đổi.
2. Thống kê thay đổi.
3. Biên dịch lại DNR.
4. Đặt tùy chọn thay đổi.
5. Bảng tạm thời thay đổi.
6. Hàng từ xa thay đổi.
7. Để duyệt perms thay đổi.
8. Môi trường thông báo truy vấn đã thay đổi.
9. Quan điểm của Bộ KH & ĐT đã thay đổi.
10. Tùy chọn con trỏ thay đổi.
11. Với tùy chọn biên dịch lại.

Khai báo một biến - ngay cả một biến bảng (nghĩa là @table_variable) - rõ ràng không thể kích hoạt bất kỳ sự kiện nào trong số này, bởi vì khai báo một biến không được tính là DDL . Một biến (thậm chí là biến bảng) là một đối tượng tạm thời được sử dụng riêng cho lập trình T-SQL của bạn. Đó là lý do tại sao các biến bảng không có số liệu thống kê và không bị ràng buộc bởi các giao dịch . Khai báo một biến (bảng hoặc không) không thể kích hoạt biên dịch lại.

#temp_tableTuy nhiên, việc tạo bảng tạm thời (ví dụ ) hoặc chỉ mục là DDL ảnh hưởng đến định nghĩa vật lý của cơ sở dữ liệu. Các bảng và chỉ mục tạm thời là các đối tượng "thực" có thống kê và kiểm soát giao dịch, do đó, việc tạo chúng có thể kích hoạt bất kỳ sự kiện 1, 2 hoặc 5 nào trong danh sách trên và do đó kích hoạt tính năng biên dịch lại.

Nó không nên tạo ra sự khác biệt hoặc giảm các khóa biên dịch hoặc gây ra ít biên dịch lại để khai báo một biến xuống một nửa xuống ngăn xếp hoặc ở trên cùng. Tôi tình cờ làm điều này ở đầu để dễ đọc hơn không.

Để hiểu được phần "suy nghĩ về DBA của tôi" trong câu hỏi, điều duy nhất tôi có thể nghĩ ra (ngoài quan điểm của Nick là họ đang nghĩ về điều gì đó đã từng xảy ra) có lẽ họ đang nói về Parameter Sniffing (Xem Tùy chọn 2 tại liên kết này trong cuộc nói chuyện đơn giản)

Về việc chặn của bạn -> Nếu bạn đang thấy chặn thực sự, đó không phải là kiểu tranh chấp khóa biên dịch mà DBA của bạn đang nói đến rất có thể. Mặc dù đúng là có một số điều ảnh hưởng đến điều này (không phải là bảng đủ điều kiện lược đồ, không phải là lược đồ đủ điều kiện cho các cuộc gọi thủ tục được lưu trữ của bạn), đây không phải là nguyên nhân khiến bạn đọc cao và chắc chắn không phải là nguyên nhân khiến bạn bị chặn. Bạn chắc chắn nên làm tất cả những gì có thể để tránh các khóa biên dịch này. Nhưng tôi sẽ xem việc điều chỉnh và tối ưu hóa phần còn lại của mã thủ tục được lưu trữ là một nhiệm vụ quan trọng hơn là lo lắng về việc các biến ở đâu. Bạn cũng có thể đọc Cách xác định và giải quyết các khóa biên dịch nếu bạn muốn xác minh rằng bạn không gặp vấn đề ở đây.

Đăng những ví dụ trước / sau và chúng ta sẽ thấy DBA đang lái xe gì ở đây.