Làm thế nào để các cột dài ảnh hưởng đến hiệu suất và việc sử dụng đĩa?

Trong dự án hiện tại của chúng tôi, điều đó xảy ra quá thường xuyên, rằng chúng tôi cần mở rộng các cột bằng một vài ký tự. Từ varchar(20)đến varchar(30)và như vậy.

Trong thực tế, nó thực sự quan trọng đến mức nào? Làm thế nào tốt là tối ưu hóa này? Tác động của việc chỉ cho phép 100 hoặc 200 hoặc thậm chí 500 ký tự cho các trường "đầu vào" bình thường là gì? Một email chỉ có thể có 320 ký tự, vì vậy ok - có một giới hạn tốt ở đó. Nhưng tôi sẽ đạt được gì nếu tôi đặt nó thành 200, vì tôi không mong đợi địa chỉ email dài hơn thế.

Thông thường các bảng của chúng tôi sẽ không có hơn 100.000 hàng và tối đa 20 hoặc 30 cột như vậy.

Chúng tôi sử dụng SQL Server 2008 ngay bây giờ, nhưng thật thú vị khi biết các DB khác nhau xử lý vấn đề này như thế nào.

Trong trường hợp tác động rất thấp - như tôi mong đợi, sẽ giúp có được một số lý lẽ tốt (được sao lưu bằng các liên kết?) Để thuyết phục DBA của tôi, rằng sự hoang tưởng trường dài này không thực sự cần thiết.

Trong trường hợp đó, tôi ở đây để tìm hiểu :-)

Câu trả lời cụ thể cho câu hỏi của bạn (ít nhất là đối với Oracle và có lẽ các cơ sở dữ liệu khác) là độ dài của trường không quan trọng, chỉ có độ dài của dữ liệu. Tuy nhiên, điều này không nên được sử dụng như một yếu tố quyết định liên quan đến việc có nên đặt trường thành độ dài tối đa cho phép của nó hay không. Dưới đây là một số vấn đề khác bạn nên xem xét trước khi tối đa hóa kích thước trường.

Định dạng Bất kỳ công cụ máy khách nào định dạng dữ liệu dựa trên kích thước của các trường sẽ yêu cầu xem xét định dạng đặc biệt. Ví dụ, SQL * Plus của Oracle hiển thị kích thước tối đa của các cột Varchar2 ngay cả khi dữ liệu chỉ dài một ký tự. Đối chiếu…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Độ dài trường dữ liệu xấu cung cấp một cơ chế bổ sung để bắt / ngăn dữ liệu xấu. Một giao diện không nên cố gắng chèn 3000 ký tự vào trường 100 ký tự, nhưng nếu trường đó được xác định là 4000 ký tự, thì nó chỉ có thể. Lỗi sẽ không bị bắt ở giai đoạn nhập dữ liệu, nhưng hệ thống có thể gặp sự cố thêm khi ứng dụng khác cố xử lý dữ liệu và cuộn cảm. Ví dụ, nếu sau này bạn quyết định lập chỉ mục trường trong Oracle, bạn sẽ vượt quá độ dài khóa tối đa (tùy thuộc vào kích thước khối và nối). Xem…

create index i1 on f1(a);

Bộ nhớ Nếu ứng dụng khách phân bổ bộ nhớ bằng kích thước tối đa, ứng dụng sẽ phân bổ bộ nhớ nhiều hơn đáng kể so với mức cần thiết. Những cân nhắc đặc biệt sẽ phải được thực hiện để tránh điều này.

Tài liệu Kích thước của trường cung cấp một điểm dữ liệu khác của tài liệu về dữ liệu. Chúng ta có thể gọi tất cả các bảng t1, t2, t3, v.v. và tất cả các trường F1, f2, f3, v.v., nhưng bằng cách chỉ định các tên có ý nghĩa, chúng ta hiểu rõ hơn về dữ liệu. Ví dụ: nếu một bảng địa chỉ cho một công ty có khách hàng ở Mỹ có một trường có tên là State là hai ký tự, chúng tôi hy vọng hai chữ viết tắt trạng thái sẽ đi vào đó. Mặt khác, nếu trường là một trăm ký tự, chúng ta có thể mong đợi tên trạng thái đầy đủ sẽ đi vào trường.

Tất cả những gì đang được nói, có vẻ thận trọng để chuẩn bị cho sự thay đổi. Chỉ vì tất cả tên sản phẩm của bạn ngày hôm nay phù hợp với 20 ký tự không có nghĩa là chúng sẽ luôn như vậy. Đừng quá nhiệt tình và kiếm 1000, nhưng hãy chừa chỗ cho việc mở rộng hợp lý.

