Chiều rộng cột VARCHAR của SQL Server

Tìm kiếm trên web, tôi đã tìm thấy lời khuyên mâu thuẫn về việc liệu có tác động hiệu suất khi chỉ định các cột VARCHAR quá rộng, ví dụ VARCHAR (255) khi VARCHAR (30) có thể sẽ làm.

Tôi luôn thấy thỏa thuận rằng có một hiệu năng đạt được nếu toàn bộ hàng vượt quá 8060 byte. Khác hơn thế, tôi thấy bất đồng.

Là yêu cầu đúng sự thật The default is SET ANSI PADDING ON = potential for lots of trailing spaces? Miễn là tổng chiều rộng của hàng nhỏ hơn 8060, có bất kỳ mối quan tâm hiệu suất thực sự nào trong các cột VARCHAR quá cỡ không?

Bằng chứng là chiều rộng cột quan trọng

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

Hậu quả của việc thiết lập varchar (8000) là gì?

Bằng chứng là chiều rộng cột KHÔNG quan trọng

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

Câu hỏi có thể được nêu rõ hơn là:

"Lợi thế của việc chỉ định quá mức độ dài tối đa của cột có độ dài thay đổi là gì?"

Nói chung, có rất ít lợi thế và một số nhược điểm khi các câu trả lời được liên kết khác nhau chỉ ra. Ngoài bất kỳ mối quan tâm nào khác, hãy xem xét rằng SQL Server không phải là nguồn mở: có nhiều 'số ma thuật' và phương pháp phỏng đoán được áp dụng dựa trên thông tin được cung cấp cho hệ thống. Không có quyền truy cập mã nguồn, chúng tôi không bao giờ có thể hoàn toàn chắc chắn tác động của thực tiễn này có thể là gì.

Trong một số trường hợp , khi độ dài trung bình của cột cao hơn đáng kể so với 50% được giả định bởi SQL Server khi tính toán cấp bộ nhớ sắp xếp / băm, bạn có thể thấy sự cải thiện hiệu suất bằng cách chỉ định quá mức độ dài tối đa. Đây là một cách giải quyết đáng ngờ và có lẽ chỉ nên được áp dụng bởi một từ rõ ràng CASThoặc CONVERT(có ý kiến!) Thay vì thay đổi định nghĩa cột cơ sở. Đôi khi, tốt hơn là nên viết lại truy vấn để sắp xếp các khóa thay vì toàn bộ các hàng.

Trong trường hợp kích thước hàng tối đa có thể vượt quá giới hạn trong hàng (ngay cả khi không có hàng nào thực sự làm), việc xóa các hàng có thể gây ra sự chia tách trang không mong muốn nếu có trình kích hoạt. Cập nhật cũng có thể dẫn đến phân mảnh thông qua cơ chế tương tự.

SQL Server thực hiện công việc khá tốt trong hầu hết các trường hợp được cung cấp thông tin chính xác, tốt từ siêu dữ liệu. Thỏa hiệp nguyên tắc này cho 'sự thuận tiện' dường như không khôn ngoan đối với tôi. Một cách tiếp cận hợp lý là chọn giá trị độ dài tối đa hợp lý theo dữ liệu thực tế sẽ được lưu trữ và mọi thay đổi có thể thấy trước.

NHƯ bạn đã chỉ định, miễn là kích thước hàng không vượt quá 8060 (hoặc bất kỳ mức tối đa nào được đặt thành), không có sự khác biệt về hiệu suất khi sử dụng VARCHAR (30) hoặc VARCHAR (255) hoặc lớn hơn. So sánh CHAR với VARCHAR từ bài viết được liên kết không thực sự thích hợp. Mặc dù tôi đồng ý rằng bạn không nên chỉ định nhiều không gian hơn bạn chắc chắn rằng bạn cần, nhưng trong nhiều trường hợp bạn không biết mình thực sự cần bao nhiêu dung lượng. Vì vậy, hãy tự do với không gian VARCHAR - Tôi khá chắc chắn rằng việc tăng kích thước của các trường yêu cầu xây dựng lại bảng, trong khi giảm là một câu lệnh ALTER TABLE đơn giản.