Điều chỉnh hiệu suất đầu gối:Sử dụng sai bảng tạm thời

Trong phần tiếp theo của loạt bài "điều chỉnh hiệu suất giật đầu gối" của tôi, tôi muốn thảo luận về bốn vấn đề phổ biến mà tôi gặp khi sử dụng bảng tạm thời. Bất kỳ một trong những vấn đề này đều có thể làm tê liệt khối lượng công việc, vì vậy chúng đáng để biết và tìm kiếm trong môi trường của bạn.

Vấn đề 1:Sử dụng bảng tạm thời khi không cần thiết

Bảng tạm thời có nhiều cách sử dụng (có lẽ phổ biến nhất là để lưu trữ tập kết quả trung gian để sử dụng sau này), nhưng bạn phải nhớ rằng khi bạn đưa bảng tạm thời vào một truy vấn, bạn đang làm gián đoạn luồng dữ liệu thông qua bộ xử lý truy vấn.

Hãy coi tập hợp của một bảng tạm thời như một điểm dừng cứng, vì có một truy vấn (hãy gọi nó là trình tạo) để tạo ra tập kết quả trung gian, sau đó được lưu trữ trong bảng tạm thời trong tempdb và sau đó là truy vấn tiếp theo (hãy gọi người tiêu dùng) phải đọc lại dữ liệu từ bảng tạm thời.

Tôi thường thấy rằng một số phần của khối lượng công việc thực sự hoạt động tốt hơn khi bảng tạm thời bị loại bỏ hoàn toàn, do đó, dữ liệu chảy từ phần của nhà sản xuất của truy vấn đến phần của người tiêu dùng của truy vấn mà không cần phải duy trì trong tempdb và trình tối ưu hóa truy vấn có thể tạo ra một kế hoạch tổng thể tối ưu hơn.

Bây giờ bạn có thể đang nghĩ, "vậy tại sao ai đó lại sử dụng một chiếc bàn tạm thời nếu nó làm cho mọi thứ chậm hơn?" - và đúng như vậy! Trong những trường hợp như vậy, tôi nhận thấy rằng việc sử dụng một bảng tạm thời đã được thể chế hóa trong nhóm phát triển; ai đó nhận thấy rằng việc sử dụng bảng tạm thời đã tăng hiệu suất nhiều năm trước, vì vậy bảng tạm thời đã trở thành lựa chọn thiết kế mặc định.

Điều này có thể là một điều khó thay đổi, đặc biệt nếu bạn có nhà phát triển hoặc người quản lý cấp cao tin rằng các bảng tạm thời nên luôn được sử dụng. Điều đơn giản để thử là chọn một truy vấn đắt tiền (ví dụ:một truy vấn chạy lâu hoặc một truy vấn được thực thi nhiều lần mỗi giây) và xóa một hoặc nhiều bảng tạm thời để xem liệu hiệu suất có tăng lên mà không có chúng hay không. Và nếu vậy, có bằng chứng của bạn để hiển thị intransigents!

Vấn đề 2:Thiếu bộ lọc khi tạo bảng tạm thời

Ngay cả khi bạn không thể xóa một bảng tạm thời, bạn vẫn có thể cải thiện đáng kể hiệu suất bằng cách đảm bảo rằng mã điền vào bảng tạm thời đang lọc chính xác dữ liệu được lấy từ các bảng nguồn.

Tôi đã mất số lần nhìn thấy một bảng tạm thời được điền với mã bắt đầu là SELECT * , bao gồm một vài phép nối không ràng buộc và không có mệnh đề WHERE, sau đó truy vấn sử dụng bảng tạm thời sau đó chỉ sử dụng một vài cột và có mệnh đề WHERE để giảm số lượng hàng xuống rất nhiều.

Tôi nhớ một trường hợp, một bảng tạm thời trong một quy trình được lưu trữ đang tổng hợp dữ liệu trị giá 15 năm từ cơ sở dữ liệu chính, và sau đó chỉ dữ liệu của năm hiện tại được sử dụng. Điều này liên tục khiến tempdb tăng lên cho đến khi hết dung lượng trên ổ đĩa và sau đó quy trình được lưu trữ sẽ không thành công.

Bất cứ khi nào bạn điền một bảng tạm thời, chỉ sử dụng các cột của bảng nguồn cần thiết và chỉ sử dụng các hàng cần thiết - tức là đẩy các biến vị ngữ bộ lọc lên trong mã tổng thể bảng tạm thời. Điều này không chỉ giúp tiết kiệm dung lượng trong tempdb mà còn tiết kiệm rất nhiều thời gian để không phải sao chép dữ liệu không cần thiết từ bảng nguồn (và có khả năng loại bỏ nhu cầu đọc các trang cơ sở dữ liệu nguồn từ đĩa ngay từ đầu).

