高并发下MySQL性能优化需聚焦稳定性与一致性，核心策略包括：读写分离与连接池精细化控制、精准索引设计、有节奏分库分表、合理缓存应用及边界管控。
高并发场景下，MySQL 往往成为性能瓶颈。关键不在“扛住多少 QPS”，而在于如何让数据库在读写压力下保持稳定、低延迟和数据一致性。以下是从真实项目中沉淀出的几条核心应对策略。
读写分离 + 连接池精细化控制
单库扛高并发读请求极易打满 CPU 和 IO。必须将查询流量导向从库，写操作只走主库。但要注意：从库延迟不可忽视，对实时性要求高的查询（如订单支付结果）不能盲目走从库。
- 用中间件（如 ShardingSphere、MyCat）或应用层路由实现读写分离，避免硬编码导致后期难维护
- 连接池（如 HikariCP）最大连接数不宜设过高——MySQL 默认 max_connections 通常为 151，连接数超限会直接拒绝新连接；建议应用端连接池 size 控制在 20–50，配合连接复用和短连接优化
- 为不同业务模块划分独立数据源（如用户中心用一组主从，订单中心另配），防止单点故障扩散
索引不是越多越好，而是要“查得准、写得稳”
高频查询必须有覆盖索引，但滥用索引会拖慢写入、增加 B+ 树分裂开销。重点
看执行计划（EXPLAIN），而非“有没有加索引”。
- 联合索引遵循最左匹配，把区分度高、WHERE 中高频出现的字段放前面；例如 (status, create_time, user_id) 比 (user_id, status, create_time) 更适合“查某状态下的最新 10 条”场景
- 避免在索引字段上做函数操作（如 WHERE DATE(create_time) = '2025-01-01'），会导致索引失效
- 大表 ALTER TABLE 加索引务必在低峰期，并考虑使用 pt-online-schema-change 工具，避免锁表
分库分表要“有节奏”，别一上来就拆
单表超 2000 万行或日增 50 万以上写入时，才需认真评估分片。过早分片带来分布式事务、跨库 JOIN、全局 ID 等复杂问题，收益远低于成本。
- 优先用垂直拆分：把大宽表按业务域拆开（如用户基础信息、用户扩展属性、用户登录记录分三张表甚至三个库）
- 水平分片推荐按业务主键哈希或范围分片，避免热点（如用 user_id % 8 分 8 库，比按时间分片更均匀）
- 务必配套全局唯一 ID 方案（如 Snowflake、数据库号段模式），禁止用自增主键跨库
缓存不是银弹，要用对位置、设好边界
缓存能抗读，但引入一致性风险。重点不是“要不要加 Redis”，而是“哪些数据值得缓存”以及“怎么保一致”。
- 缓存粒度宜粗不宜细：缓存整条订单记录，优于缓存 order_status、pay_time 等多个字段
- 更新时采用“先删缓存，再更新 DB”策略（Cache Aside），并加延迟双删（如更新后休眠 500ms 再删一次），降低脏数据窗口
- 对缓存穿透（查不存在的 key）、击穿（热点 key 过期瞬间大量请求打到 DB）、雪崩（大量 key 同时过期）要有兜底：布隆过滤器、逻辑过期、随机过期时间
不复杂但容易忽略。真正决定高并发成败的，往往是连接管理是否合理、索引是否真正生效、分片是否真有必要、缓存是否真的可控。每一步都得拿线上慢查日志、监控指标和压测结果说话，而不是凭经验拍板。
