聊到数据库优化，很多人第一反应就是“加索引”“上缓存”。但如果真去问那些能把查询速度从几秒压到几十毫秒的人，他们往往会说，真正管用的不是某个单一技巧，而是一整套组合拳。今天我就把这套打法拆开，用五个最接地气的策略跟你聊透——不是抄文档，而是实实在踩过坑后总结的经验。
先说第一个策略：别让索引变成累赘。索引用好了是神器，用烂了就是拖油瓶。我见过太多人在每个字段上都加索引，觉得多多益善。结果呢？写入速度慢得像蜗牛，查询也没快多少。正确的做法是先拿慢查询日志开刀，找出执行频率高、耗时长的 SQL，再针对性建索引。而且别忘了联合索引——比如你查询 ，单独给 status 和 createdat 各建一个索引，还不如建一个 的联合索引。索引覆盖也是个好东西：如果查询只涉及索引里的字段，数据库根本不用回表，速度能翻倍。我上次优化一个电商订单表，把三个单列索引换成两个联合索引，查询时间直接从 800 ms 降到 40 ms，就这么简单粗暴。
第二个策略：改写 SQL，别跟数据库过不去。很多时候查询慢，不是数据库不行，而是 SQL 写得太“蠢”。比如最常见的 ，明明只需要两个字段，却把整行数据拖出来，网络和内存都是浪费。改成具体字段名，效果立竿见影。再比如 ，通配符在前导致索引失效，只能全表扫描。如果业务允许，改成 ，索引就能用了。还有 条件——，数据库会拆成两个查询再合并，效率极低。换成 或者用 分开写，速度能快好几倍。我优化过一个报表查询，原来用 关联三个条件跑了 6 秒，改成 后降到 0.3 秒。记住：写 SQL 时想象自己在跟数据库对话，让它少干活、干轻活。
第三个策略：分库分表和读写分离，别让单库扛所有。当数据量上千万甚至上亿，单库再优化也扛不住。这时就需要战术。读写分离是第一步：主库负责写，从库负责读，把查询压力分散出去。别小看这一步，很多中小公司的查询瓶颈就是读请求太多，把主库拖死。更狠的是分库分表，按业务维度或时间切分。比如用户表按用户 ID 哈希分到多个库；订单表按月份分表，查询历史订单时直接定位到对应表。我见过一个社交 App，动态表数据量 10 亿+，原来查询列表要 5 秒以上，按用户 ID 分库后，每个库只有几百万数据，查询降到 50 ms 以内。不过分库分表有代价：跨库查询、排序、聚合都变得复杂。所以别一上来就搞分片，先确认数据量和增长趋势，再决定是否实施。
第四个策略：缓存别只想着 Redis，要分层配合。很多人一提缓存就想到 Redis，但缓存不是银弹，用不好反而更慢。正确的做法是分层缓存：第一层是应用内缓存，比如本地内存（Caffeine）存热点数据，毫秒级响应；第二层是 Redis 这类分布式缓存，存高频但不太变化的数据；第三层才是数据库。为什么？因为本地缓存比 Redis 快得多，而且没有网络开销。我优化过一个商品详情页，原来所有请求都走 Redis，QPS 到 5000 时 Redis 成了瓶颈。后来加了本地缓存，热点商品直接命中内存，Redis 负载降到原来的 20%，整体查询延迟从 30 ms 降到 5 ms。但要注意：缓存必须考虑失效和更新策略。我见过一个项目，缓存更新不及时，用户看到的数据比数据库慢了半小时，直接引发投诉。所以“缓存穿透”“缓存雪崩”“缓存击穿”这三大坑，必须在设计时就想好应对方案。
第五个策略：字段设计和数据类型，细节决定成败。很多人觉得表结构设计是 DBA 的事，开发随便写就行。但恰恰是这些“小细节”能让查询速度差十倍。比如时间字段，用 DATETIME 还是 TIMESTAMP？后者只占 4 字节，前者 8 字节，而且 TIMESTAMP 能自动处理时区。再比如状态字段，用 VARCHAR 存 “active”“inactive”还是用 TINYINT 存 0、1？后者占空间更小，索引效率也更高。还有，别在数据库里存 JSON、TEXT 这种大字段，除非真的需要。我优化过一个用户表，里面有个 字段存 JSON，占了每行几百字节。后来把它拆到另一张表，主表查询速度直接翻倍。另外，尽量使用 NOT NULL，因为 NULL 会让索引更复杂，查询时还要额外处理。这些细节单个提升不大，但叠加起来效果惊人。
说回开头那句话，数据库优化不是玄学，而是把这些基础策略扎实落地。索引别随意加，SQL 别乱写，数据别硬扛，缓存别滥用，字段别浪费。把这些都做到位，查询速度翻十倍真的不是吹的。我见过太多团队，上来就想上分布式、上分片、上各种高大上的中间件，结果基础的索引和 SQL 优化都没做好。记住：先学会走路，再想着跑。
