MySQL性能调优需破除认知偏差：索引滥用会拖慢写入、误导优化器、浪费资源；慢查询日志仅设阈值会漏掉高频临界查询和响应抖动；分页查询须用EXPLAIN验证执行计划。
MySQL性能调优不是堆硬件、加索引、改参数就能一劳永逸的事。很多团队投入大量精力，效果却微乎其微，问题往往出在认知偏差和操作惯性上。
索引滥用：越多越好？其实是写入拖垮+查询更慢
给每个字段都建索引、为每个WHERE条件单独建单列索引、重复创建功能重叠的索引——这些做法看似“保险”，实则埋雷：
- 每次INSERT/UPDATE/DELETE都要同步更新所有相关索引，写入延迟翻倍，高并发下连接堆积明显
- 优化器面临更多索引路径选择，可能选错执行计划（比如该走联合索引却用了低效单列索引）
- 已存在(a,b)联合索引时，再建INDEX(a)属于冗余，白白浪费磁盘与内存
- 低基数字段（如status、gender）建索引几乎无效，优化器大概率直接跳过
慢查询日志当“终点站”，漏掉响应抖动和高频临界查询
只盯着long_query_time阈值（比如1秒）来捕获慢查询，会系统性忽略两类关键问题：
- 大量执行时间在400–900ms之间的查询，单次不超阈值，但并发一上来就引发P95响应飙升、用户卡顿
- 慢查询日志不记录执行成功但耗时波动大的请求（如因锁等待、Buffer Pool争用导致的瞬时抖动）
- 缺少直方图统计，无法看清响应时间分布——你看到的是“平均120ms”，实际可能是80%请求
建议搭配Percona Toolkit或pt-query-digest做聚合分析，并接入Prometheus+Grafana看P95/P99趋势。
查不出问题就调参数：缓冲池、连接数、日志刷盘…全调一遍？
盲目修改innodb_buffer_pool_size、max_connections、innodb_flush_log_at_trx_commit等参数，常导致：
- buffer_pool设得过大，挤占系统内存，触发swap，IO反而恶化
- max_connections调太高，未配对调整OS文件句柄限制，启动即报Too many open files
- 为求性能把innodb_flush_log_at_trx_commit=2，却忽视主从延迟与崩溃丢失1秒事务的风险
参数调优必须基于真实负载特征：先用SHOW ENGINE INNODB STATUS和performance_schema定位瓶颈类型（是Buffer Pool命中率低？还是log write wait高？），再针对性调整。
SQL本身写得糙，再好的索引也白搭
很多性能问题根源不在数据库，而在SQL写法。常见硬伤包括：
- SELECT *：回表多、网络传输大、缓存利用率低，尤其宽表+大分页时极易OOM
- 隐式类型转换：WHERE phone = 13800138000（phone是VARCHAR），触发全表扫描
- 函数操作索引列：WHERE DATE(create_time) = '2025-12-01' → 改成create_time BETWEEN '2025-12-01 00:00:00' AND '2025-12-01 23:59:59'
- OR连接未索引字段：WHERE a = 1 OR b = 2（b无索引）→ 全表扫描；改用UNION或补索引
- 分页越深越慢：LIMIT 1000000, 20 → 改用游标分页（WHERE id > last_id ORDER BY id LIMIT 20）
每条SQL上线前，务必跑EXPLAIN，重点盯type（避免ALL/INDEX）、key（是否命中索引）、Extra（警惕Using filesort/Using temporary）。
