Есть ли у кого-нибудь какое-либо сравнение, личный опыт или рекомендации, когда использовать тип text вместо большого varchar в MySQL?Каковы реальные последствия использования текста вместо типов varchar в MySQL?
Хотя большинство записей в моей базе данных будут содержать менее 1000 символов, некоторые могут занимать до 4000 символов и более. Какова предельная длина varchar, которая делает text лучшим вариантом?
Мне не нужно индексировать эти поля.
У меня нет личного опыта, но этот парень делает:
VARCHAR vs. TEXT - some performance numbers
Быстрый ответ: VARCHAR был хороший немного быстрее.
Редактировать - нет, не было. Он индексировал их по-другому - у него был полный индекс на varchar (255 символов), но индекс префикса 255 символов в тексте. Когда он удалил это, они выполнили более или менее то же самое.
Позже в резьбе этот интересный факт:
Когда таблица TMP необходима для SELECT, первый вариант заключается в использовании ПАМЯТИ, которая будет RAM-только, следовательно, вероятно, заметно Быстрее. (Второй вариант - это MyISAM.) Однако в MEMORY запрещены TEXT и BLOB, поэтому не может его использовать. (Есть и другие причины, почему может пропустить ПАМЯТЬ.)
Edit 2 - некоторая более актуальной информация, на этот раз сравнивая путь различных показателей борьбы с различными типами.
MyISAM помещает TEXT и BLOB 'inline'. Если вы ищете таблицу (сканирование диапазона /сканирование таблицы), вы «перешагиваетесь на те корова paddies» - дорогостоящие для диска I/O. То есть, наличие inline blob ухудшает производительность в этом корпусе .
InnoDB ставит только 767 байт TEXT или BLOB встроенный, остальные идут в какой-либо другой блок. Это компромисс , который иногда помогает, иногда болит производительность.
Что-то еще (Maria? Falcon? InnoDB плагин?) Полностью помещает TEXT и BLOB в другое место. Это сделало бы заметную разницу в производительности по сравнению с VARCHAR. Иногда ТЕКСТ будет быстрее (например, сканирование диапазона , которому не нужен blob); иногда VARCHAR будет быстрее (например, если вам нужно посмотреть на него и/или , верните его).
Ну, но в этой статье в качестве первичного ключа используется столбец TEXT/VARCHAR. ОП сказал, что он не будет индексировать колонку. – Thilo
Thilo - вы правы, я просто хотел обратиться к более общей проблеме «последствия работы текста vs varchar». Кто-то, кто читает это, может оказаться полезным. – danben
Да, но я думаю, что на измерение повлияло индексирование. Я не буду делать текстовый столбец первичным ключом. – Viliam
Конечно, лучший способ узнать, это запустить некоторые тесты самостоятельно с помощью своего реального набора данных или, по крайней мере, имитируемого эквивалента. Просто напишите несколько сценариев, чтобы заполнить данные и запустить выбранные вами. Протестируйте с помощью varchar разных размеров, затем текст и измерьте время и общее использование системы (cpu/load, memory, disk i/o).
Если у вас будет достаточно нагрузки, это будет иметь значение, тогда вы должны иметь автоматические тесты в любом случае.
Я думаю, что это интересно для многих архитекторов баз данных, которые не обязательно подтягиваются одним конкретным макетом и архитектурой. Такие ответы «находят сами» полезны ни для меня, ни для кого-либо другого. :) – Viliam
вы не будете использовать столбец в предложениях WHERE или подстроки SELECT, верно? – Thilo
@Thilo: Верно, я не буду использовать его в ГДЕ. – Viliam
Текст в порядке, если вы не включаете столбец в качестве столбца вывода в своих результирующих наборах. То есть Только возвращайте текстовый столбец в запросах, которые возвращают одну строку. ПРИМЕЧАНИЕ. Это должно быть естественным делом в любом случае, потому что такой «большой» столбец действительно полезен только тогда, когда он представлен пользователю для определенной строки. Однако некоторые разработчики ошибочно ошибочно используют 'SELECT * FROM ...'. –