SQL Server - Bảng tạm thời so với bảng vật lý

Một phong trào đang diễn ra ở nơi tôi sử dụng lao động để tránh sử dụng các bảng #temp và thay vào đó để sử dụng các bảng vật lý vĩnh viễn với SPID. Bất cứ khi nào trước đây người ta đã CHỈ VÀO một bảng #temp, thì bây giờ INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)bắt buộc phải có - cùng với một loạt các DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDcâu lệnh ở đầu ví dụ như một thủ tục được lưu trữ. Ngoài ra, không cần phải nói rằng bất cứ nơi nào mà các 'bảng cố định để lưu trữ dữ liệu tạm thời' này được sử dụng, người ta phải cẩn thận để bao gồm một WHERE SPID = @@SPID.

Logic đằng sau động thái hướng tới thực tiễn này là nó sẽ cải thiện hiệu suất tổng thể của máy chủ nơi các truy vấn đang chạy (bằng cách giảm I / O và tranh chấp trong tempdb). Tôi không quan tâm đến phương pháp này vì một số lý do - nó xấu, có khả năng nguy hiểm và có vẻ như nó có thể gây hại cho hiệu suất của những truy vấn sử dụng lược đồ mới.

Có ai có bất kỳ kinh nghiệm nào với cách tiếp cận này hoặc tương tự để loại bỏ các bảng #temp không?

Nó có thể được chứng minh khá dễ dàng rằng nó sẽ không làm giảm IO cũng như sự tranh chấp, mà thay vào đó tăng cả hai.

• IO : Mỗi hàng được chèn, đọc hoặc xóa khỏi bảng #temp sẽ được chèn, đọc hoặc xóa khỏi bảng @@ SPID. Nhưng mỗi hàng sẽ rộng hơn với một cột @@ SPID bổ sung, do đó số lượng trang cần thiết sẽ tăng lên một chút và IO sẽ lớn hơn một chút. Nhưng quan trọng hơn, việc thả bảng #temp và khởi tạo bảng #temp của phiên mới bằng một phiên bây giờ sẽ phải được mô phỏng với một hoạt động DELETE FROM @@spidTable WHERE spid = @@SPID, do đó, cắt ngắn / tạo hoạt động (nghĩa là hoạt động quản lý phạm vi trang) sẽ được chuyển đổi trong hoạt động hàng, không thể so sánh chậm hơn.
• Sự tham gia : Mọi lần quét đang sử dụng khóa trang trên bảng #temp giờ đây sẽ có khả năng khóa một trang với các hàng spid không liên quan, do đó tạo ra sự tranh chấp không tồn tại trước đó. Mỗi bản cập nhật nào đạt đến ngưỡng leo thang khóa đều có cơ hội leo thang khóa sang khóa bảng và do đó chặn mọi spid khác.

Vì vậy, trong khi sự thật là bạn sẽ không gặp phải sự tranh chấp IAM / SGAM / GAM huyền thoại trong tempdb, lý do duy nhất tại sao điều này xảy ra là do hoạt động của bạn sẽ trở nên chậm hơn do có thêm IO thông thường và tranh chấp thêm.

Đây dường như là một giải pháp quyết liệt. Có nhiều bài viết trực tuyến về việc giảm sự tranh chấp tempdb (và tối ưu hóa việc sử dụng nó) - bạn đã kiểm tra kỹ lưỡng con đường đó chưa?

http://www.sql-server-performance.com/tips/tempdb_p1.aspx

http://www.sqlservercentral.com/bloss/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

http://searchsqlserver.techtarget.com/tip/Optizes-tempdb-in-Query-Server-by-striping-and-splspl-to-mult Môn-files

Vân vân.

Âm thanh với tôi như bạn nên khắc phục sự cố hiệu suất trong tempDB, có một vài đề xuất ở đây