Không có DBMS nào mà tôi biết có bất kỳ "tối ưu hóa" nào sẽ tạo ra VARCHAR với 2^n chiều dài hoạt động tốt hơn chiều dài có max chiều dài không phải là lũy thừa của 2.
Tôi nghĩ rằng các phiên bản SQL Server đầu tiên thực sự xử lý VARCHAR có chiều dài 255 khác với chiều dài có chiều dài tối đa cao hơn. Tôi không biết nếu vẫn còn trường hợp này.
Đối với hầu hết tất cả DBMS, dung lượng lưu trữ thực tế được yêu cầu chỉ được xác định bởi số ký tự bạn đưa vào nó, không phải max độ dài bạn xác định. Vì vậy, từ quan điểm lưu trữ (và hầu hết có thể là một hiệu suất), không có bất kỳ sự khác biệt nào cho dù bạn khai báo một cột là VARCHAR(100) hoặc VARCHAR(500) .
Bạn sẽ thấy max độ dài được cung cấp cho một VARCHAR là một loại ràng buộc (hoặc quy tắc kinh doanh) chứ không phải là một thứ kỹ thuật / vật lý.
Đối với PostgreSQL, cách thiết lập tốt nhất là sử dụng text không giới hạn độ dài và CHECK CONSTRAINT giới hạn số lượng ký tự ở bất kỳ số lượng ký tự nào mà doanh nghiệp của bạn yêu cầu.
Nếu yêu cầu đó thay đổi, việc thay đổi ràng buộc kiểm tra nhanh hơn nhiều so với việc thay đổi bảng (vì bảng không cần phải viết lại)
Điều tương tự cũng có thể được áp dụng cho Oracle và các hãng khác - trong Oracle, nó sẽ là VARCHAR(4000) thay vì text Tuy nhiên.
Tôi không biết liệu có sự khác biệt về bộ nhớ thực giữa VARCHAR(max) hay không và v.d. VARCHAR(500) trong SQL Server. Nhưng dường như có tác động về hiệu suất khi sử dụng varchar(max) so với varchar(8000) .
Xem liên kết này (được đăng bởi Erwin Brandstetter dưới dạng bình luận)
Chỉnh sửa 2013-09-22
Về bình luận của bigown:
Trong các phiên bản Postgres trước 9.2 (không có sẵn khi tôi viết câu trả lời ban đầu), một thay đổi đối với định nghĩa cột did viết lại toàn bộ bảng, xem ví dụ: tại đây . Vì 9.2, điều này không còn đúng nữa và một thử nghiệm nhanh đã xác nhận rằng việc tăng kích thước cột cho một bảng có 1,2 triệu hàng thực sự chỉ mất 0,5 giây.
Đối với Oracle, điều này dường như cũng đúng, xét theo thời gian cần thiết để thay đổi varchar của một bảng lớn cột. Nhưng tôi không thể tìm thấy bất kỳ tài liệu tham khảo nào cho điều đó.
Đối với MySQL, hướng dẫn sử dụng cho biết
" Trong hầu hết các trường hợp, ALTER TABLE tạo bản sao tạm thời của bảng gốc ". Và các thử nghiệm của riêng tôi xác nhận rằng:chạy ALTER TABLE trên một bảng có 1,2 triệu hàng (giống như trong thử nghiệm của tôi với Postgres) để tăng kích thước của một cột mất 1,5 phút. Tuy nhiên, trong MySQL, bạn có thể không sử dụng "giải pháp thay thế" để sử dụng ràng buộc kiểm tra nhằm giới hạn số ký tự trong một cột.
Đối với SQL Server, tôi không thể tìm thấy tuyên bố rõ ràng về điều này nhưng thời gian thực thi để tăng kích thước của varchar (lại là bảng 1,2 triệu hàng từ trên) chỉ ra rằng không viết lại diễn ra.
Chỉnh sửa 2017-01-24
Có vẻ như tôi đã sai (ít nhất một phần) về SQL Server. Xem câu trả lời này từ Aaron Bertrand
điều đó cho thấy rằng độ dài được khai báo của nvarchar hoặc varchar cột tạo ra sự khác biệt lớn cho hiệu suất.
