MySQL 8.0 运行慢主因是默认配置更严格：tmp_table_size 和 max_heap_table_size 过小（默认16MB）导致GROUP BY等操作频繁落盘临时表，innodb_log_buffer_size过小加剧日志刷盘压力，叠加审计日志默认开启，共同引发卡顿。
MySQL 8.0 安装后运行慢，不是因为版本本身“变笨”了，而是默认行为更严格、更重审计、更倾向磁盘落盘——尤其在小内存或低配环境里，tmp_table_size 和 max_heap_table_size 过小导致频繁写磁盘临时表，innodb_log_buffer_size 过小又加剧日志刷盘压力，这两点叠加会让简单查询都卡顿。
为什么临时表会落到磁盘上？
MySQL 执行 GROUP BY、ORDER BY、DISTINCT、子查询等操作时，会先尝试在内存建临时表。但 8.0 默认的 tmp_table_size 和 max_heap_table_size 都是 16MB（有些发行版甚至更低），远小于 5.7 的默认值。一旦结果集超限，就会 silently 落到磁盘（CREATE TEMPORARY TABLE ... ENGINE=InnoDB 或 MyISAM），触发大量随机 I/O。
验证方式：执行一个带 GROUP BY 的查询后，立刻查：
SHOW STATUS LIKE 'Created_tmp%';
若 Created_tmp_disk_tables 增长快，而 Created_tmp_tables 增长慢，说明正在频繁落盘。
- 调高二者到相同值（推荐 64M～256M，根据可用内存定），必须加在
[mysqld]段下 - 不能只调一个：
max_heap_table_size控制 MEMORY 表上限，tmp_table_size控制内部临时表内存上限，两者取小值生效 - 改完必须重启 MySQL，
SET GLOBAL不生效（仅对新连接部分生效，且不持久）
为什么日志缓存太小会拖慢写入？
InnoDB 的 redo log 写入不是直接刷盘，而是先写进内存缓冲区（innodb_log_buffer_size），再由后台线程批量刷出。8.0 默认值是 16MB，看似不小，但在高并发 INSERT/UPDATE 场景下，如果事务平均修改量大（比如每条 UPDATE 涉及多个字段 + 多个二级索引），缓冲区会快速填满，被迫高频刷盘，造成写入抖动和锁等待。
典型现象：写入吞吐上不去，innodb_log_waits 状态值持续非零，show engine innodb status 中看到大量 log buffer wait。
- 把
innodb_log_buffer_size提到 32M 或 64M（最大支持 512MB，但没必要） - 同时确认
innodb_log_file_size是否合理（建议单个 256M～1G，总大小 ≈ 1～2 倍 buffer size） - 注意：调大
innodb_log_buffer_size不影响 crash recovery，但会略微增加内存占用
哪些日志配置会偷偷吃掉性能？
MySQL 8.0 默认开启更多日志通道，尤其在未人工干预的情况下：
-
general_log = ON：记录所有语句，I/O 开销极大，生产环境必须关 -
slow_query_log = ON且long_query_time = 0：等于全量记录，比 general_log 还狠 -
log_error_verbosity = 3（默认）：错误日志包含详细堆栈，写入频繁时占 CPU -
audit_log插件已加载但未禁用：即使没配置策略，也会引入额外 hook 开销
检查命令：
SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name LIKE '%audit%' OR plugin_name LIKE '%fire%';<br>SHOW VARIABLES LIKE 'general_log%';<br>SHOW VARIABLES LIKE 'slow_query_log%';
关闭方式（写入配置文件并重启）：
general_log = OFF<br>slow_query_log = OFF<br>log_error_verbosity = 2<br># 若 audit_log 已加载，加一行：plugin_load_add = 'audit_log=OFF'
真正容易被忽略的是：这些日志开关在配置文件里设为 OFF 后，必须重启 MySQL 才彻底卸载日志模块；仅用 SET GLOBAL 关闭，底层 handler 可能仍在内存中驻留，仍消耗微量资源。
