索引优化是提升查询性能的关键，应针对WHERE、JOIN、ORDER BY和GROUP BY字段建立复合索引，按选择性从高到低排序，并避免在索引列上使用函数或运算。
索引优化：让查询秒出结果
高并发下最常见瓶颈是慢查询，而索引是第一道防线。不是加得越多越好，关键看查询模式：
- 对 WHERE 条件、JOIN 字段、ORDER BY 和 GROUP BY 列建复合索引，顺序按选择性从高到低排（比如
(status, created_at, user_id)比单独建三个单列索引高效得多） - 避免在索引列上用函数或运算，如
WHERE YEAR(create_time) = 2024会让索引失效；改写成WHERE create_time >= '2024-01-01' AND create_time - 定期用
EXPLAIN分析慢查询，关注 type（尽量到ref或range）、key（是否命中索引）、rows（扫描行数）
连接池与查询控制：稳住数据库入口
应用层不控量，再强的数据库也会被压垮：
- 用 HikariCP、Druid 等成熟连接池，设置合理 maxPoolSize（通常设为 CPU 核数 × (2~4)，结合压测调优），避免连接数爆炸
- 所有 SQL 加 query timeout（如 3 秒），防止长事务拖垮整个池；超时自动中断，前端返回“服务繁忙”比卡死更友好
- 禁止在循环里执行单条 INSERT/UPDATE，改用批量操作（
INSERT ... VALUES (...), (...), (...)或 JDBC 的addBatch()）
读写分离 + 缓存穿透防护：分摊压力
高并发场景下，80% 请求是读，把它们从主库摘出来是性价比最高的优化：
- 用 MySQL 主从复制 + 中间件（如 ShardingSphere、MaxScale）自动路由读请求到从库；注意处理主从延迟，对强一致性读（如刚下单查订单）强制走主库
- 加 Redis 缓存热点数据（如商品详情、用户配置），但必须防穿透：缓存空值（带短过期）、布隆过滤器前置校验、接口限流兜底
- 缓存更新用 “先删缓存，再更新 DB，延迟双删”（如更新后 500ms 再删一次），避免脏数据
分库分表与异步化：突破单机极限
当单库单表扛不住千万级日活或亿级数据，就得横向拆解：
- 垂直拆分：按业务域切库（如用户库、订单库、支付库），减少跨库 JOIN，用应用层组装数据
- 水平分片：用 sharding-key（如 user_id 取模、日期范围）分散数据；推荐 ShardingSphere-JDBC 或 MyCat，避免自己手写路由逻辑
- 非核心写操作异步化：日志记录、消息通知、积分变更等，写入 Kafka/RocketMQ，由消费者后台处理，主流程响应控制在 200ms 内
基本上就这些。没有银弹，但每一步都踩准了，QPS 从几百拉到几万很常见。关键是先监控（慢日志、连接数、CPU、QPS），再定位瓶颈，最后按需组合策略——别一上来就分库分表，90% 的性能问题靠索引+连接池+缓存就能解决。
