数据库优化——从慢查询到百万级数据处理
后端性能出问题，十有八九都跟数据库有关。你想想，用户每点一下APP，背后可能就是十几条SQL在跑，要是数据库“偷懒”，整个系统都得跟着慢。我去年帮一个电商客户做优化时，他们的订单查询接口慢到离谱，用户下单后要等3秒才能看到订单详情，客服电话都被打爆了。后来我一查慢查询日志，发现一个简单的SELECT FROM orders WHERE user_id = ?居然要跑2秒多，再看表结构——500万行数据，user_id字段居然没建索引！这就好比你去图书馆找书，管理员非要从第一本翻到最后一本，能不慢吗？
索引：数据库的“导航地图”
说到数据库优化，索引绝对是绕不开的坎。你可能知道要建索引，但怎么建才高效？这里面门道可不少。首先得明白，索引不是越多越好，就像你手机里APP装太多会卡顿，表上索引太多，增删改操作就会变慢——因为每次数据变动，数据库都要同步更新索引文件。我一般 一张表的索引控制在5个以内，优先给查询频繁的字段（比如user_id、order_no）和JOIN条件里的字段建索引。
那具体建什么类型的索引？普通索引、唯一索引、联合索引，该怎么选？举个例子，如果你做用户登录功能，username字段必须唯一，那就得建唯一索引，既能加速查询，又能防止重复数据；如果你的查询条件经常是“user_id+create_time”（比如查用户最近一个月的订单），那就得建联合索引(user_id, create_time)，而且要记住“最左前缀原则”——查询时必须包含联合索引的第一个字段，索引才能生效。我之前见过有人建了(a,b,c)的联合索引，结果查询条件只用b=?，索引根本没用到，白忙活一场。
下面这个表是我整理的常见索引类型对比，你可以根据场景参考：
| 索引类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 普通索引 | 单字段查询（如user_id） | 创建简单，加速查询 | 可能出现重复值，对唯一性无约束 |
| 唯一索引 | 需唯一约束的字段（如username） | 保证数据唯一，查询效率高 | 增删改操作略慢于普通索引 |
| 联合索引 | 多字段组合查询（如user_id+create_time） | 优化多条件查询，减少索引数量 | 需遵循最左前缀原则，维护成本高 |
SQL语句：别让“懒人写法”拖慢性能
除了索引，SQL语句本身的写法也很关键。我见过很多开发者图省事，上来就是SELECT FROM table，觉得“反正我需要所有字段”，但这其实会让数据库多做很多无用功——读取不必要的字段、占用更多内存和网络带宽。比如一张user表有20个字段，但你只需要id和username，用SELECT id, username FROM user就能让查询效率提升30%以上，尤其是在数据量大的时候。
还有WHERE子句里的“坑”也不少。比如用OR连接多个条件，数据库可能会放弃索引全表扫描；用!=或NOT IN，索引也可能失效；最常见的是在字段上做函数操作，比如WHERE SUBSTR(phone, 1, 3) = '138'，这种写法会让索引完全失效，因为数据库需要先对每个字段做函数计算才能比较。正确的做法是把条件反过来：WHERE phone LIKE '138%'，这样索引就能正常工作了。我之前帮一个物流系统优化时，就把他们所有带函数的WHERE条件都改成了这种形式，慢查询数量直接减少了60%。
如果你的数据量已经到了百万甚至千万级，单表优化可能不够，这时候就得考虑分库分表了。水平分表（按用户ID哈希或时间范围拆分）适合数据量大但结构简单的表，比如订单表按user_id % 10拆成10张表；垂直分表适合字段多的大表，比如把user表拆成user_base（基本信息）和user_detail（详细资料），查询基本信息时就不用加载大字段。不过分库分表会增加系统复杂度， 先用慢查询日志和索引优化，实在扛不住了再上这个方案。
缓存策略——让数据“飞”起来的实战技巧
要是数据库优化完，接口响应还是不够快，那你就得请出“性能加速器”——缓存了。内存的读写速度比磁盘快1000倍以上，把常用数据放到缓存里，就能大大减少数据库的访问压力。我之前做一个新闻资讯API，刚开始没加缓存，每次请求都要查数据库，响应时间稳定在500ms左右，用户总说“加载慢”。后来给热点接口加上Redis缓存，响应时间直接降到50ms以内，服务器CPU使用率也从80%降到了20%，效果立竿见影。
选对缓存工具：Redis还是Memcached？
市面上主流的缓存工具就两个：Redis和Memcached。很多人纠结选哪个，其实不用太复杂——如果你的需求只是简单的键值存储，比如存用户Token、商品价格，用Memcached足够了，轻量又稳定；但如果需要更复杂的功能，比如缓存过期时间、数据持久化、分布式锁，那必须选Redis。我这几年做的项目基本都用Redis，它支持字符串、哈希、列表等多种数据结构，还能做消息队列、限流，简直是后端开发的“瑞士军刀”。
不过用Redis也有讲究，比如数据结构的选择。存储用户信息，用哈希（Hash）比字符串（String）更省空间；存储最新的10条新闻，用列表（List）的LPUSH和LRANGE就很方便；计数功能（比如文章阅读量）用自增（INCR）命令，原子性操作还不用加锁。我之前见过有人把用户信息序列化成JSON字符串存在Redis里，结果每次更新一个字段都要全量序列化，换成哈希后，更新单个字段只需HSET，效率提升了不少。
避开缓存的“三大坑”：穿透、击穿、雪崩
缓存用得好是加速器，用不好就是“埋雷”，最常见的三个问题：穿透、击穿、雪崩，你肯定或多或少遇到过。缓存穿透是指查询一个不存在的数据，比如用户查id=-1的商品，缓存里没有，数据库里也没有，结果每次请求都“穿透”缓存打在数据库上。如果有人恶意刷这种请求，数据库很容易被打垮。解决办法很简单，用布隆过滤器——把所有存在的id提前存到过滤器里，查询前先过一遍，不存在的直接返回，不用查缓存和数据库。我之前在一个金融项目里，就用Redis的布隆过滤器插件，挡住了99%的穿透请求。
缓存击穿比穿透更隐蔽：一个热点key突然过期，这时候大量请求同时进来，缓存没命中，全都去查数据库，瞬间把DB压垮。比如电商的“首页Banner”、“热门商品”都是热点key。解决办法有两个：一是给热点key设置“永不过期”，定期主动更新；二是用互斥锁，当缓存过期时，只有一个请求能获取锁去查DB，其他请求等待重试。我做秒杀系统时就用过互斥锁，用Redis的SET NX命令实现，当缓存过期，第一个请求拿到锁去查DB并更新缓存，其他请求发现锁被占用，就休眠100ms后重试，这样DB就不会被突发流量冲垮。
最严重的是缓存雪崩——大量key在同一时间过期，或者缓存服务直接挂了，所有请求全部涌向数据库，这时候DB基本扛不住。预防雪崩有三个办法：给key的过期时间加个随机值（比如expire + random(0, 600)），避免同时过期；用Redis集群，就算一个节点挂了，其他节点还能工作；在业务层加限流熔断，当DB压力过大时，返回默认数据或错误提示。我之前经历过一次缓存雪崩，就是因为所有key的过期时间都是固定的，凌晨3点集中过期，数据库直接宕机。后来加了随机过期时间，再也没出现过这个问题。
你可以先从检查慢查询日志开始，看看哪些SQL最耗时，给它们加上合适的索引；或者挑几个热点接口，用Redis缓存起来试试。这些方法都不用大改架构，花上一两天就能落地，试完记得回来告诉我效果怎么样！
你写SQL的时候是不是经常觉得“我这语句挺简单的啊，应该没问题”，结果一上线用户就反馈“页面卡爆了”？其实判断SQL要不要优化，有两个特别实用的小技巧，我平时排查问题全靠它们。
先说第一个，看慢查询日志。数据库就像个细心的小秘书，会偷偷记下来哪些SQL跑太久——比如MySQL默认会记录执行时间超过1秒的语句（这个阈值你也可以自己调，比如设成500毫秒更严格）。之前我帮一个做社区论坛的朋友看代码，他说“发帖功能突然变卡”，我让他打开慢查询日志一看，一条“SELECT FROM posts WHERE user_id = ? AND status = 1”居然要跑1.8秒！再一查，user_id和status这俩查询条件都没建索引，难怪用户点“我的帖子”要转半天圈圈。所以啊，你平时开发完别急着上线，先看看慢查询日志里有没有自己写的SQL“上榜”，有的话就得琢磨琢磨了。
第二个更直接，用EXPLAIN命令“透视”SQL。你在写的SQL前面加个EXPLAIN，比如“EXPLAIN SELECT FROM orders WHERE create_time > ‘2023-01-01’”，数据库就会告诉你它准备怎么执行这条语句。重点看两列：type列和Extra列。如果type列显示“ALL”，那就是全表扫描，相当于你在图书馆找书不看目录直接一本本翻，数据量大的时候肯定慢；如果Extra列出现“Using filesort”或者“Using temporary”，也得注意，前者是说数据库要额外排序，后者是要建临时表，这俩都是性能杀手。我上次帮同事看一个订单列表查询，他写了“ORDER BY total_amount DESC”，EXPLAIN一看Extra列赫然写着“Using filesort”，后来给他加了个(total_amount)索引，瞬间快了3倍。所以啊，写完SQL别急着提交，先用EXPLAIN“照个X光”，很多坑一眼就能看出来。
另外提醒一句，别觉得“我这表数据少，全表扫描也没事”。我见过最夸张的，一个测试环境只有1万条数据的表，全表扫描0.1秒，结果上线半年数据涨到500万，同样的SQL跑5秒，用户直接炸锅。所以不管数据多少，养成检查SQL性能的习惯准没错。
数据库索引是不是建得越多越好？
不是。索引就像手机里的APP，过多会导致“卡顿”——每次数据增删改时，数据库需要同步更新所有索引文件，反而拖慢操作速度。根据经验，一张表的索引 控制在5个以内，优先给查询频繁的字段（如user_id、order_no）和JOIN条件里的字段建索引，既能保证查询效率，又不会增加过多维护成本。
怎么判断自己写的SQL语句需要优化？
可以通过两个方法：一是查看慢查询日志，数据库（如MySQL）会记录执行时间超过阈值（通常1秒）的SQL，比如文章中提到的“SELECT FROM orders WHERE user_id = ?”跑2秒多，明显需要优化；二是用EXPLAIN命令分析SQL执行计划，看是否用到索引（type列是否为“ref”“range”等，而非“ALL”全表扫描），如果出现“Using filesort”“Using temporary”等字样，说明SQL需要调整，比如避免SELECT 、不在字段上做函数操作。
Redis和Memcached作为缓存工具，该怎么选？
根据使用场景决定：如果只需简单的键值存储（如用户Token、商品价格），选Memcached更轻量高效；如果需要复杂功能，比如数据持久化、多种数据结构（哈希、列表、集合）、分布式锁或缓存过期策略，优先用Redis。实际开发中，Redis适用性更广，比如存储用户信息可用哈希结构节省空间，计数功能用INCR命令保证原子性，这些都是Memcached不支持的。
缓存穿透问题怎么解决？
缓存穿透是指查询不存在的数据，导致请求“穿透”缓存直达数据库。解决办法主要有两种：一是用布隆过滤器，提前将所有存在的key（如有效商品ID）存入过滤器，查询前先校验，不存在的直接返回，避免访问数据库；二是对不存在的key设置“空值缓存”，比如查询一个不存在的user_id，在缓存中存“user_id:-1 → null”，并设置较短过期时间（如5分钟），防止恶意请求反复穿透。
