Имеет ли медленный выбор столбцов переменной длины в таблице InnoDB?

Question

С MyISAM, имеющим столбцы переменной длины (varchar, blob) на таблице, действительно замедлялись запросы, поэтому я обнаружил в сети советы по перемещению столбцов varchar в отдельную таблицу.

Это все еще проблема с InnoDB?Я не имею в виду случаи, когда введение множества строк varchar в таблицу приводит к разбиению страницы.Я просто имею в виду, стоит ли вам, например, перенести post_text (одно поле BLOB в таблице) в другую таблицу, говоря о производительности с InnoDB?

Answer 1

Данные InnoDB полностью отличаются от MyISAM.

В MyISAM все индексы - первичные или иные - хранятся в файле MYI и содержат указатель на данные, хранящиеся в файле MYD.Строки переменной длины не должны напрямую влиять на скорость запроса, но файл MYD имеет тенденцию становиться более фрагментированным со строками переменной длины, потому что отверстие, оставленное позади при удалении строки, не обязательно может быть заполнено строкой, которую вы вставляете следующей.Если вы обновите значение переменной длины, чтобы сделать его длиннее, вам, возможно, придется переместить его куда-то еще, что означает, что оно будет иметь тенденцию выходить из строя по отношению к индексам с течением времени, делая запросы диапазона более медленными.(Если вы запускаете его на вращающемся диске, где важно время поиска).

InnoDB хранит данные, кластеризованные на страницах в B-дереве на первичном ключе.Пока данные помещаются на странице, они сохраняются на странице независимо от того, используете ли вы BLOB или VARCHAR.Пока вы не пытаетесь вставлять неоправданно длинные значения на регулярной основе, не должно иметь значения, являются ли ваши строки фиксированной или переменной длины.

Answer 2

Насколько я знаю, BLOB (и TEXT) на самом деле хранятся вне таблицы, VARCHAR хранятся в таблице.

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

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

Я не думаю, что перемещение значений BLOB действительно помогает, кроме уменьшения общего размера таблицы, что в любом случае оказывает положительное влияние на производительность.VARCHARы - это отдельная история.Вы обязательно выиграете здесь.Если все ваши столбцы имеют определенную длину (и я предполагаю, что это означает, что вы также не можете использовать BLOB-объекты?), Поиск полей будет быстрее.

Если вы просто «читаете» поля VARHCAR и BLOB, ясказал бы, что стоит попробовать.Но если ваш запрос на выборку требует сравнения значения из VARCHAR или BLOB, вы довольно кислы.

Так что да, вы определенно можете повысить производительность здесь, но убедитесь, что вы проверяете, действительно ли вы получаете производительность, и чтоувеличение стоит агрессивной денормализации.

PS.

Другой способ «оптимизации» производительности чтения VARCHAR - просто заменить их полями CHAR (фиксированной длины).Это может повысить производительность чтения, если допустимо увеличение дискового пространства.