升级后需立即验证系统库可读性、版本一致性、innodb状态、关键表数据一致性、外键与索引有效性，以及时间字段默认值兼容性。
升级后立刻检查 information_schema 和 mysql 系统库是否可读
MySQL 升级（尤其是跨大版本，如 5.7 → 8.0）后，系统表结构可能变更，mysql 库中的权限表（如 user、db）或 information_schema 视图可能因元数据不兼容而报错或返回空。这不是业务数据问题，但会阻断后续校验逻辑。
- 执行
SELECT COUNT(*) FROM mysql.user;—— 若报错Table 'mysql.user' doesn't exist或提示Unknown table，说明升级未完成或mysql_upgrade未运行（8.0.16+ 已弃用该命令，改由mysqld --upgrade=FORCE替代） - 运行
SELECT VERSION(), @@version_comment;确认实际运行版本与预期一致，避免“看似升级成功实则回滚到旧实例” - 检查
SHOW ENGINES;中InnoDB是否为DEFAULT且状态为YES；若显示DISABLED，需确认配置中未误设skip_innodb
用 mysqldump --single-transaction --no-create-info 抽样比对行数和哈希值
全量导出再对比不现实，但抽样关键表（如用户主表、订单主表）可快速暴露数据截断、字符集转换失败、JSON 字段解析异常等问题。重点不是导出结构，而是确保内容一致性。
- 在旧库和新库分别执行：
mysqldump -u root -p --single-transaction --no-create-info --skip-extended-insert dbname tablename | md5sum，对比输出的 MD5 值 - 注意：必须加
--single-transaction，否则高并发下可能因 MVCC 快照不一致导致行数差异；--skip-extended-insert避免因 INSERT 语句换行/空格差异干扰哈希 - 若 MD5 不同但行数相同，用
diff对比两份 dump 输出，常见原因是：5.7 的utf8mb4默认排序规则是utf8mb4_general_ci，8.0 改为utf8mb4_0900_as_cs，导致 ORDER BY 结果顺序变化，进而影响 dump 行序
验证外键约束和索引是否生效，而非仅存在
升级后 SHOW CREATE TABLE 看起来一切正常，但某些约束可能被静默禁用（尤其从 5.6 升级到 5.7 时 FOREIGN_KEY_CHECKS=0 残留），或索引因统计信息陈旧未被优化器选用，导致查询结果异常。
拍客竞拍系统是一款免费竞拍网站建设软件，任何个人可以下载使用，但未经商业授权不能进行商业活动，程序源代码开源，任何个人和企业可以进行二次开发，但不能以出售和盈利为目的。安装方法，将www文件夹里面的所有文件上传至虚拟主机，在浏览器执行http://你的域名/install.php或者直接导入数据库文件执行。本次升级优化了一下内容1，程序和模板完美分离。2，优化了安装文件。3，后台增加模板切换功能。
- 执行
SELECT @@foreign_key_checks;，确保返回1；若为0，需手动执行SET FOREIGN_KEY_CHECKS = 1;并检查错误日志是否有修复失败提示 - 对含外键的表做一次强制校验：
ALTER TABLE child_table ENGINE=InnoDB;（触发重建，同时校验引用完整性） - 用
EXPLAIN FORMAT=TREE SELECT * FROM orders WHERE user_id = 123;（8.0+ 支持）确认是否命中预期索引；若仍走全表扫描，运行ANALYZE TABLE orders;更新统计信息
特别关注时间类型字段和默认值行为变化
MySQL 5.6.5+ 引入 TIMESTAMP/DATETIME 默认值支持，但 5.7 和 8.0 对 0000-00-00、NO_ZERO_DATE SQL 模式的处理逻辑不同，极易导致应用层读取为空或报错。
- 检查当前 SQL 模式：
SELECT @@sql_mode;，确认是否含NO_ZERO_DATE和STRICT_TRANS_TABLES；8.0 默认启用，5.7 默认不启用 - 查出所有含时间默认值的列：
SELECT table_name, column_name, column_default FROM information_schema.columns WHERE data_type IN ('datetime','timestamp') AND column_default IS NOT NULL AND table_schema='dbname'; - 对典型记录执行
SELECT id, created_at, updated_at FROM t1 WHERE id = 123;，对比新旧库输出；若旧库返回'0000-00-00 00:00:00'而新库返回NULL或报错，说明严格模式拦截了非法值
升级后的数据验证本质是“信任链重建”：先确认系统元数据可信，再验证关键样本内容一致，接着确认约束与执行计划未退化，最后抠住那些版本间行为漂移最剧烈的字段类型。最容易被跳过的，其实是时间字段的默认值兼容性测试——它不报错，只悄悄把数据变 NULL。
