高并发下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) = '2024-01-01'），会导致索引失效
- 大表 ALTER TABLE 加索引务必在低峰期，并考虑使用 pt-online-schema-change 工具，避免锁表
分库分表要“有节奏”，别一上来就拆
单表超 2000 万行或日增 50 万以上写入时，才需认真评估分片。过早分片带来分布式事务、跨库 JOIN、全局 ID 等复杂问题，收益远低于成本。
PHP5 和 MySQL 圣经
下载
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。
- 优先用垂直拆分：把大宽表按业务域拆开（如用户基础信息、用户扩展属性、用户登录记录分三张表甚至三个库）
- 水平分片推荐按业务主键哈希或范围分片，避免热点（如用 user_id % 8 分 8 库，比按时间分片更均匀）
- 务必配套全局唯一 ID 方案（如 Snowflake、数据库号段模式），禁止用自增主键跨库
缓存不是银弹，要用对位置、设好边界
缓存能抗读，但引入一致性风险。重点不是“要不要加 Redis”，而是“哪些数据值得缓存”以及“怎么保一致”。
- 缓存粒度宜粗不宜细：缓存整条订单记录，优于缓存 order_status、pay_time 等多个字段
- 更新时采用“先删缓存，再更新 DB”策略（Cache Aside），并加延迟双删（如更新后休眠 500ms 再删一次），降低脏数据窗口
- 对缓存穿透（查不存在的 key）、击穿（热点 key 过期瞬间大量请求打到 DB）、雪崩（大量 key 同时过期）要有兜底：布隆过滤器、逻辑过期、随机过期时间
不复杂但容易忽略。真正决定高并发成败的，往往是连接管理是否合理、索引是否真正生效、分片是否真有必要、缓存是否真的可控。每一步都得拿线上慢查日志、监控指标和压测结果说话，而不是凭经验拍板。
