SQL高并发性能提升核心是让数据库“少干活、快响应、不堵车”，关键在索引设计、语句写法、连接控制和缓存协同四方面：查得快需精准建联合索引并避免函数操作；写得稳要分片、乐观锁与异步化；连得省须用连接池加限流；缓得准则按业务维度缓存、删缓存而非更新、失败重试告警。
SQL高并发性能提升，核心不是堆硬件，而是让数据库“少干活、快响应、不堵车”。重点在索引设计、语句写法、连接控制和缓存协同这四块，下面结合真实高频场景讲清楚怎么落地。
查得快：索引不是越多越好，而是要精准匹配查询模式
比如用户中心常见的“按手机号查用户”或“按订单号查订单”，如果只在 id 上建了主键索引，而查询条件是 phone 或 order_no，就会全表扫描——并发一上来，CPU 和 I/O 直接拉满。
- 对高频 WHERE 字段（如 phone、status、create_time）建联合索引，注意字段顺序：等值查询字段放前面，范围查询（如 >、BETWEEN）放后面
- 避免在索引字段上做函数操作，WHERE DATE(create_time) = '2024-01-01' 会失效索引，改成 WHERE create_time >= '2024-01-01' AND create_time
- 用 EXPLAIN 看执行计划，重点关注 type=range/const/ref，避开 ALL（全表扫描）
写得稳：高频插入/更新别锁表，分而治之是关键
秒杀场景下，10 万用户同时抢同一商品，如果直接 UPDATE stock SET num = num - 1 WHERE sku_id = 123，所有请求串行排队等行锁，响应时间飙升甚至超时。
- 把单库存拆成多分片，比如按 sku_id % 16 分 16 个库存表或字段，分散锁竞争
- 用乐观锁替代悲观锁：加版本号字段 version，UPDATE 时带上 AND version = ?，失败后重试，避免长事务阻塞
- 非核心写操作异步化，比如日志记录、积分变更，走消息队列延迟落库
连得省：连接不是“用了就扔”，复用和限流才能扛住流量峰
一个 Web 请求开一个数据库连接，5000 QPS 就可能创建 5000 个连接，MySQL 默认 max_connections=151，早崩了。
- 务必使用连接池（如 HikariCP），设置合理 maxPoolSize（一般设为 CPU 核数 × 2～4）、minIdle 和 connectionTimeout
- 应用层加接口限流（如 Sentinel 或 Nginx limit_req），防止突发流量击穿数据库
- 短连接改长连接，但要配合 wait_timeout 和 interactive_timeout 配置，避免空闲连接堆积
缓得准：缓存不是万能胶，要懂什么该缓、什么时候失效
用户资料页每次打开都查一次 DB，QPS 1000 就压垮单库；但缓存乱用也会导致数据不一致，比如修改密码后头像还显示旧的。
- 读多写少、实时性要求不高的数据优先缓存（如商品类目、配置项、用户基础信息）
- 缓存 key 要带业务维度，比如 user:profile:12345，别用泛泛的 user:info
- 写操作后主动删缓存（Cache Aside 模式），而不是更新缓存；删除失败要加重试 + 告警，避免脏数据长期滞留
基本上就这些。高并发不是一步到位的优化，而是从慢查询日志里找瓶颈、用监控看连接和锁等待、靠压测验证改动效果——小步快跑，每改一点，都得有数据支撑。