Đây là một điểm khởi đầu tốt cho bạn.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Tôi có thể đã hiểu nhầm câu hỏi ban đầu của bạn. Hãy để tôi xem nếu tôi có thể tìm thấy bạn một vài liên kết khác để tham khảo.

Dưới đây là tài liệu tham khảo tốt về các lựa chọn loại dữ liệu: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Thay đổi từ varchar (20) sang varchar (30) có vẻ như là một cái gì đó nhỏ, nhưng bạn cần hiểu thêm về cách cấu trúc cơ sở dữ liệu hoạt động để nhận thức được các vấn đề tiềm ẩn. Ví dụ: đi tới varchar (30) có thể đẩy bạn vượt qua điểm tới hạn của các cột (nếu tất cả 30 byte được sử dụng) có thể được lưu trữ trên một trang (dưới 8060 byte). Điều này sẽ dẫn đến sự gia tăng không gian đĩa được sử dụng, giảm hiệu suất và thậm chí một số chi phí bổ sung với nhật ký giao dịch của bạn.

Đây là một liên kết cho các cấu trúc cơ sở dữ liệu: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Đây là một phần để phân chia trang và ghi nhật ký trx: http://sqlskills.com/BLOGS/PAUL/post/How-Exensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

Tôi nghĩ rằng tôi muốn chia sẻ một điểm thú vị khác, mà tôi đã tìm thấy trong Câu hỏi SO sau đây:

https://stackoverflow.com/questions/148398/are-there-any-disabilitiesages-to-always-USE-nvarcharmax

Câu trả lời gốc của: Nick Kavadias

Một lý do KHÔNG nên sử dụng các trường tối đa hoặc văn bản là bạn không thể thực hiện [xây dựng lại chỉ mục trực tuyến] [1] tức là REBUILD VỚI ONLINE = ON ngay cả với SQL Server Enterprise Edition.

[1]: http://msdn.microsoft.com/en-us/l Library / ms188388% 28Query.90% 29.aspx "xây dựng lại chỉ mục trực tuyến"

Tôi sẽ coi đây là một bất lợi lớn khi thêm các cột n / varchar (max) một cách tùy ý và theo Trang web của MS, hạn chế này đối với việc xây dựng lại chỉ mục trực tuyến vẫn còn trong SQL Server 2008, 2008 R2 và Denali; vì vậy nó không dành riêng cho SQL Server 2005.

Cảm ơn, Jeff

Trong một số trường hợp, lượng không gian bạn phân bổ cho trường varchar sẽ ảnh hưởng đến lượng bộ nhớ được phân bổ cho các loại trong bộ nhớ.

Tôi thấy các bài thuyết trình tại SQLWorkairs.com nghĩ là kích động, bài thuyết trình này nói về một trường hợp sắp xếp thứ tự bằng cách tràn vào tempdb vì không đủ bộ nhớ được phân bổ cho các trường char / varchar.

http://webcasts2.sqlworkairs.com/webcasts.asp

Webcast này cũng đã được trình bày như một bài viết tại trang web sau:

http://www.mssqltips.com/tip.asp?tip=1955

Lưu ý trong phần trình bày này rằng cột được sắp xếp không phải là cột char / varchar, nhưng lượng không gian được phân bổ cho cột varchar trong bộ nhớ tạo ra sự khác biệt trong hiệu suất truy vấn trong một số trường hợp.

THIẾT LẬP ANSI_PADDING TRÊN?

Bạn kết thúc với rất nhiều khoảng trắng theo sau ...

Nó chỉ quan trọng liên quan đến không gian đĩa và độ dài ký tự. Tất nhiên tìm kiếm trên các loại dữ liệu char và chỉ mục trên các loại dữ liệu này sẽ hoạt động chậm hơn số nguyên nhưng đây là một cuộc thảo luận khác.

Kiểu dữ liệu Varchar là kiểu dữ liệu "biến", vì vậy nếu bạn thiết lập giới hạn varchar (500) thì đây là độ dài ký tự tối đa cho trường đó. Độ dài tối thiểu có thể từ 0 đến 500. Mặt khác, không gian đĩa được yêu cầu sẽ khác nhau cho các trường 10, 30 hoặc 500 ký tự.

Đôi khi tôi đã thực hiện một thử nghiệm cho varchar loại dữ liệu (800) và đối với các giá trị null tôi có 17 byte được sử dụng và với mỗi ký tự được chèn, nó thêm một byte nữa. Ví dụ, một chuỗi 400 ký tự có 417 byte được sử dụng trên đĩa.

Tôi không nghĩ rằng có sự khác biệt giữa các bảng được tạo với các cột varchar (20) hoặc varchar ((8000), miễn là độ dài tối đa thực tế là <= 20.

Mặt khác, trong một số trường hợp, việc cung cấp cho người dùng khả năng lưu trữ các chuỗi dài hơn có thể khuyến khích họ làm điều đó.