MySQL 高并发优化核心是减少锁冲突、降低查询开销、分散压力、提升响应确定性，需从 SQL 与索引、事务与锁、架构部署、配置监控四方面系统推进。
MySQL 在高并发场景下，核心优化方向不是盲目加机器或调参数，而是围绕“减少锁冲突、降低单次查询开销、分散访问压力、提升响应确定性”来系统推进。
一、SQL 与索引层面：让查询快且轻量
90% 的高并发性能问题源于低效 SQL。重点做三件事：
- 避免全表扫描 ：每个高频查询必须有覆盖索引，联合索引注意最左匹配；用
EXPLAIN确认type至少是ref或range，避免ALL。 - 精简查询结果：禁止
SELECT *，只查业务真正需要的字段；分页慎用LIMIT 10000,20，改用游标式分页（如WHERE id > last_id ORDER BY id LIMIT 20）。 - 拆分复杂操作：JOIN 多表、子查询、GROUP BY + ORDER BY 混用会显著拖慢响应；能前置到应用层聚合的，就别压给数据库。
二、事务与锁控制：缩短锁持有时间
高并发下锁争用是吞吐瓶颈。关键原则是“快进快出”：
- 事务粒度最小化：只把真正需要 ACID 保障的操作包进事务，非必要不跨表、不跨服务；避免在事务里调外部 API 或做耗时计算。
- 写操作优先走主键更新 ：用
UPDATE …… WHERE id = ?而非WHERE status = 'pending'，后者易引发行锁升级为间隙锁甚至表锁。 - 读已提交（RC）够用就不上可重复读（RR）：RR 隔离级别下 Gap Lock 更重，尤其在范围查询 + 并发插入时容易死锁；除非业务强依赖一致性快照，否则 RC 更轻量。
三、架构与部署策略：分流、缓存、降级
单库总有上限，需靠架构手段卸载压力：
- 读写分离 + 从库分组 ：主库只写，读请求按业务模块 路由 到不同从库（如订单读走 A 组，用户读走 B 组），避免所有读都挤在同一从库。
- 热点 数据兜底缓存：对频繁查询且变更不频繁的数据（如配置表、商品类目），用 Redis 缓存结果，并设置合理过期 + 主动更新机制；注意缓存穿透（布隆过滤器）、击穿（互斥锁）、雪崩（随机 TTL）。
- 冷热分离 + 归档历史数据：将半年前订单移入历史库，当前库只保留活跃数据；既减小单表体积，又降低索引深度和锁竞争面。
四、配置与监控：让优化有据可依
不监控的优化等于蒙眼开车：
- 开启慢查询日志（long_query_time ≤ 1s），配合 pt-query-digest 定期分析 TOP SQL，聚焦影响大的少数几条。
- 关注核心指标：Threads_running（瞬时活跃连接数）、Innodb_row_lock_waits（每秒锁等待次数）、QPS/TPS 趋势、主从延迟（Seconds_Behind_Master）；突增即预警。
- 连接池合理配置：应用端连接池最大值≠数据库 max_connections；建议设为数据库连接数的 60%~80%，并启用连接复用和空闲超时回收。
高并发优化不是一次性动作，而是一个持续观测—定位—收敛—验证的闭环。从一条慢 SQL 开始，比堆参数更有效。
