SQL高并发性能提升核心是优化查询而非堆硬件，需减少锁争用、降低IO压力、避免全表扫描、控制连接资源，并通过索引优化、查询瘦身、事务精简及架构分层等手段系统性解决瓶颈。
SQL高并发性能提升，核心不是堆硬件，而是让查询更快、更轻、更稳。重点在减少锁争用、降低IO压力、避免全表扫描、控制连接资源——这些才是压测时最常暴露的瓶颈点。
索引优化：别只建索引，要建对索引
高频WHERE、ORDER BY、JOIN字段必须有索引；但单列索引≠万能，复合索引要注意最左前缀原则。比如查询 WHERE status = ? AND created_at > ? ORDER BY updated_at DESC，推荐建 (status, created_at, updated_at) 而非三个单列索引。
- 用 EXPLAIN 看执行计划，确认是否走了索引（type=ref/const，key不为NULL）
- 避免在索引列上做函数操作：WHERE YEAR(created_at) = 2024 会失效，改用 created_at BETWEEN '2024-01-01' AND '2024-12-31'
- 大表加索引建议在低峰期操作，MySQL 5.6+ 支持在线DDL，但仍有性能影响
查询瘦身：少查、少算、少传
高并发下，每多返回1个字段、每多算1次COUNT(*)、每多JOIN一张表，都可能放大延迟和内存压力。
- 禁止 SELECT *，只取业务真正需要的字段
- 分页慎用 LIMIT 1000000, 20，改用游标分页（如 WHERE id > last_id ORDER BY id LIMIT 20）
- 聚合统计类查询尽量走预计算或缓存，实时查大表COUNT(*)是典型反模式
- 避免在SQL里拼接复杂逻辑，把计算交给应用层或物化视图
连接与事务：小事务 + 短连接 + 合理隔离
长事务=长锁等待=高并发雪崩起点。很多慢查其实不是SQL慢，是被别的事务堵住了。
- 事务内只包必要SQL，避免在事务中调用外部API、写日志、休眠
- 读多写少场景，把隔离级别从REPEATABLE READ降为READ COMMITTED（MySQL默认），减少间隙锁
- 用连接池（如HikariCP），限制最大连接数，防止数据库被打满；空闲连接及时释放
- 写操作优先用INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE，比先查后插更原子、更高效
架构辅助：该绕开数据库时就别硬刚
再好的SQL也扛不住百万QPS的直接冲击。高并发必须配合分层减压策略。
- 热点数据必上Redis缓存，注意缓存穿透（布隆过滤器）、击穿（互斥锁）、雪崩（随机过期时间）
- 写多读少场景考虑CQRS，读写分离到不同库，查用宽表/ES，写走主库
- 超大表按时间或ID哈希分表（如user_202401、user_202402），配合ShardingSphere等中间件
- 异步化：非关键路径的日志、通知、统计，扔进消息队列延迟处理
基本上就这些。没有银弹，但每一条落地都能明显缓解高峰期的“查询排队”“锁等待”“CPU打满”。先从慢查询日志和监控（如Percona PMM、MySQL Performance Schema）定位真实瓶颈，再精准下手——比盲目加索引、调参数管用得多。
