SQL高并发优化核心是让数据库少做事、快做事、做对事，关键在合理索引（如联合索引）、查询拆分、缓存前置、事务瘦身、异步化及聚合降级。
SQL高并发性能提升，核心不在堆硬件，而在“让数据库少做事、快做事、做对事”。真实场景中，90%的瓶颈不是SQL写得慢，而是查询逻辑不合理、索引没用对、事务拖太久、数据分布不均或缓存没接住流量。
索引不是越多越好，而是要精准匹配查询模式
某电商订单系统在大促时QPS破万，但red">order_status = 'paid' AND created_at > '2024-06-01'这类查询响应超2s。分析发现：只在order_status建了单列索引，而实际查询总是带时间范围——MySQL无法高效跳过大量已支付但时间久远的记录。
- 改成联合索引 (created_at, order_status) 或 (order_status, created_at)（按选择性高低排序），性能直接降到80ms以内
- 注意：如果查询中created_at常用范围扫描，它放索引最左列更利于B+树定位；若order_status值非常离散（如100+状态），且常等值过滤，则优先放左边
- 用 EXPLAIN FORMAT=TREE 看执行计划是否走了索引、是否用了index condition pushdown（ICP）
复杂查询别硬扛，该拆就拆，该缓就缓
某SaaS后台需实时展示“每个客户近30天的成交金额、退款率、复购次数、TOP3商品”，原SQL含4个子查询+2层JOIN+窗口函数，平均耗时1.7s，高峰期直接超时。
- 把“TOP3商品”这类强聚合、弱实时需求，改用异步任务每小时预计算，结果存入customer_summary_daily表
- “成交金额”和“退款率”虽需实时，但可拆成两条独立查询——应用层合并，避免MySQL在一次执行中反复扫描同一张大表
- 对客户ID加布隆过滤器前置拦截无效请求；高频客户ID走Redis Hash缓存聚合结果，TTL设为15分钟，命中率超82%
事务越短越好，读写分离只是辅助，不是解药
某金融系统转账接口因SELECT ... FOR UPDATE锁住整行太长，导致并发写入排队严重。问题不在没读写分离，而在事务里干了不该干的事：
- 原流程：查余额 → 校验风控规则（调外部HTTP） → 更新余额 → 写日志 → 发MQ → 返回，整个事务长达1200ms
- 优化后：查余额 + 校验本地规则 → 仅更新余额（20ms内提交）→ 其余步骤全异步化
- 风控调用改成本地规则引擎缓存+轻量校验；日志用Logstash采集binlog；MQ消息由监听binlog的服务投递
- 补充：对热点账户（如平台商户），用account_id % 16分片更新，避免单行锁争抢
统计类查询别总盯着SQL，先看数据是不是必须实时
某BI看板每5秒轮询“各区域销售额TOP10”，底层查的是亿级明细表，即使加了索引也撑不住。后来发现业务方真正需要的是“感知趋势”，而非毫秒级精确值。
- 将原始订单流接入Flink，按区域+小时滚动聚合，结果写入sales_hourly_agg宽表
- BI查询从查明细 → 查聚合表，响应从1.4s → 45ms，数据库压力下降70%
- 对“必须实时”的个别指标（如当前小时完成订单数），用MySQL 8.0的COUNT(*) OVER (PARTITION BY region ORDER BY created_at)配合覆盖索引实现低开销窗口计数
基本上就这些。高并发下的SQL优化，本质是权衡：一致性 vs 延迟、实时性 vs 成本、开发效率 vs 运维复杂度。没有银弹，但有清晰路径——先看清瓶颈在哪条链路上，再选最省力的杠杆点撬动。
