如果压测发现数据库是瓶颈，通常怎么优化？

按"先减压、再扩容、再改架构"的顺序处理。先看能不能用缓存、索引、SQL 优化解决问题，再考虑升级实例规格，等真的不够了才上读写分离、分库分表这类伤筋动骨的改造。绝大多数项目在前两步就能扛过去，没必要一开始就把架构做得很重。

第一步通常是"减压"，这类优化性价比最高：

• 加缓存：把高频读、变化少的数据放到 Redis，命中率上去之后数据库连接数会明显下降。比如商品详情、用户信息、字典表、首页推荐
• 优化慢查询：用慢日志找出 Top 10 慢 SQL，看是缺索引、走全表扫、还是 join 太多。一两个慢查询往往就拖垮整库
• 拆分大事务：把一个长事务拆成几个短事务，减少锁等待
• 异步化写入：日志、统计、消息推送类的写入丢到队列里，让数据库专注核心业务

第二步是"扩容"。云数据库升一档配置，把内存和 IOPS 提上去，往往能直接撑过一个量级。这一步成本可控、风险小，应该是数据库瓶颈的首选解法之一。

第三步是"改架构"，到这一步才考虑：

• 读写分离：主库只写、从库只读，前提是业务能接受主从延迟
• 垂直拆分：把不同业务模块的数据库拆开（订单库、用户库、日志库分别独立）
• 水平分片：单表数据量太大才考虑（一般是亿级以上），按用户 ID 或时间分片
• 冷热数据分离：历史数据迁到归档库，主库只保留近期热数据

我们在做高并发 IoT、电商和直播类项目时基本都走过这套流程。一般初期都能用前两步解决，到第三步通常是业务确实跑出来了，那时再做架构调整反而风险更低，因为已经有真实的访问模式可以参考。提前过度设计的"高并发架构"在中小规模阶段反而会拉高运维成本。