Почему INFORMATION_SCHEMA моей MySQL базы данных неточно представляет таблицы

Question

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

Сначала я заметил, что из 46 таблиц, которые я перенес, 13 были разных размеров, при дальнейшем осмотре я заметил, что 9 из 13 таблиц были на самом деле больше в более новой базе данных, чем Старый. В настоящее время нет сценариев / кода, настроенных для любой базы данных, которая изменила бы данные, не говоря уже о количестве данных.

Затем я дополнительно изучил одну из меньших таблиц (всего 43 строки) в старой базе данных и заметил что при выполнении приведенного ниже запроса sql я получал 40 TABLE_ROWS вместо фактических 43. То же самое было и для другой меньшей таблицы в старой базе данных, где в запросе было указано 8 строк, но их было 15. (Я вручную подсчитал несколько раз, чтобы подтвердить эти два случая)

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

SELECT TABLE_ROWS, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE.SCHEMA = 'db_name';

Есть мысли?

Answer 1

Чтобы информация_schema не была мучительно медленной при извлечении этого для больших таблиц, она использует оценки, основанные на мощности первичного ключа, для таблиц InnoDB. В противном случае пришлось бы выполнять SELECT COUNT(*) FROM table_name, что для таблицы с миллиардами строк может занять несколько часов.

Посмотрите на SHOW INDEX FROM table_name, и вы увидите, что число, указанное в information_schema, такое же в качестве мощности ПК.

Запуск ANALYZE TABLE table_name обновит статистику, которая может сделать ее более точной, но это все равно будет оценка, а не точное количество проверенных строк.

Answer 2

Чтение документации: https://dev.mysql.com/doc/refman/8.0/en/tables-table.html

TABLE_ROWS Количество строк. Некоторые механизмы хранения, такие как MyISAM, хранят точное количество. Для других механизмов хранения, таких как InnoDB, это значение является приблизительным и может отличаться от фактического значения на целых 40–50%. В таких случаях используйте SELECT COUNT (*), чтобы получить точное количество.

Были ли какие-либо ошибки / предупреждения в журнале миграции? Существует так много способов переноса данных таблицы mysql, что лично мне нравится использовать mysqldump и импортировать файл sql для получения результатов с помощью клиента командной строки mysql. По моему опыту импортирования с использованием клиентов GUI всегда есть недостатки.