上周和一个做了十年后端的朋友喝酒，他跟我吐槽说，最近被一个慢查询折腾得够呛。系统上线前测试都好好的，一上线用户量一上来，数据库就像老牛拉车，一个页面要转好几秒才出来。他翻来覆去地看慢查询日志，发现是少建了一个索引。就这一个索引，让查询时间从 3 秒降到了 30 毫秒。他说这话时，表情里带着一种“我居然栽在这种事上”的无奈。
这事让我想到，数据库性能优化听起来好像挺高大上，什么分库分表、读写分离、缓存策略，听着就吓人。但其实在绝大多数场景下，真正拖垮数据库的，往往是最基础的东西没做好。比如索引，很多人知道索引能加速查询，却不知道索引用不好反而会拖慢写入。一个表上建了七八个索引，每次插入数据都要维护这些索引树，写入速度自然慢。还有个朋友的公司，表里有个字段存的是 JSON 格式，他们居然在上面建了索引——MySQL 对 JSON 字段的索引是通过虚拟列实现的，他们不知道，结果查询时索引根本没生效，全表扫描跑了一整天。
说到索引，就不能不提它的选择性和基数。很多开发者建索引时喜欢在状态字段上建，比如“是否删除”“订单状态”这种，觉得查询最频繁就该建索引。但实际效果往往很差，因为这类字段的区分度太低。一个订单表里，99% 的订单都是“已支付”，你在“订单状态”上建索引，查询“已支付”时，索引帮不了多少忙，MySQL 仍然要扫大量数据页。相反，数值型、时间型或高基数的字符串字段建索引效果更好。比如根据用户 ID 查询订单，用户 ID 唯一性高，索引能快速定位到具体的数据行。
再说说连接数的问题。我见过不少创业公司，数据库配置用的是默认值，最大连接数只设了 100。用户量稍微上来，连接池就满了，新的请求只能排队等。这时候优化 SQL 都没用，因为系统根本没有资源去执行。更夸张的是，有些团队为了省事，把连接池设得特别大，觉得“越多越好”，结果数据库服务器内存被吃光，上下文切换频繁，性能反而下降。合理的做法是根据服务器配置和业务量来算，比如 4 核 8 GB 的 MySQL，最大连接数设在 200 到 300 左右就差不多了，再往上加，收益递减明显。
缓存策略也是个大坑。很多人觉得加个 Redis 就万事大吉，但缓存和数据库的数据一致性怎么保证，往往想得不够清楚。某电商平台的商品详情页走了缓存，但库存数据是实时写的。他们用了“先删缓存再更新数据库”的策略，结果在高并发场景下，缓存被删了但数据库还没更新完，另一个请求又把旧数据写回缓存，导致库存显示不准。后来改成“先更新数据库再删缓存”，配合延迟双删，才勉强解决。但说实话，没有完美的缓存方案，关键在于业务能否容忍短暂的不一致。比如用户评论，几分钟的延迟用户察觉不到；但支付结果这种，必须强一致。
除了这些，SQL 写法本身也常常是性能瓶颈。很多程序员写 SQL 时习惯用 SELECT *，觉得省事。但一个表如果有几十个字段，你只需要两个，MySQL 仍然要把整行数据读出来，IO 开销大得离谱。还有人在 WHERE 条件里用函数，例如 WHERE DATE(createtime) = '2024-01-01'，这样索引就失效了。改成 WHERE createtime >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'，性能能提升几十倍。这些细节说穿了就是基本功，但正是这些基本功决定了系统能否扛住流量。
说个真实案例。我认识的一个技术负责人，他们公司的数据库在双十一当天挂了，原因是全表锁。排查下来，是一个定时任务跑了个 UPDATE 语句，没走索引，导致全表扫描并锁住了整张表，所有读写操作都堵在那里。后来他们做了两件事：一是把所有定时任务改成只在低峰期跑，二是给 UPDATE 语句的 WHERE 条件加上了索引。就这么简单的改动，系统再没出过问题。数据库性能优化很多时候不是要你搞什么黑科技，而是把这些基础的东西做到位。把索引建对、把 SQL 写对、把连接数调对，比什么都管用。那些花里胡哨的架构方案，等用户量真的到了百万级别再考虑也不迟。