Sự cố 3:Lập chỉ mục bảng tạm thời không chính xác

Cũng giống như với các bảng thông thường, bạn chỉ nên tạo các chỉ mục thực sự sẽ được sử dụng bởi mã truy vấn sau này để giúp hiệu suất truy vấn. Tôi đã thấy nhiều trường hợp có một chỉ mục không hợp nhất cho mỗi cột bảng tạm thời và các chỉ mục một cột được chọn mà không phân tích mã sau này thường khá vô dụng. Bây giờ, hãy kết hợp các chỉ mục không hợp nhất vô dụng với việc thiếu bộ lọc khi điền bảng tạm thời và bạn đã có một công thức cho món tempdb khổng lồ.

Ngoài ra, nói chung, việc tạo chỉ mục sau khi bảng đã được điền sẽ nhanh hơn. Điều này mang lại phần thưởng bổ sung là các chỉ mục sẽ có số liệu thống kê chính xác, điều này có thể giúp ích nhiều hơn cho truy vấn vì trình tối ưu hóa truy vấn sẽ có thể thực hiện ước tính số lượng chính xác.

Việc có một loạt các chỉ mục không hợp nhất không được sử dụng làm lãng phí không chỉ dung lượng ổ đĩa mà còn tốn thời gian cần thiết để tạo chúng. Nếu đây là mã được thực thi thường xuyên, việc xóa các chỉ mục không cần thiết này được tạo mỗi khi mã chạy có thể có ảnh hưởng đáng kể đến hiệu suất tổng thể.

Vấn đề 4:Tranh chấp chốt tempdb

Khá phổ biến khi có một nút cổ chai chốt trong tempdb có thể bắt nguồn từ việc sử dụng bảng tạm thời. Nếu có nhiều kết nối đồng thời chạy mã tạo và xóa các bảng tạm thời, việc truy cập vào các bitmap cấp phát của cơ sở dữ liệu trong bộ nhớ có thể trở thành một nút thắt cổ chai đáng kể.

Điều này là do chỉ một luồng tại một thời điểm có thể thay đổi một bitmap phân bổ để đánh dấu các trang (từ bảng tạm thời) là được cấp phát hoặc đã phân bổ, và do đó, tất cả các luồng khác phải đợi, làm giảm thông lượng khối lượng công việc. Mặc dù đã có bộ đệm ẩn bảng tạm thời kể từ SQL Server 2005, nó không lớn lắm và có những hạn chế về thời điểm có thể lưu bảng tạm thời (ví dụ:chỉ khi nó có kích thước nhỏ hơn 8MB).

Các cách truyền thống để giải quyết vấn đề này là sử dụng cờ theo dõi 1118 và nhiều tệp dữ liệu tempdb (xem bài đăng trên blog này để biết thêm thông tin), nhưng một điều khác cần xem xét là xóa hoàn toàn các bảng tạm thời!

Tóm tắt

Bảng tạm thời có thể rất hữu ích, nhưng chúng rất dễ bị sử dụng sai cách. Bất cứ khi nào bạn đang viết (hoặc xem lại mã) đang sử dụng một bảng tạm thời, hãy xem xét những điều sau:

• Bảng tạm thời này có thực sự cần thiết ?
• Là mã điền vào bảng sử dụng đúng bộ lọc để giới hạn kích thước bảng tạm thời?
• Có phải các chỉ mục được tạo sau tổng số bảng (nói chung) và là chỉ mục đang được sử dụng bằng mã sau?

Paul White có một vài bài đăng tuyệt vời (tại đây và tại đây) về việc sử dụng đối tượng tạm thời và bộ nhớ đệm mà tôi cũng khuyên bạn nên đọc.

Và một điều cuối cùng, nếu bạn quyết định không sử dụng bảng tạm thời, đừng chỉ thay thế nó bằng một biến bảng, một biểu thức bảng thông thường hoặc một con trỏ (tất cả đều là những cách phổ biến mà mọi người cố gắng "tối ưu hóa" bảng tạm thời) - tìm ra cách hiệu quả nhất để (lại) viết mã - không có câu trả lời "một kích thước phù hợp với tất cả".

Cho đến lần sau, chúc bạn khắc phục sự cố!