MySQL主版本升级后必须执行mysql_upgrade并确认成功,否则会导致元数据异常;8.0.16+改由启动时自动升级,需查错误日志;辅以pt-table-checksum比对主从一致性、人工抽样验证关键数据、mysqlcheck检查物理完整性,并逐表核对字符集与排序规则变更。
mysql_upgrade 是否已执行且无报错MySQL 主版本升级(如 5.7 → 8.0)后,系统表结构可能变更,mysql_upgrade 是官方推荐的元数据兼容性修复工具。它不校验业务数据,但若跳过或失败,会导致 INFORMATION_SCHEMA 视图异常、权限失效、甚至 SELECT COUNT(*) 返回错误结果。
mysql_upgrade -u root -p --force
Upgrade process completed successfully;若出现 ERROR 1872 或反复提示某张表损坏,说明底层数据字典已不一致,需先用 mysqld --upgrade=NONE 启动并导出再重建Auto-upgrade complete 或 Failed to upgrade data dictionary
pt-table-checksum 做主从/跨实例一致性比对如果升级涉及主从切换或迁移至新实例,pt-table-checksum(Percona Toolkit)是最实用的在线一致性校验工具。它通过分块计算 CRC32 校验和,在主库生成摘要,再让从库执行相同逻辑并比对,避免全表锁和网络拉取全部数据。
Seconds_Behind_Master = 0)pt-table-checksum --host=localhost --user=root --password=xxx --databases=mydb --no-check-binlog-format
--chunk-size 过大会触发超时,--max-load 可防主库压力突增;若校验中报 Column count mismatch,说明某张表在新旧版本间字段定义被隐式修改(如 TIMESTAMP 默认值行为变化),需人工核对 SHOW CREATE TABLE 输出自动化工具无法覆盖所有语义逻辑,比如金额字段是否被截断、JSON 字段是否解析失败、时间字段是否因时区处理差异偏移。必须人工设计轻量级验证点。
SELECT COUNT(*) 在大表上不准,优先用 TABLE_ROWS,但仅适用于 InnoDB 估算值):SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='mydb' AND table_name IN ('orders','users');SUM(amount)、AVG(score),特别注意浮点数字段是否因 MySQL 8.0 的 DECIMAL 精度策略变更导致微小偏差ORDER BY created_at DESC LIMIT 1 和 MIN(id), MAX(id),确认自增列、时间戳未重置或翻转;若发现 created_at 出现 '0000-00-00 00:00:00',说明 sql_mode 中 NO_ZERO_DATE 生效,需清理或调整配置mysqlcheck 检查表物理完整性mysqlcheck 是 MySQL 自带的表维护工具,可检测索引损坏、页断裂、B+树节点异常等底层问题。升级过程若中断或磁盘 I/O 异常,可能导致 .ibd 文件损坏,而这种损坏不会立刻暴露,后续 DML 才会触发 ERROR 2013 或崩溃。
--parallel 降低影响:mysqlcheck -u root -p --check --all-databases --medium-check
--medium-check 会校验索引树结构和行记录链接,比 --quick 更彻底;若返回 error : record is crashed,说明该表已损坏,不能直接 REPAIR(InnoDB 不支持),只能从备份恢复或用 mysqldump --single-transaction 导出重建mysqlcheck 的 --optimize 行为有变更,不再默认重建表,需显式加 --alter 才触发 ALGORITHM=INPLACEutf8mb4_general_ci,升级到 8.0 后 information_schema.COLLATION_NAME 显示为 utf8mb4_0900_as_cs,但表定义没变,导致 WHERE name = 'abc' 结果不一致。这类问题必须在验证清单里单列一条:用 SHOW FULL COLUMNS FROM t1
和 SHOW CREATE TABLE t1 逐表比对 COLLATE 值。