MySQL: Великий VARCHAR проти ТЕКСТУ?

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

Чи є обґрунтування для того, щоб їхати або з VARCHAR (3000), або з TEXT? Існує щось про те, щоб просто написати VARCHAR (3000), який відчуває себе дещо контрінтуїтивним. Я переглядав інші подібні публікації на стеку Overflow, але було б добре отримати перегляди, характерні для цього типу загального зберігання повідомлень.

• TEXTі BLOB може зберігатися поза таблицею, якщо таблиця просто має вказівник на місце фактичного зберігання. Де він зберігається, залежить від багатьох речей, таких як розмір даних, розмір стовпців, рядок_формату та версія MySQL.

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

Чи можете ви передбачити, як довго триватиме введення користувача?

ВАРХАР (X)

Випадок: ім’я користувача, електронна адреса, країна, тема, пароль

---

ТЕКСТ

Випадок: повідомлення, електронні листи, коментарі, відформатований текст, html, код, зображення, посилання

---

MEDIUMTEXT

Корпус: великі тіла json, книги короткої та середньої довжини, рядки csv

---

ДОВГОТЕКСТ

Випадок: підручники, програми, літні файли журналів, Гаррі Поттер та кубок вогню, наукові дослідження

Просто для уточнення найкращої практики:

1. Повідомлення у форматі тексту майже завжди повинні зберігатися як TEXT (вони в кінцевому підсумку є довільно довгими)

2. Атрибути рядків повинні зберігатися як VARCHAR (ім'я користувача призначення, тема тощо).

Я розумію, що у вас є обмеження на передньому кінці, що чудово, поки його немає. * grin * Хитрість полягає в тому, щоб БД розглядалася як окрема від додатків, які до неї підключаються. Тільки тому, що одна програма ставить обмеження на дані, не означає, що дані суттєво обмежені.

Що саме щодо самих повідомлень змушує їх ніколи не бути більше 3000 символів? Якщо це просто довільне обмеження програми (скажімо, для текстового поля чи чогось іншого), використовуйте TEXTполе на рівні даних.

Відмова: Я не експерт MySQL ... але це моє розуміння проблем.

Я думаю, що TEXT зберігається поза рядком mysql, тоді як я думаю, що VARCHAR зберігається як частина рядка. Максимальна довжина рядків для рядків mysql .. тому ви можете обмежити кількість інших даних, які ви можете зберігати в рядку, використовуючи VARCHAR.

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

Коротка відповідь: різниця в практиці, продуктивності та зберіганні.

Довга відповідь:

По суті немає різниці (в MySQL) між VARCHAR(3000)(або будь-яким іншим великим лімітом) і TEXT. Перший уріжеться на 3000 символів ; останній скорочується на рівні 65535 байт . (Я розрізняю байти і символи, оскільки персонаж може приймати кілька байтів.)

Що стосується менших обмежень в VARCHAR, є деякі переваги порівняно TEXT.

• "менший" означає 191, 255, 512, 767 або 3072 тощо, залежно від версії, контексту та CHARACTER SET.
• INDEXesобмежені тим, наскільки великий стовпчик може бути індексований. (767 або 3072 байти ; це залежить від версії та налаштувань)
• Проміжні таблиці, створені комплексом SELECTs, обробляються двома різними способами - MEMORY (швидше) або MyISAM (повільніше). Якщо задіяні "великі" стовпці, автоматично вибирається повільна техніка. (Суттєві зміни, що надходять у версії 8.0; тому цей пункт із кулькою може бути змінений.)
• Стосовно попереднього пункту, всі TEXTтипи даних (на відміну від VARCHAR) переходять прямо до MyISAM. Тобто, TINYTEXTавтоматично генерується для генерованих темп-таблиць, ніж еквівалент VARCHAR. (Але це сприймає дискусію в третьому напрямку!)
• VARBINARYце як VARCHAR; BLOBце як TEXT.

Спростування інших відповідей

Оригінальне запитання задало одне (який тип даних використовувати); прийнята відповідь відповіла на щось інше (зберігання поза записом). Ця відповідь застаріла.

Коли цей потік був запущений і відповів, у InnoDB було лише два "формати рядків". Незабаром були введені ще два формати ( DYNAMICі COMPRESSED).

Місце зберігання для TEXTта VARCHAR()засноване на розмірі , а не на назві типу даних . Для оновленого обговорення зберігання великих / стовпчиків тексту / блоку див. Це .

Попередні відповіді недостатньо наполягають на головній проблемі: навіть у дуже простих запитах, таких як

(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id) 

може знадобитися тимчасова таблиця, а якщо VARCHARзадіяне поле, воно перетворюється на CHARполе у ​​тимчасовій таблиці. Отже, якщо у вашій таблиці скажіть 500 000 рядків із VARCHAR(65000)полем, цей стовпець лише буде використовувати 6,5 * 5 * 10 ^ 9 байт. Такі таблиці темп не обробляються в пам'яті і записуються на диск. Очікується, що вплив буде катастрофічним.

Джерело (з показниками): https://nicj.net/mysql-text-vs-varchar-performance/ (Це стосується обробки TEXTVS VARCHARв "стандартному" (?) Двигуні зберігання MyISAM. Він може бути різним в інших, наприклад, InnoDB.)

Існує велика різниця між VARCHAR і TEXT. Хоча поля VARCHAR можна індексувати, поля TEXT не можуть. Поля типу VARCHAR зберігаються вбудованим, тоді як TEXT зберігається в автономному режимі, лише вказівники на дані TEXT фактично зберігаються в записах.

Якщо вам доведеться проіндексувати своє поле для швидшого пошуку, оновлення чи видалення, ніж для VARCHAR, незалежно від величини. VARCHAR (10000000) ніколи не буде збігатися з полем TEXT, оскільки ці два типи даних відрізняються за своєю суттю.

• Якщо ви використовуєте поле лише для архівації
• вам не байдуже відновлення швидкості передачі даних
• вам важлива швидкість, але ви будете використовувати оператор "LIKE%" у своєму пошуковому запиті, тому індексація не допоможе багато
• не можна передбачити обмеження довжини даних

ніж їхати на TEXT.

Varchar призначений для невеликих даних, таких як адреси електронної пошти, тоді як Text - для набагато більших даних, таких як статті новин, Blob для бінарних даних, таких як зображення.

Продуктивність Varchar є більш потужною, оскільки вона працює повністю з пам'яті, але це не буде так, якщо дані занадто великі, varchar(4000)наприклад.

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

Blob набагато повільніше, тому використовуйте його, лише якщо у вас немає таких даних, як 10000 зображень, які коштують 10000 записів.

Дотримуйтесь цих порад щодо максимальної швидкості та продуктивності:

1. Використовуйте varchar для імені, назв, електронних листів

2. Використовуйте текст для великих даних

3. Відокремлений текст у різних таблицях

4. Використовуйте запити зліва приєднатися до ідентифікатора, такого як номер телефону

5. Якщо ви збираєтесь використовувати Blob, застосовуйте ті самі поради, що і в тексті

Це зробить запити в мілісекундах на таблицях з даними> 10 М та розміром до 10 ГБ.