MySQL 8.0 默认配置严重低估现代硬件，必须调整七项参数：1. innodb_buffer_pool_size设为内存70–80%；2. innodb_log_file_size单文件至少512M；3. tmp_table_size与max_heap_table_size同步设大；4. innodb_flush_log_at_trx_commit=2提升并发查询稳定性；5. 确保character-set-server=utf8mb4及匹配collation；6. slow_query_log需合理设置long_query_time并避免log_queries_not_using_indexes；7. innodb_buffer_pool_instances在多核下设为8或16以减少锁争用。
直接上结论：MySQL 8.0 安装后不调参，相当于把法拉利当自行车骑——默认配置严重低估了现代硬件能力，尤其在查询效率上会吃掉 40% 以上的性能红利。
安装后必须改的三个核心参数
很多用户以为装完就能跑，结果一上线就慢。真正影响查询效率的不是 SQL 写得有多差，而是这三项没动：
-
innodb_buffer_pool_size必须设为物理内存的 70–80%，低于 50% 就大概率触发频繁磁盘读；16GB 机器建议设innodb_buffer_pool_size = 12G -
innodb_log_file_size默认 48MB，对 OLTP 场景太小，建议单文件至少512M（innodb_log_files_in_group = 2），否则日志频繁刷盘拖慢写入，连带影响后续 SELECT 的响应 -
tmp_table_size和max_heap_table_size必须同步设大（如256M），否则 JOIN 或 GROUP BY 一多就自动落盘到磁盘临时表，性能断崖下跌
为什么 innodb_flush_log_at_trx_commit = 2 是查询效率的隐形开关
这个参数不直接影响 SELECT，但极大影响高并发下查询的响应稳定性。设为 1（默认）时，每次事务提交都强制刷盘，IO 峰值会卡住其他查询线程；设为 2 后，写入先进 OS 缓存，每秒批量刷盘，SELECT 线程不会被阻塞。
注意：这不是“牺牲一致性”，只要 OS 不崩溃、电源不断，数据就不会丢；生产环境用 2 + sync_binlog = 1 是成熟折中方案。
别忽略 character-set-server = utf8mb4 对索引效率的实际影响
MySQL 8.0 默认就是 utf8mb4，但很多人手动改回 utf8 或漏配 collation-server，导致：
- 字段定义为
VARCHAR(255)但实际只能存 191 个字符（utf8mb4下每个字符最多占 4 字节），索引长度被截断 -
utf8mb4_unicode_ci比utf8mb4_general_ci更准，但排序开销略高；若业务无多语言需求，可用utf8mb4_0900_as_cs（8.0 新 collation，大小写敏感且更快） - 客户端连接未设
init_connect = 'SET NAMES utf8mb4'，会导致隐式转换，让索引失效（例如 WHERE name = '张三' 匹配不到utf8mb4_bin字段）
slow_query_log 开启后反而查得更慢？
不是日志本身慢，是 long_query_time = 2 配得太松 + log_queries_not_using_indexes = ON 导致日志暴增，I/O 压力反噬查询性能。
实操建议：
- 初期设
long_query_time = 0.5，抓出真实瓶颈 SQL，而非等它“慢到明显” - 关掉
log_queries_not_using_indexes，用sys.schema_unused_indexes定期清理无效索引更精准 - 慢日志路径务必放在 SSD 分区（如
/var/log/mysql/slow.log），别和数据目录共盘
最常被跳过的细节：innodb_buffer_pool_instances 在多核 CPU 上必须设为 8 或 16（不能保持默认 1），否则缓冲池锁争用会让并发查询排队等待——这点在 24 核以上机器上尤为致命。
