На MySQL 5.7.24 живет табличка на движке MyISAM. Табличка поделена на 12 партиций - по числу месяцев. Работает давно и вопросов не вызывает. Запись в таблицу сравнительно редкая, преимущественно чтение используется. Количество записей нынче порядка 16 миллионов и растет. В таблице 8 полей: два поля INT, три TINYINT, одно MEDIUMINT, одно DATE и одно VARCHAR(255). Все поля NOT NULL.
Однако, при обновлении версии сервера давно уже стало появляться предупреждение "The partition engine, ...., is deprecated and will be removed in a future release.". Документация говорит следующее:
https://dev.mysql.com/doc/refman/8.0/en/partitioning.html In MySQL 8.0, partitioning support is provided by the InnoDB and NDB storage engines.
MySQL 8.0 does not currently support partitioning of tables using any storage engine other than InnoDB or NDB, such as MyISAM.
Ясно-понятно, есть смысл протестировать переезд заблаговременно. На тестовой базе делаю резервную копию таблицы, а затем для рабочей делаю ALTER TABLE ... ENGINE=InnoDB;, как сказано в
мануале по переезду . Вместо предполагаемых ориентировочно 30...40 минут (так то заливка дампа в 15 минут легко укладывается) запрос работал часа полтора. Ну это ладно, я же не знаю, как работает внутренняя кухня.
Тем не менее,
вопрос первый : чего он так долго ковырялся, это так и должно быть?
Конвертация завершилась. Смотрю статистику таблицы. На MyISAM исходная таблица (как и бэкап её) весит
1,9 гига , из них треть примерно данные, остальное - индексы (индексов там много, да). Цифра привычная и ожидаемая.
На InnoDB после ALTER TABLE таблица весит уже
5,7 гиг , соотношение данные/индекс (смотрел в phpmyadmin) похожее. Посмотрел размеры (опция innodb_file_per_table включена) файлов в датадир - ну да, сопоставимо, каждый файл *.ibd для этой таблицы порядка 500 мегабайт, ну плюс-минус, конечно.
Вопрос второй : с чего так распухли файлы? В мануале по переезду на InnoDB сказано:
https://dev.mysql.com/doc/refman/8.0/en/converting-tables-to-innodb.html InnoDB tables require more disk space than MyISAM tables.Но не нашел, насколько больше. Втрое больше - ад какой-то.
Хорошо, есть же ещё способ. Делаю дамп таблицы. Делаю новую пустую таблицу InnoDB с копией структуры. Заливаю дамп в пустую таблицу. Время заливки ожидаемо, но размер получился уже
3,1 гига при том же соотношении данные/индекс. Ага, больше чем в MyISAM, но уже не втрое, а лишь в полтора раза. Смотрю в датадир файлы этой таблицы - в среднем порядка 300 мегабайт на файл. Вот тут уже не понимаю. Данные те же, а размеры файлов сильно разные. Опять же
вопрос третий : оно получилось где-то посередине, но почему? Ну так то, конечно, способ получения файлов таблицы разный, хотя, данные идентичны и в количестве и в типе полей, да и в значениях, надеюсь...
Или есть различия? Для начала просто проверяю количество строк запросом SELECT COUNT(1) FROM ....
И опять же, пляска. На MyISAM:
1.
2.
3.
4.
5.
+----------+
| count(1) |
+----------+
| 16384529 |
+----------+
1 row in set (0.00 sec)
Ну ладно, тут статистика знает точное число и готова немедленно дать ответ. Делаю тот же запрос к таблице, полученной при помощи ALTER TABLE:
1.
2.
3.
4.
5.
6.
+----------+
| count(1) |
+----------+
| 16384529 |
+----------+
1 row in set (3 min 28.29 sec)
Опс... Три минуты!!! Повторно делаю тот же запрос, и спустя много времени ещё - аналогично, менее 3 минут ни разу не отработал.
Для чистоты эксперимента тот же запрос к таблице, куда заливал дамп. Количество строк ожидаемо то же самое, время выполнения не ноль, конечно, но от 4 до 15 секунд колеблется. Ладно, сойдет. Но многократная разница времени выполнения по сравнению с предыдущим намекает на какие-то проблемы.
В общем, по итогу тестирования закралось сомнение в правильности работы ALTER TABLE. Выходит, этот запрос выдал в результате не только не в меру пухлую по размерам файлов таблицу, но и какую-то тормозную, чтоли...
Вопрос : есть какие-то противопоказания применения ALTER TABLE или чего я не учел ещё?
