SQL高并发优化核心是“减负担”，80%靠SQL写法与索引设计：遵循最左前缀建联合索引、避免函数操作、用覆盖索引、下推过滤条件；配合连接池调优、读写分离、熔断降级及定期更新统计信息。
SQL高并发性能提升，核心不在“加机器”，而在“减负担”——减少锁争用、降低查询复杂度、避开全表扫描、让数据更靠近请求。真正有效的优化，80%来自SQL写法和索引设计，20%来自配置与架构微调。
索引不是越多越好，而是要精准匹配查询模式
很多团队盲目建索引，结果写入变慢、查询仍卡顿。关键看执行计划（EXPLAIN）里是否真用了索引、是否走了索引下推、是否避免了回表。
- 联合索引要遵循最左前缀原则，比如 WHERE status = ? AND user_id = ? ORDER BY created_at，适合建 (status, user_id, created_at)
- 区分度低的字段（如 gender、is_deleted）单独建索引意义很小，但作为联合索引的首列可能拖垮效率
- 用 SELECT * 容易触发回表；改成只查索引覆盖字段（或加 INCLUDE 列，SQL Server/PostgreSQL 支持），能直接走覆盖索引
高并发下的 SQL 写法，本质是“让数据库少干活”
一条慢 SQL 在 QPS=100 时可能拖垮整个库；而一个合理拆分的轻量查询，在 QPS=5000 也能稳住。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 避免在 WHERE 中对字段做函数操作：WHERE DATE(create_time) = '2024-01-01' → 改成 WHERE create_time >= '2024-01-01' AND create_time
- 分页慎用 LIMIT 10000,20：偏移量越大越慢；改用游标分页（WHERE id > last_seen_id ORDER BY id LIMIT 20）
- 大表 JOIN 前先过滤：把 WHERE 条件尽量下推到 JOIN 子句内，别让数据库先拼出百万行再筛选
连接池 + 读写分离 + 热点降级，是高并发的三道安全阀
单靠SQL优化扛不住突发流量，必须配合服务层协同控制。
- 连接池大小 ≠ 并发数：通常设为 CPU 核数 × (2～4)，过大会导致上下文切换和锁竞争加剧
- 读多写少场景，优先走从库；但注意主从延迟，用户刚下单就查订单列表？得走主库或加缓存兜底
- 对超时、失败、慢查询做分级熔断：比如商品详情页查不到库存，可返回默认值或兜底图，而不是让整个接口 hang 住
别忽略统计信息和执行计划老化问题
MySQL/PostgreSQL 的查询优化器依赖表的统计信息做决策。如果数据量突增、分布剧变，旧的执行计划可能突然变差，但你没动过 SQL。
- 定期更新统计信息：ANALYZE TABLE（MySQL）、ANALYZE（PostgreSQL）
- 留意执行计划是否“跳跃式变化”：今天走索引，明天走全表？大概率是统计不准或参数设置不合理（如 innodb_stats_auto_recalc 关闭了）
- 对关键 SQL 可固化执行计划（MySQL 8.0+ 支持 SPM，PostgreSQL 可用 extended query protocol 绑定）
基本上就这些。高并发 SQL 优化不复杂，但容易忽略细节。重点始终是：看执行计划、测真实数据、控查询边界、留降级余地。
