MySQL 8.0 升级后 performance_schema 表结构变动是因系统表未自动升级所致，根源在于 mysqld 启动时未执行 --upgrade 流程或残留 5.7 的 MyISAM 文件，导致元数据加载失败、SHOW TABLES 返回空或报错。
MySQL 8.0 升级后 performance_schema 表结构变动不是配置问题，而是系统表未完成自动升级——服务启动时没走通 --upgrade 流程，或残留旧版 MyISAM 引擎表导致元数据加载失败。
为什么 SHOW TABLES FROM performance_schema 返回空或报错 Unknown table？
这不是权限或配置遗漏，是 performance_schema 库下的表（如 events_statements_summary_by_digest）在 8.0 中字段、引擎、索引都已重构，但你的数据目录仍保留着 5.7 的 MyISAM 结构文件（.MYD/.MYI），而 8.0 要求所有 performance_schema 表必须为内存引擎且结构严格匹配。
- 典型错误：
ERROR 1146 (42S02): Table 'performance_schema.events_statements_summary_by_digest' doesn't exist，但SELECT * FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'performance_schema'又能查到库存在 - 检查实际引擎：
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'performance_schema'—— 若结果里出现MyISAM，就确认是引擎残留问题 - 别手动删
performance_schema/目录下文件——它由 mysqld 启动时自动生成，删了会导致服务无法加载
mysqld 启动时如何强制刷新 performance_schema 结构？
MySQL 8.0 不再依赖 mysql_upgrade，performance_schema 的重建完全由 mysqld 在首次启动旧数据目录时自动触发。若没触发或中途失败，需显式启用升级模式：
- 停服务：
systemctl stop mysql，确保无残留进程（ps aux | grep mysqld） - 临时注释掉
my.cnf中的innodb_force_recovery（否则升级流程被跳过） - 用完整路径启动并强制升级：
/usr/local/mysql-8.0/bin/mysqld --user=mysql --datadir=/var/lib/mysql --upgrade=FORCE - 观察错误日志（通常是
/var/log/mysql/error.log），成功会有类似Upgrading performance_schema tables和Finished upgrading system tables的日志行 - 升级完成后，正常启动：
systemctl start mysql，不要带--upgrade参数
升级后 performance_schema 查询变慢或统计不准怎么办？
8.0 默认开启更细粒度的采集（如语句 digest、锁等待），但若没调优，会因频繁写入内存表拖慢性能，甚至触发内存溢出：
- 检查是否全开：
SELECT * FROM performance_schema.setup_consumers WHERE ENABLED = 'YES';—— 若events_statements_history_long或events_waits_history_long被启用，立刻关掉：UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME IN ('events_statements_history_long', 'events_waits_history_long'); - 限制 digest 缓存大小（防 OOM）：
SET GLOBAL performance_schema_digests_size = 2000;（默认 10000，按业务 SQL 去重量调整） - 确认采集开关是否生效：
SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE 'statement/sql/%' AND ENABLED = 'YES';，避免误关关键采集项 - 注意：这些设置重启失效，需写入
my.cnf的[mysqld]段：performance_schema_digests_size = 2000
真正卡住的点往往不在 SQL 写法，而在启动那一刻——--upgrade=FORCE 是否真执行成功、error.log 里有没有 “Upgrading performance_schema” 这行字。漏看这一行，后面所有调优都是在修一个根本没建好的地基。
