Для таблицы innodb в MySQL, что быстрее: varchar (255) или tinytext?

я оптимизирую некоторые InnoDB таблицы в MySQL, поэтому я побежал процедура analsye() чтобы увидеть, какие рекомендации были.

результаты рекомендуется tinytext вместо varchar(255) для всех полей, которые ранее были настроены как varchar(255)

есть производительность чтобы быть с помощью tinytext? Меня здесь интересует только скорость, а не размер.

7
innodb mysql optimization tinytext varchar

4 ответов

Не верьте, если кто-то скажет вам, что TINYTEXT хранится иначе, чем VARCHAR.

фактические различия:

  • TINYTEXT и другие текстовые поля хранятся отдельно от строки в памяти внутри кучи MySQL, тогда как поля VARCHAR() добавляют до предела 64k (поэтому вы можете иметь более 64k в TINYTEXTs, тогда как вы не будете с VARCHAR).

  • TINYTEXT и другие "blob-подобные" поля заставят SQL layer (MySQL) использовать временные таблицы на диске, когда они используются, тогда как VARCHAR будет по-прежнему сортироваться "в памяти" (хотя будет преобразован в CHAR для полной ширины).

  • InnoDB внутренне не очень волнует, является ли это tinytext или varchar. Очень легко проверить, создать две таблицы, одну с VARCHAR(255), другую с TINYINT, и вставить запись в обе. Они оба будут занимать одну страницу 16k-тогда как если используются страницы переполнения, таблица TINYTEXT должна отображаться как принимающая минимум 32k в "показать состояние таблицы".

Я обычно предпочитаю VARCHAR (255) - они не вызывают слишком много фрагментации кучи для одной строки и могут рассматриваться как один объект 64k в памяти внутри MySQL. На InnoDB различия в размерах незначительны.

6

Я ожидал бы, что varchar будет быстрее, чем tinytext, и, судя по моему Гуглу, это, кажется, общий консенсус. Конечно, вам придется проверить свою систему, чтобы быть действительно уверенным.

причина в том, что это быстрее, потому что, когда MySQL выполняет определенные виды операций (соединения, сортировки и т. д.) он часто создает временные таблицы. Когда у вас есть тип BLOB (например, tinytext) во временной таблице, Таблица будет основана на диске, а не на памяти, что, конечно, будет оказывают влияние на производительность.

1

CHAR / VARCHAR будет быстрее, поскольку эти столбцы хранятся на той же странице, что и данные основной строки*, тогда как типы текста хранятся вне страницы (Я был неправ, см. комментарий Харрисона).

люди часто использовали tinytext, потому что varchar (раздражающе) обрезал конечные пробелы. Это поведение было удалено в MySQL 5.0.

(*по крайней мере, для первых 768 байт и со встроенным InnoDB, а не новым плагином InnoDB ).

1

вы также можете посмотреть на использование char(255) - хотя он использует больше пространства, он был значительно быстрее (по моему опыту), чтобы использовать поле, которое является постоянным размером при выполнении сравнения позже. Дополнительное пространство может быть заполнено заполнением, если вы ищете только скорость, а затем игнорируете пробелы позже.

однако, Примечание: MySQL не позволит varchar и char типы, существующие в одной таблице. Также [обычно] не позволяет сравнивать между varchar и char. Я узнал об этом в прошлом году, когда делал реализацию таблицы для хобби проект.

0