8123 байта хватит каждому

Пипец, вот настрочили комменты.
В каждой базе данных хватает своих особенностей, ограничений и глюков. Код пишет не подразделение НАСА, которое пишет софт для шатлов. А у MySQL историческое наследие, которое слава богу выпиливают и меняют. У же не говорю о том, что прямо в топике написано, что с 5.5 такой проблемы уже нет (либо использовать InnoDB Plugin, который кажись с 5.1 уже работает).

А меня в мускуле насторожило, что два из четырёх типов хранилища не обещают транзакционной целостности.

Ограниченность мышления данного индивидума… Ну вы поняли.
А ещё, он знает всего 4 типа движков для MySQL. Чел спец! :trollface:
Их вобще-то 8, просто часть не включена по умолчанию. А так же с десяток-два сторонних бесплатных и комерческих движков — советую заглянуть на mysqlperformanceblog.com для самообразования что-бы узнать побольше о самых известных (там в основном колоночные движки для аналитики рассматриваются — клиенты пользуются ихние).

Что касается автора — он молодец. Теперь меньше людей будут недоумевать над причиной проблемы. К счастью 10+ колонок типа TEXT в таблице — редкость, так что это знание больше из разряда уличной магии :)

Вроде на поля VARCHAR это ограничение тоже распространяется, т.е. они тоже «отъедают» байты из этих 8Кб и их надо учитывать. Поправьте меня, если ошибаюсь.

Всё верно. Хочу добавить следующее.

Текст ошибки может быть такой: “SQL Error (1118): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs”.

Чтобы решить проблему в MySQL 5.5, нужно:

1) включить новый формат InnoDB файлов в my.cnf:

innodb_file_format = Barracuda

Если создаётся таблица, которая не нуждается в новых возможностях, то она будет создана в более простом формате Antelope.

2) преобразовать таблицу в новый формат строки:

ALTER TABLE tableName ENGINE = InnoDB ROW_FORMAT = Dynamic;

Формат строки Dynamic означает, что для длинных TEXT/VARCHAR, не являющихся частью primary key, в B-дереве могут хранятся только 20 байт указателя на отдельную область с данными (overflow). База сама выбирает, какие колонки держать в B-дереве, а какие слишком длинные, и нужно держать отдельно в overflow: если строка таблицы не умещается в размер половины страницы (8126 байт), то самая длинная колонка целиком помещается во внешнее хранилище. Процедура повторяется, пока все оставшиеся колонки не уместятся в размер половины страницы.

Итак, в этом формате каждая TEXT/VARCHAR колонка занимает минимум 20 байт в странице, и одна строка таблицы может содержать максимум 400 TEXT/VARCHAR полей. Колонка может занимать больше байт в странице, если там осталось место.

Чтобы в будущем MySQL выдавал ошибку при создании таблицы, если она не помещается в формат строки, включаем innodb_strict_mode в my.cnf:

innodb_strict_mode = ON

Также можно обратить внимание на sql_mode для упрощения отладки.

Рубрика «нам пишут анонимы»:

Доброе утро

Прочитал ваш топик и сразу возник вопрос — и за чем он нужен? Каково реальное применение? Хранить в БД большие объёмы текстовых данных — это несусветная глупость, т.к. это сильно тормозит БД, съедает кэш и существуют другие оптимальные способы.

Уберите топик в черновики, пожалуйста.

И вам, Виталий, доброе утро.

Реальное применение топика — избегать таких ошибок у себя в проектах. Как я уже сказал, ошибка эта не сильно освещена в документации, и понять в чем проблема из сообщения об ошибке не представляется возможным. Кроме того, информация о том, что эта особенность не проявляется в новой версии InnoDB при определенном формате таблиц, была найдена мной эмпирически. О том, что базы данных не предназначены для хранения текстовой информации я слышу впервые, научите, пожалуйста, как правильно.

Топик не уберу, спасибо.