MySQL 你一般调优哪些参数？
五个经典回答示范
我按三层调优：连接层——max_connections 配合 thread_cache，避免频繁建线程；内存层——innodb_buffer_pool_size 是第一大参数（物理内存五到七成）、脏页刷新策略调平滑；日志层——sync_binlog 与 innodb_flush_log_at_trx_commit 的组合权衡双 1 最安全最慢、非核心业务放宽到 10 或 2。前提原则：先看状态变量与慢查询定位瓶颈，再动参数，压测验证。
我讲一次调优实战：业务高峰写抖动严重。诊断：iostat 写压力周期性尖峰，show engine innodb status 显示脏页堆积与刷盘等待。动作：innodb_io_capacity 按盘实际 IOPS 设（SSD 设 2000 而不是默认 200）、脏页比例上限调低让刷新平滑、redo log 加大（ib_logfile_size）减少 checkpoint 抖动；同时 binlog 组提交开起来。效果：写延迟 P99 从 300ms 降到 60ms。参数调优必须配套压测前后数据，否则是玄学。
资深视角：参数调优在优化金字塔的位置——架构与 SQL 优化（索引、语句改写、读写分离）收益远大于参数微调，参数是让硬件特性匹配负载。方法论：基线画像（QPS/TPS、读写比、连接模型、数据规模）→ 瓶颈假设（CPU/IO/锁/内存）→ 参数与配置组合验证（sysbench 或回放压测）→ 变更管理与回滚预案。进阶认知：很多『参数问题』实际是版本问题——升级带来的优化器与并行改进常比调参有效。
追问『buffer pool 设多大』：物理内存的 50-70%，但要看是否同机有其他服务；『连接数设多少』：按应用实例数乘每实例连接池上限估算加余量，配合连接错误监控，不是越大越好（内存与上下文切换代价）；『双 1 是什么』：sync_binlog=1 加 flush_log_at_trx_commit=1，任何提交不丢，金融场景必须，代价是写吞吐。
『MySQL 慢就调参数，网上抄个 my.cnf 优化模板贴上去，buffer pool 拉满内存，连接数设一万，重启完事。』——点评：模板不看负载画像——读写比不同的库参数方向相反；连接数一万是内存炸弹；不动慢查询只调参数是治标中的治标。
- 打开 模拟练习，选择「运维/DBA」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。