MySQL 8.0 InnoDB性能未提升反降，主因是旧配置失效或触发更严资源约束；真正提升高并发查询的关键改进是Hash Join、Parallel Query和Atomic DDL，但需匹配索引、单表扫描及INSTANT操作等前提条件。
为什么升级后InnoDB性能没变好，甚至更差？
大概率不是InnoDB本身变慢了，而是旧配置在8.0下失效或触发了更严格的资源约束。MySQL 8.0的InnoDB改进集中在底层机制（如崩溃恢复、DDL效率、缓冲池管理），但这些优势会被错误的sort_buffer_size、被元数据挤占的innodb_buffer_pool_size或未清理的mysqld-auto.cnf直接抵消。
哪些InnoDB改进能真正提升高并发查询性能？
真正影响线上查询吞吐的关键点有三个：
-
Hash Join：8.0默认启用，对大表JOIN（尤其等值连接）替代嵌套循环，大幅降低CPU和IO——但需确保JOIN字段有索引，否则仍退化为BNL -
Parallel Query：范围扫描、COUNT(*)等操作可自动并行（由innodb_parallel_read_threads控制），但仅对单表大扫描有效，多表JOIN不参与 -
Atomic DDL：ALGORITHM=INSTANT支持秒级加列（无锁），避免长事务阻塞；但仅限添加列、重命名列等有限操作，DROP COLUMN仍需COPY
innodb_buffer_pool_size在8.0中为什么实际可用内存变少了？
8.0把数据字典、角色权限、统计信息缓存全放InnoDB里，information_schema_stats_expiry默认开启（3600秒），导致buffer pool常驻元数据页。原来设1G，在8.0下可能只剩800MB给业务数据。
查真实占用：
SELECT (SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_PAGE WHERE PAGE_TYPE = 'INDEX') * 16384 / @@innodb_buffer_pool_size AS index_ratio,
(SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_PAGE WHERE PAGE_TYPE = 'TRX_SYSTEM') * 16384 / @@innodb_buffer_pool_size AS trx_system_ratio;
建议做法：
- 把
innodb_buffer_pool_size调高15%~20%，再观察innodb_buffer_pool_read_requests与innodb_buffer_pool_reads比值 - 关掉统计缓存（
SET GLOBAL information_schema_stats_expiry = 0），但会增加每次SHOW TABLE STATUS开销
排序性能下降最常踩的坑是什么？
8.0彻底移除了max_length_for_sort_data，排序策略改为全字段内存排序。只要sort_buffer_size不够装下所有排序字段 × 行数，就强制走磁盘filesort——而5.7还能靠rowid路径“蒙混过关”。
典型错误现象：Using filesort出现在EXPLAIN中，且Handler_sort_merge陡增
排查步骤：
- 查当前生效值：
SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.variables_info WHERE VARIABLE_NAME IN ('sort_buffer_size', 'read_rnd_buffer_size'); - 确认是否被
mysqld-auto.cnf覆盖：SELECT * FROM performance_schema.persisted_variables WHERE VARIABLE_NAME = 'sort_buffer_size'; - 临时清空持久化变量：
RESET PERSIST sort_buffer_size;，再重启验证
真正有效的解法是先建复合索引覆盖ORDER BY字段，再把sort_buffer_size设为2M~4M区间观察——盲目调到8M以上，容易因per-connection分配引发OOM。
