SQL高并发性能提升关键在于精准识别瓶颈、分层优化与合理取舍，聚焦慢查询、锁竞争、连接耗尽、缓存失效四类问题，通过索引优化、锁控制、连接池调优和分级缓存实现稳态提升。
SQL高并发性能提升，核心不在“堆硬件”或“换数据库”，而在于精准识别瓶颈 + 分层优化 + 合理取舍。多数场景下，90%的高并发压力其实来自少数几类典型问题：慢查询堆积、锁竞争激烈、连接资源耗尽、缓存缺失或失效。解决它们，不需要全盘重构，关键是快速定位、小步验证、稳住线上。
查得快：索引不是越多越好，而是要“刚好够用”
高并发下，一条没走索引的查询可能拖垮整个连接池。但盲目加索引反而加重写入开销和维护成本。
- 先用 EXPLAIN 或 EXPLAIN ANALYZE 看执行计划，重点关注 type=ALL（全表扫描）、rows 过大、Extra 中出现 Using filesort 或 Using temporary
- 联合索引遵循最左前缀原则，WHERE 条件中能覆盖的字段顺序要和索引定义一致；比如查询 WHERE status = ? AND created_at > ?，索引应建为 (status, created_at)，而非反过来
- 避免在索引字段上做函数操作（如 WHERE YEAR(created_at) = 2024），改用范围查询：created_at BETWEEN '2024-01-01' AND '2024-12-31'
锁得住但不卡死：减少锁粒度与冲突时间
InnoDB 默认行锁，但若没走索引，会升级为表锁；长事务、大事务、不必要 SELECT ... FOR UPDATE，都会放大锁等待。
- 确保所有 UPDATE/DELETE 语句都命中索引，否则可能锁住整张表
- 事务尽量短——只包真正需要原子性的逻辑；不要在事务里调外部接口、发邮件、做复杂计算
- 读多写少场景，优先用 SELECT ... LOCK IN SHARE MODE 替代 FOR UPDATE；确认无并发写需求时，直接用一致性非锁定读（默认隔离级别下普通 SELECT 就是）
- 监控 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS，及时发现长事务和锁等待链
连得稳：连接池不是越大越好，而是要“刚够用+可回收”
连接数超限会导致新请求排队甚至拒绝服务，但连接池过大又浪费内存、增加上下文切换开销。
- 应用端连接池最大值建议设为 DB 最大连接数的 60%~80%，留出空间给运维命令、后台任务等
- 设置合理的 maxLifetime（如 30 分钟）和 idleTimeout（如 10 分钟），避免僵死连接占用资源
- 开启 testOnBorrow 或更轻量的 validationQuery（如 SELECT 1），但别用耗时语句验证
- 用 SHOW PROCESSLIST 或 performance_schema.threads 查看真实活跃连接，区分“真忙”和“假空闲”
缓得巧：不是所有数据都值得缓存，也不是缓存越深越好
缓存能扛住 80% 的读流量，但用错方式会引发脏读、雪崩、击穿等问题。
- 高频、低更新、业务容忍短时 stale 的数据适合缓存（如配置表、用户基础信息）；订单详情、库存余额等强一致性场景慎用缓存，或结合版本号/时间戳校验
- 缓存穿透：对不存在的 key 做布隆过滤，或缓存空值（带短 TTL）
- 缓存雪崩：不同 key 设置随机 TTL，避免集中过期；核心数据加本地缓存（Caffeine）作二级兜底
- 缓存击穿：热点 key 加互斥锁（如 Redis SETNX），只放一个线程回源加载，其余等待
基本上就这些。高并发 SQL 优化不是一锤定音的事，而是持续观察（慢日志、Performance Schema、应用埋点）、小步迭代、灰度验证的过程。工具只是辅助，真正关键的是对数据访问路径的清晰理解——谁在读、谁在写、读写频率如何、一致性要求多高。抓准这几点，优化自然有方向。
