Bảng so với hiệu suất bảng tạm thời

Question

Tốc độ nào nhanh hơn cho hàng triệu bản ghi: Bảng thường trực hoặc Bảng tạm thời?

Tôi chỉ sử dụng nó cho 15 triệu bản ghi. Sau khi xử lý xong, chúng tôi xóa các bản ghi này.

Answer 1

Trong trường hợp của bạn, chúng tôi sử dụng một bảng vĩnh viễn gọi là một bảng dàn dựng. Đây là một phương pháp phổ biến với nhập khẩu lớn. Trong thực tế, chúng tôi thường sử dụng hai bảng dàn một với dữ liệu thô và một với dữ liệu đã được làm sạch, giúp cho các vấn đề nghiên cứu dễ dàng hơn (chúng hầu như luôn là kết quả của các cách mới và đa dạng mà khách hàng của chúng tôi gửi cho chúng tôi dữ liệu rác) chúng ta phải chứng minh điều đó). Ngoài ra, bạn tránh các vấn đề như phải phát triển db tạm thời hoặc gây ra sự cố cho những người dùng khác muốn sử dụng db tạm thời nhưng phải đợi trong khi nó phát triển cho bạn, v.v.

Bạn cũng có thể sử dụng SSIS và bỏ qua bảng dàn), nhưng tôi thấy khả năng quay trở lại và nghiên cứu mà không cần phải tải lại một bảng 50.000.000 là rất hữu ích.

Answer 2

Bảng vĩnh viễn nhanh hơn nếu cấu trúc bảng là 100% giống nhau vì không có phí để phân bổ không gian và tạo bảng.

bảng Temp là nhanh hơn trong những trường hợp nhất định (ví dụ như khi bạn không cần phải chỉ có mặt trên bảng vĩnh viễn mà sẽ làm chậm chèn/cập nhật)

Answer 3

bảng Temp là trong bộ nhớ (trừ khi chúng quá lớn), vì vậy về mặt lý thuyết, chúng nên nhanh chóng thực sự. Nhưng thường thì không. Theo quy tắc chung, hãy cố gắng tránh xa các bảng tạm thời, trừ khi đó là giải pháp duy nhất. Bạn có thể cho chúng tôi biết thêm thông tin về những gì bạn đang cố gắng làm không? Nó có thể có thể được thực hiện với truy vấn có nguồn gốc

Answer 4

Bảng vĩnh viễn nhanh hơn trong hầu hết các trường hợp so với bảng tạm thời.

Có một cái nhìn về: http://www.sql-server-performance.com/articles/per/derived_temp_tables_p1.aspx

Answer 5

Cá nhân tôi sẽ sử dụng bảng vĩnh viễn và cắt bớt nó trước mỗi lần sử dụng. Theo kinh nghiệm của tôi, việc hiểu/duy trì dễ dàng hơn. Tuy nhiên, lời khuyên tốt nhất của tôi cho bạn là thử cả hai và xem cái nào hoạt động tốt hơn.

Answer 6

Nếu bạn không sử dụng tempdb, hãy đảm bảo mô hình khôi phục của cơ sở dữ liệu bạn đang làm việc không được đặt thành "Đầy đủ". Điều này sẽ gây ra rất nhiều chi phí trên những chèn hàng 50M.

Lý tưởng nhất là bạn nên sử dụng cơ sở dữ liệu dàn dựng, mô hình khôi phục đơn giản, trên RAID 10 nếu có thể và định kích thước trước để cung cấp đủ không gian cho tất cả các hoạt động của bạn. Tắt tự động phát triển.

Sử dụng INSERT ... VỚI (TABLOCK) để tránh row-level khai thác gỗ:

INSERT INTO StagingTable WITH (TABLOCK) (.....) 
SELECT ..... 

Tương tự như vậy cho BULK INSERT. Nếu bạn thả và tạo lại, hãy tạo chỉ mục nhóm trước để chèn. Nếu bạn không thể, hãy chèn vào một bảng trước, sau đó chèn từ bảng đó vào bảng khác với phân cụm đúng và cắt bớt bảng đầu tiên. Tránh kích thước lô nhỏ trên BULK INSERT nếu có thể. Đọc tài liệu BULK INSERT chặt chẽ, vì bạn có thể phá hoại hiệu suất với các tùy chọn sai.

Tránh INSERT ... EXEC. Mỗi hàng được ghi lại.

Tránh CẬP NHẬT, trừ khi bạn cần tính tổng chạy.Nói chung, nó rẻ hơn để chèn từ bảng này sang bảng khác, và sau đó cắt bớt bảng đầu tiên, thay vì cập nhật tại chỗ. Chạy tính toán tổng là ngoại lệ, vì chúng có thể được thực hiện với một UPDATE và các biến để tích lũy các giá trị giữa các hàng.

Tránh biến bảng cho bất kỳ điều gì ngoại trừ cấu trúc điều khiển, vì chúng ngăn chặn sự song song. Không tham gia bảng hàng 50M của bạn vào biến bảng, thay vào đó hãy sử dụng bảng tạm thời.

Đừng sợ con trỏ để lặp lại. Sử dụng các biến con trỏ và khai báo chúng với từ khóa STATIC đối với các cột có số lượng thấp ở phía trước chỉ mục nhóm. Sử dụng công cụ này để cắt các bảng lớn thành nhiều phần dễ quản lý hơn.

Đừng cố gắng làm quá nhiều trong bất kỳ tuyên bố nào.