高并发SQL性能瓶颈在于锁冲突与索引低效，需通过避免全表扫描、缩小事务粒度、统一访问顺序减少锁争抢，并构建覆盖索引、匹配查询模式的复合索引及合理隔离级别（如READ-COMMITTED）来优化。
SQL高并发场景下，性能瓶颈往往不在于单条查询慢，而在于大量请求争抢同一资源——比如行锁、表锁、索引页或热点数据页。解决核心是“减少等待”和“加快处理”，重点在锁冲突规避与索引精准性两方面下手。
锁冲突：从“等锁”到“不抢锁”
高并发写入时，InnoDB 的行级锁若落在同一索引键或相邻索引范围（如 gap lock），极易引发锁等待甚至死锁。关键不是加锁快，而是让事务尽量不碰同一把锁。
- 避免全表扫描更新：UPDATE 或 DELETE 缺少有效 WHERE 条件（尤其没走索引）会升级为表锁或扫描大量索引页，放大锁范围。务必确保修改语句命中唯一索引或高效复合索引。
- 缩小事务粒度：把一个大事务拆成多个小事务，例如分批更新（LIMIT + WHERE id > ?），降低单次持锁时间；业务上允许时，用“先查后更”改为“条件更新”（WHERE version = ?），减少无谓锁竞争。
- 统一访问顺序防死锁：多表更新时，所有事务按固定顺序（如按主键升序）操作记录；对同一组关联数据，始终先更新 user 表再更新 order 表，避免交叉加锁。
索引调优：让查询“秒定位”，让写入“少搬动”
索引不是越多越好，而是要匹配高频查询模式和写入负载。低效索引不仅拖慢查询，还会在 INSERT/UPDATE 时额外维护 B+ 树结构，加剧 IO 和锁开销。
- 覆盖索引减少回表：SELECT name, email FROM user WHERE status = 1 AND created_at > '2024-01-01'，可建联合索引 (status, created_at, name, email)，避免查索引后再回主键聚簇索引取字段。
- 区分“查询索引”和“排序/分页索引”：ORDER BY create_time LIMIT 10 配合 WHERE type = 'pay'，索引应为 (type, create_time)，而非 (create_time, type)——前导列必须匹配 WHERE 等值条件。
- 谨慎使用前缀索引：VARCHAR(255) 字段只取前 10 个字符建索引虽省空间，但可能造成大量重复值，降低选择性；优先考虑完整字段或结合业务选高区分度子串（如邮箱的 @ 后域名部分）。
实战中容易被忽略的细节
很多性能问题藏在配置和习惯里，不显眼却影响巨大。
- READ-COMMITTED 比 REPEATABLE-READ 更适合高并发写：前者不加 gap lock（除唯一索引冲突外），大幅降低范围锁概率；只要业务能接受“不可重复读”，就该默认用 RC。
- 避免 SELECT ... FOR UPDATE 无条件锁定：没 WHERE 或 WHERE 不走索引时，可能锁整张表；务必加 EXPLAIN 验证执行计划，确认只锁目标行。
- 监控 innodb_row_lock_waits 和 innodb_row_lock_time_avg：这两个指标持续升高，说明锁冲突已成常态，比慢查询日志更能提前暴露并发瓶颈。
不复杂但容易忽略：一次精准的索引 + 一次克制的事务 + 一次明确的隔离级别选择，往往比加机器、调缓冲池更立竿见影。
