MySql Tinytext vs Varchar vs Char

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

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

Вот представление 100 футов:

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

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

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

Ответ 1

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

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

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

Смотрите: varchar (255) v tinyblob v tinytext
И: 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.*') и, очевидно, более универсальный.

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

ИЗМЕНИТЬ

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