Як довгі стовпці впливають на продуктивність та використання диска?

У нашому поточному проекті дуже часто трапляється, що нам потрібно розширити стовпчики на пару символів. Від varchar(20)до varchar(30)і так далі.

Справді, наскільки це насправді має значення? Наскільки це оптимізовано? Який вплив просто дозволити 100, 200 або навіть 500 символів для нормальних "вхідних" полів? Електронний лист може мати лише 320 символів, так що нормально - там є хороший ліміт. Але що я отримую, якщо встановити його на 200, тому що я не очікую довгих електронних адрес, ніж це.

Зазвичай наші таблиці не матимуть більше 100 000 рядків та до 20 або 30 таких стовпців.

Зараз ми використовуємо SQL Server 2008, але було б цікаво дізнатися, як різні БД вирішують ці проблеми.

У випадку, якщо вплив буде дуже низьким - як я б очікував, це допоможе отримати кілька хороших аргументів (підкріплених посиланнями?), Щоб переконати мого DBA, що ця параноя на довгому полі не дуже потрібна.

У випадку, якщо це так, я тут, щоб навчитися :-)

Конкретна відповідь на ваше запитання (принаймні для Oracle та, ймовірно, інших баз даних) полягає в тому, що довжина поля не має значення, а лише довжина даних. Однак це не повинно використовуватися як визначальний фактор щодо того, встановлювати поле максимальною допустимою довжиною чи ні. Ось деякі інші проблеми, які слід розглянути, перш ніж збільшити розміри полів.

Форматування Будь-який клієнтський інструмент, який форматує дані залежно від розміру полів, потребує особливих міркувань щодо форматування. Наприклад, SQL * Plus Oracle * Plus, за замовчуванням, відображає максимальний розмір стовпців Varchar2, навіть якщо дані мають лише один символ. Порівняти…

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;

Неправильна довжина поля даних забезпечує додатковий механізм для збору / запобігання поганих даних. Інтерфейс не повинен намагатися вставити 3000 знаків у поле 100 символів, але якщо це поле визначено як 4000 символів, воно може просто. Помилка не буде виявлена ​​на етапі введення даних, але система може мати проблеми з подальшим знищенням, коли інша програма намагається обробити дані та задихається. Наприклад, якщо ви пізніше вирішите індексувати поле в Oracle, ви перевищили б максимальну довжину ключа (залежно від розміру блоку та конкатенації). Побачити…

create index i1 on f1(a);

Пам'ять Якщо клієнтська програма виділяє пам'ять, використовуючи максимальний розмір, програма виділить значно більше пам'яті, ніж потрібно. Щоб уникнути цього, слід зробити особливі міркування.

Документація Розмір поля забезпечує ще одну точку даних документації про дані. Ми можемо називати всі таблиці t1, t2, t3 і т. Д. І всі поля f1, f2, f3 і т.д., але, вказуючи значущі імена, ми краще розуміємо дані. Наприклад, якщо в таблиці адрес для компанії з клієнтами в США є поле під назвою State, яке є двома символами, ми очікуємо, що в ньому ввійде абревіатура стану двох символів. З іншого боку, якщо поле має сто символів, ми можемо очікувати, що в ньому буде вказано повне ім'я стану.

Все, що говорити, здається доцільним бути готовим до змін. Тільки тому, що всі назви ваших продуктів сьогодні вміщують 20 символів, не означає, що вони завжди будуть. Не переходьте за борт і зробіть це 1000, але не залишайте місця для правдоподібного розширення.

Ось вам вдалий вихідний пункт.

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

Можливо, я неправильно зрозумів ваше первісне запитання. Дозвольте мені побачити, чи можу я знайти вам кілька інших посилань для ознайомлення.

Ось хороша довідка щодо вибору типів даних: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Перехід від varchar (20) до varchar (30) може здатися чимось невеликим, але вам потрібно більше зрозуміти, як працюють структури бази даних, щоб бути в курсі потенційних проблем. Наприклад, перехід до varchar (30) може проштовхнути вас через точку відбиття ваших стовпців (якщо всі 30 байт звикнути), щоб вони могли зберігатися на одній сторінці (менше 8060 байт). Це призведе до збільшення використовуваного дискового простору, зниження продуктивності та навіть додаткових накладних витрат із журналами транзакцій.

Ось посилання на структури баз даних: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Ось один з розділів сторінки та ведення журналу trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

Я думав, що поділюсь ще одним цікавим моментом, який я знайшов у наступному питанні:

/programming/148398/are-there-any-disasures-to-always-using-nvarcharmax

Оригінальна відповідь: Нік Кавадіас

Причина НЕ використовувати максимум або текстові поля полягає в тому, що ви не можете виконати [інтерактивне відновлення індексів] [1], тобто ЗАБУДОВАЄТЬСЯ З ONLINE = УВІМКНЕНО навіть із програмою SQL Server Enterprise Edition.

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "індекс перебудовується"

Я вважаю це великим недоліком при додаванні стовпців n / varchar (max) довільно, і згідно з веб-сайтом MS, це обмеження щодо відновлення оновлень в Інтернеті залишається в SQL Server 2008, 2008 R2 та Denali; тому це не характерно для SQL Server 2005.

Спасибі, Джеффе

У деяких випадках кількість місця, яке ви виділите для поля вархар, впливатиме на об'єм пам'яті, виділений для сортування в пам'яті.

Я виявив, що презентації на SQLWorkshops.com вважають провокуючим, ця презентація розповідає про випадок, коли сортування замовлення від переливається в tempdb, оскільки для полів char / varchar виділяється недостатньо пам'яті.

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

Ця веб-трансляція була також представлена ​​як стаття на наступному веб-сайті:

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

Зауважте у цій презентації, що стовпець, відсортований не є стовпцем char / varchar, але кількість місця, виділеного для стовпчика varchar у пам’яті, в деяких випадках відрізняє ефективність запиту.

ВКЛЮЧЕНО ANSI_PADDING?

У вас виходить багато пробілів пробілів ...

Це має значення лише для місця на диску та довжини символів. Звичайно, пошук типів даних char та індексів цих типів даних діятиме повільніше, ніж цілочисельний, але це ще одна дискусія.

Тип даних Varchar - це "змінний" тип даних, тому якщо ви встановите ліміт varchar (500), це максимальна довжина символу для цього поля. Мінімальна довжина може становити від 0 до 500. З іншого боку, заявлене місце на диску буде різним для полів 10, 30 або 500 символів.

Я іноді робив тест на тип даних varchar (800) і на нульові значення, я використовував 17 байтів, і для кожного вставленого символу додавали ще один байт. Наприклад, рядок на 400 символів мав на диску 417 байт.

Я не думаю, що є різниця між таблицями, створеними стовпцями varchar (20) або varchar ((8000), доки фактична максимальна довжина <= 20.

З іншого боку, в деяких випадках надання користувачам можливості зберігати довші рядки може спонукати їх до цього.