并发控制需用连接池（如hikaricp）并最小化事务；索引应匹配查询模式、遵循最左前缀与覆盖原则；慢查询须通过explain优化，避免全表扫描；读写分离优先于分库分表，后者仅在数据量与qps超限且优化穷尽时采用。
并发控制：合理设置连接池与事务粒度
数据库吞吐量瓶颈常不在SQL本身，而在连接争用和长事务阻塞。应用层应避免“一个请求一个连接”，改用连接池（如HikariCP），并根据实际负载调整maxPoolSize（通常设为CPU核数×2～4，配合监控调整）。事务务必最小化——只包裹真正需要ACID保障的操作，避免在事务内调用远程接口、处理大文件或执行复杂计算。例如，下单流程中“扣库存+写订单”需事务，但“发短信通知”应异步落库后由消息队列触发。
索引设计：聚焦高频查询路径与覆盖原则
索引不是越多越好，而是要匹配查询模式。优先为WHERE、JOIN、ORDER BY、GROUP BY中出现的字段建索引；复合索引注意最左前缀匹配（如索引(a,b,c)，能加速WHERE a=1 AND b=2，但对WHERE b=2无效）。尽量使用覆盖索引——让SELECT字段全部落在索引B+树叶子节点，避免回表。例如查询SELECT user_id, status FROM orders WHERE shop_id = ? AND created_at > ?，可建联合索引(shop_id, created_at, user_id, status)，既满足过滤又覆盖输出。
慢查询治理：从执行计划入手，拒绝全表扫描
定期用EXPLAIN分析慢日志中的SQL，重点关注type（应避免ALL/INDEX）、rows（预估扫描行数）、Extra（警惕Using filesort、Using temporary）。常见陷阱包括：对索引字段使用函数（WHERE YEAR(created_at) = 2024 → 改为created_at BETWEEN '2024-01-01' AND '2024-12-31'）；模糊查询前置通配符（LIKE '%abc'无法走索引）；NULL值判断导致索引失效（IS NULL在部分场景下不走索引，可考虑默认值替代）。
读写分离与分库分表：按业务阶段渐进落地
单实例吞吐见顶时，优先考虑读写分离：将报表、搜索等只读流量路由到从库，主库专注写入。注意从库延迟风险，对强一致性读（如刚下单查订单）仍打主库。当单表数据超千万、QPS持续超3000且索引优化已达极限，再评估分库分表——选择业务维度（如用户ID、店铺ID）做分片，避免跨库JOIN和分布式事务。切记：分库分表是最后手段，不是性能银弹。
