直接结论：innodb_buffer_pool_size、innodb_log_file_size和innodb_flush_log_at_trx_commit协同调优是提升mysql读写性能最有效的三步；buffer_pool需按可用内存科学计算避免oom，log_file_size过小引发checkpoint卡顿、过大延长恢复时间，flush_log参数选1/2/0本质是数据安全分级而非单纯性能排序。
直接结论：innodb_buffer_pool_size 配对合理、innodb_log_file_size 和 innodb_flush_log_at_trx_commit 协同调优，是提升 MySQL 读写性能最实际有效的三步。其他参数调得再细，这三项没踩准，性能就卡在 I/O 瓶颈上。
为什么 innodb_buffer_pool_size 必须先算准，不能直接填“总内存×75%”
物理内存不是全给 MySQL 的，OS 和其他进程（比如监控 agent、logrotate、备份脚本）必须留足空间。填大了会触发系统 OOM Killer 杀掉 mysqld 进程——这不是慢，是直接宕。
- 专用数据库服务器：用
free -m看available值，扣掉 1~2GB 给 OS，剩余的 70%~80% 才是安全上限 - 混合部署（如跑着 Nginx + PHP-FPM）：先
ps aux --sort=-%mem | head -10看常驻进程内存占用，再从available里减掉，剩下的 60%~70% 才是innodb_buffer_pool_size的天花板 - MySQL 8.0+ 要求对齐：若
innodb_buffer_pool_instances = 8（推荐值），默认innodb_buffer_pool_chunk_size = 128M，那最小单位就是8 × 128M = 1024M；填49g会被自动向下取整到48g，别指望它真用上 49G
innodb_log_file_size 太小会导致写入卡顿，但改大有风险
日志文件太小（比如默认 48MB），事务频繁刷满日志，就会阻塞提交——表现为 Innodb_log_waits > 0 持续上升，INSERT/UPDATE 延迟跳高。但盲目设成 2GB，重启恢复时间可能长达数分钟，主从延迟也会拉长。
- 观察指标：执行
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';，非零就要调 - 安全范围：单个日志文件建议 256MB~1GB，总日志容量（
innodb_log_files_in_group × innodb_log_file_size）控制在 2~4GB 内 - 修改前提：必须停库，删旧日志（
ib_logfile0,ib_logfile1），再启动——否则 MySQL 启动失败
innodb_flush_log_at_trx_commit 怎么选：1、2、0 不是性能排序，是数据安全分级
这个参数本质是在“每事务刷盘”、“每秒刷一次”、“只刷内存”之间做权衡。选错不是变慢，是丢数据。
-
=1（默认）：每次COMMIT都强制写盘，ACID 最强，但写吞吐受限于磁盘 fsync 延迟 -
=2：日志写入 OS 缓存即返回，每秒由后台线程fsync一次。断电可能丢失 1 秒内事务，但写性能提升明显，适合大多数业务 -
=0：日志只留在内存，每秒刷盘。崩溃可能丢最多 1 秒数据，且 MySQL 异常退出时日志未持久化，恢复可能失败——生产环境慎用 - 注意：设为 2 或 0 时，必须配合
sync_binlog = 1（MySQL 5.7+ 默认）才能保证主从一致性，否则 binlog 和 redo 日志不同步
真正难的不是记住这些值，而是每次改完都要盯住三个实时指标：Innodb_buffer_pool_read_requests 与 Innodb_buffer_pool_reads 算出命中率（目标 ≥95%）、Innodb_log_waits 是否归零、Threads_running 在压测时是否稳定不飙升。缓存和日志参数从来不是孤立生效的，它们咬合在一起工作——漏掉任一环，优化就只停留在配置文件里。
