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


22

Vì varchar chiếm không gian đĩa tỷ lệ thuận với kích thước của trường, có lý do nào khiến chúng ta không nên luôn định nghĩa varchar là tối đa, ví dụ như varchar(8000)trên SQL Server không?

Trên bảng tạo, nếu tôi thấy ai làm varchar(100)tôi nên nói với họ rằng bạn không sai thì bạn nên làm gì varchar(8000)?


Tôi nghĩ rằng chúng ta phải phân biệt ở đây giữa việc sử dụng trong bảng tạo và sử dụng trong khai báo tham số của các thủ tục được lưu trữ. Đối với cách hiểu thứ hai, hãy xem câu hỏi của tôi dba.stackexchange.com/questions/1772/ory
bernd_k

Câu trả lời:


18
  • Độ dài là một ràng buộc đối với dữ liệu (như CHECK, FK, NULL, v.v.)
  • Hiệu suất khi hàng vượt quá 8060 byte
  • Không thể có ràng buộc hoặc chỉ mục duy nhất (độ rộng cột chính phải <900)
  • Mặc định là SET ANSI PADDING ON = tiềm năng cho nhiều khoảng trống được lưu trữ
  • SQL Server sẽ giả sử độ dài trung bình là 4000 cho các hoạt động sắp xếp, phân bổ bộ nhớ dựa trên điều này (cần tìm một liên kết để sao lưu này nhưng làm tôi khó chịu trong khi tôi làm :-)

Tóm tắt: đừng làm điều đó.


Hiệu suất khi hàng vượt quá 8060 byte . Điều đó đề cập đến các byte được sử dụng thực tế và không phải là các byte được phép tối đa?
bernd_k

@bernd_k: 8060 = lượng dữ liệu lớn nhất cho một hàng sẽ vừa với một trang 8192. Bao gồm hàng trên cao. Phần còn lại (132 byte) = chi phí trang
gbn

Điều đó có nghĩa là hiệu suất giảm khi kích thước lớn hơn thực sự được sử dụng, chứ không phải bởi thực tế thuần túy, nó được phép sử dụng.
bernd_k

@bernd_k: bất kỳ sự giảm hiệu năng nào là do 1. cấp phát bộ nhớ cho các loại vv 2. tràn hàng (> 8060 byte). Thực tế là có 10 ký tự trong mỗi varar (8000) là không liên quan cho đến khi các điều kiện này được đáp ứng (SQL sẽ cảnh báo về các lỗi tiềm ẩn sau này cho các khóa chỉ mục)
gbn

Việc sắp xếp một bảng có cột varchar (100) chứa đầy các trường có độ dài 100 byte có đáng để đặt câu hỏi khác không, bởi vì sắp xếp giả định trung bình là 50 ký tự?
bernd_k

7

Giả sử bạn đang đề cập đến SQL Server, tôi có thể nghĩ về một cái.

Có một giới hạn về kích thước (8K) của một hàng trong bảng và SQL cho phép bạn xác định các trường varchar có thể vượt quá giới hạn đó về mặt lý thuyết. Vì vậy, người dùng có thể gặp lỗi nếu họ đặt quá nhiều dữ liệu vào trường liên quan đến điều đó.

Bắt đầu với SQL 2K8, bạn có thể vượt quá giới hạn này, nhưng có ý nghĩa về hiệu suất .

Ngoài ra, có toàn bộ kiểm tra tính hợp lý của việc giới hạn kích thước cho những gì bạn mong đợi dữ liệu trông như thế nào. Nếu bạn muốn một trường có độ dài không giới hạn tại sao không đi với văn bản hoặc ntext?


Vì vậy, các loại dữ liệu văn bản và ntext được lưu trữ theo cách không ảnh hưởng đến hiệu suất?
Chad

Các loại đó không đóng góp nhiều vào giới hạn kích thước hàng 8K trên một bảng vì dữ liệu thực tế được lưu trữ trong một bảng riêng biệt dưới nắp thay vì nội tuyến với các cột còn lại. Vẫn có một tác động hiệu suất, nhưng vì những lý do khác nhau. Cũng có những hạn chế về hỗ trợ tính năng trên các lĩnh vực này khi so sánh với varchar và nvarchar
JohnFx

văn bản và ntext không được dùng để thay thế cho varchar (max).
Phil Helmer

3

Chắc chắn nó phụ thuộc vào thông tin nào đang được lưu trữ trong lĩnh vực này?

Một số thứ sẽ có độ dài tối đa vì một số lý do và nếu phải có độ dài tối đa thì đó phải là độ dài của trường của bạn.

Nếu về mặt lý thuyết không có độ dài tối đa thì tôi sẽ hỏi tại sao varchar sẽ được sử dụng.


3

Tôi bối cảnh của Cơ sở dữ liệu Oracle Tôi đã học được rằng luôn sử dụng kích thước trường nhỏ nhất cho các cột Cơ sở dữ liệu có một cạm bẫy.

Khi di chuyển dữ liệu thông qua xuất nhập từ cơ sở dữ liệu có đối chiếu byte đơn sang dữ liệu đối chiếu nhiều byte (như Oracle XE), độ dài tính theo byte có thể tăng và nhập dữ liệu vào các bảng được tạo bởi quá trình nhập thất bại. Tất nhiên, Oracle có tùy chọn để xác định độ dài varchar2 là char hoặc byte.

Quan điểm của tôi ở đây, là không phải lúc nào cũng là khôn ngoan để xác định trường luôn luôn nhỏ nhất có thể. Tôi đã thấy rất nhiều bảng thay đổi để tăng trường sau đó (do yêu cầu thay đổi).

Có 20% - 100% trường không sử dụng với là một lựa chọn có thể thảo luận ở đây.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.