MySql Tinytext против Varchar против Char

Question

Построение системы, которая может сильно ударить с помощью ударов и трафика. Это типичная настройка Apache / PHP / MySql.

Раньше собирал много систем, но никогда не было сценария, в котором мне действительно приходилось принимать решения относительно потенциальной масштабируемости такого размера. У меня есть десятки вопросов, касающихся построения системы такого масштаба, но по этому конкретному вопросу я пытаюсь решить, что использовать в качестве типа данных.

Вот вид 100 футов:

У нас есть таблица, которая (помимо прочего) имеет поле description . Мы решили ограничить его 255 символами . Это будет доступно для поиска ( т.е.: показать мне все записи с описанием, которое содержит ... ). Проблема: в какой-то момент эта таблица может содержать миллионов на миллионы записей ( или, как нам кажется, ).

Я еще не определил стратегию поиска (оператор MySql LIKE, вероятно, будет медленным и / или боровом, я полагаю, для такого большого количества записей), но это еще один вопрос SO. На этот вопрос мне интересно , в чем плюсы и минусы создания этого поля в виде tinytext, varchar и char .

Я не эксперт по базам данных, поэтому любые комментарии полезны. Спасибо -

Answer 1

Используйте CHAR.

BLOB и TEXT хранятся вне строки, поэтому за их чтение взимается штраф за доступ.VARCHAR имеют переменную длину, что экономит место на диске, поскольку может привести к небольшому штрафу за доступ (поскольку строки не имеют фиксированную длину).

Однако, если вы правильно создадите свой индекс, в индексе может быть полностью сохранено VARCHAR или CHAR, что сделает доступ намного быстрее.

См .: varchar (255) v крошечный шарик v крошечный текст И: http://213.136.52.31/mysql/540
И: http://forums.mysql.com/read.php?10,254231,254231#msg-254231
И: http://forums.mysql.com/read.php?20,223006,223683#msg-223683

Кстати, по моему опыту оператор MySQL regex являетсянамного быстрее, чем LIKE для простых запросов (т. е. SELECT ID WHERE SOME_COLUMN REGEX 'search.*'), и, очевидно, более универсален.

Answer 2

Если вы хотите искать среди миллионов строк, сохраните все эти тексты в другой таблице (что уменьшит размер строки вашей большой таблицы) и используйте VARCHAR, если ваши текстовые данные короткие, или TEXT, если вам требуется большедлина.

Вместо поиска с помощью LIKE используйте специализированное решение, такое как Lucene, Sphinx или Solr.Я не помню какой, но по крайней мере один из них может быть легко настроен для индексации в реальном времени или почти в реальном времени.

РЕДАКТИРОВАТЬ

Мое предложениехранение текста в другой таблице уменьшает количество операций ввода-вывода, необходимых для основной таблицы, но при вставке данных требуется сохранение дополнительного индекса и добавление накладных расходов на объединение в выборках, поэтому это допустимо, только если вы используете вашу таблицу для чтения нескольких описаний одновременно и других данныхиз таблицы чаще используется.

Answer 3

В вашей ситуации все три типа плохие, если вы будете использовать LIKE (LIKE '%string%' не будет использовать индекс, созданный для этого столбца, независимо от его типа).Все остальное - просто шум.

Я не знаю какой-либо существенной разницы между TINYTEXT и VARCHAR до 255 символов, а CHAR просто не предназначен для строк переменной длины.

Итак, мое предложение: выберите VARCHAR или TINYTEXT (я бы лично выбрал VARCHAR) и проиндексируйте содержимое этого столбца, используя систему полнотекстового поиска, такую ​​как Lucene, Sphinx или любую другую, которая сделает эту работу за вас.Просто забудьте о LIKE (даже если это означает, что вам нужно самостоятельно создать механизм индекса полнотекстового поиска самостоятельно по любым причинам, которые у вас могут быть, т.е. вам нужна поддержка набора функций, который не может удовлетворить ни один механизм).

Answer 4

Я считаю, что с varchar у вас есть переменная длина, хранящаяся в фактической базе данных на низких уровнях, что означает, что она может занимать меньше места на диске, а текстовое поле имеет фиксированную длину, даже если строка не использует всеЭто.Строка фиксированной длины должна выполняться быстрее.

Редактировать : Я только что посмотрел, текстовые типы также сохраняются как переменная длина.Лучше всего было бы сравнить его с чем-то вроде mysqlslap

. Что касается вашего другого не заданного вопроса, вы, вероятно, захотите создать какой-то поисковый индекс, который связывает каждое полезное слово в описании.поле индивидуально для описания, затем вы можете индексировать это и искать его вместо.будет намного быстрее, чем использование% как%.