上周和一个做后端开发的朋友聊天，他吐槽说公司某个系统最近慢得像蜗牛，用户投诉电话都快被打爆了。排查下来，问题出在一张表——数据量才几十万行，但每次查询都要跑好几秒。他翻出建表语句一看，主键索引倒是建了，但业务查询条件全是其他字段，根本没走索引。这种场景太熟悉了，我敢说十个系统里至少有八个慢查询，根子都在索引设计上。
很多人觉得数据库索引只是个辅助工具，建几个主键、唯一索引就够了。但现实是，索引设计才是数据库性能的命门。你想想，一张表就像一本厚书，没有目录的话，想找一句话就得从头翻到尾。索引就是那个目录，帮你快速定位数据。问题在于，很多人只建了“书名”级别的目录，却忘了用户查的是“章节标题”或“关键词”。比如电商系统的订单表，用户最常查的是“订单状态”“下单时间”“用户ID”，如果索引只建在“订单ID”上，每次查询都得全表扫描。
更麻烦的是，索引设计不是“多建就完事”那么简单。每个索引都要占用磁盘空间，写入数据时还得同步更新索引，索引多了，写入速度反而会下降。我见过一个极端案例，某公司的日志表为了“全面覆盖查询”，建了20多个索引，结果每次插入一条日志都要花半秒，因为要更新这些索引树。这就像给一本书做了20个目录，翻书时爽了，但写书时累得要死。所以索引设计是个平衡术：既要覆盖高频查询，又不能拖累写入。
那到底怎么设计索引才靠谱？核心就一句话：从业务查询出发，反向推导索引。别管表结构多复杂，先去问运维和产品经理：用户最常用的查询是什么？筛选条件有哪些？排序字段是什么？比如用户中心系统，最常查的是“用户手机号”和“注册时间”，那联合索引就优先建这两个字段。而且顺序很重要：等值条件放前面，范围条件放后面。比如“状态=1 AND 创建时间>2024-01-01”，联合索引应该是(状态, 创建时间)，而不是反过来。
有些开发者喜欢用“万能索引”，把一张表的所有字段都塞进一个索引。这其实是个大坑。索引列数越多，占用的存储空间越大，查询时索引树也越深，性能反而下降。更关键的是，MySQL 这类数据库有“最左前缀”原则：只有当查询条件匹配了索引的最左侧字段时，索引才能生效。比如建了(a,b,c)的联合索引，但查询条件只有 b 和 c，索引就废了。所以别贪心，索引字段控制在 3‑5 个以内，并把最常用的筛选条件放最左边。
还有一个容易被忽视的细节：索引覆盖。简单说，就是查询所需的字段全部包含在索引里，这样数据库不用回表查原始数据，直接读索引就能拿到结果。比如订单表，用户只查“订单号、金额、状态”，那联合索引就建在这三个字段上，查询时走索引直接返回，速度能快十倍。我优化过一个报表系统，把原本需要 0.8 秒的查询降到 0.02 秒，就是靠覆盖索引。但要注意，覆盖索引会增加存储成本，适合高频且字段少的查询。
当然，索引设计不是一劳永逸的。业务在变，数据量在涨，索引也得跟着调。我建议每季度做一次慢查询日志分析，把执行超过 100 毫秒的查询挑出来，看看是否因为索引未命中。还有一种常见问题：索引失效。比如对索引字段用了函数运算（WHERE DATE(time)='2024-01-01'），或者用了模糊查询加通配符（WHERE name LIKE '%张三%'），这些都会让索引失效。遇到这种情况，要么改写 SQL，要么建函数索引。
想说，索引设计没有银弹。别迷信网上的“万能索引模板”，每个系统的数据分布、查询模式都不一样。比如金融系统，核心是事务一致性，索引要少而精；而日志系统，写入量大查询少，索引甚至可以不建。关键是养成习惯：每次建表前，先画一张查询场景清单，列出最频繁的 10 条查询，然后针对性地设计索引。这个步骤花不了 10 分钟，却能省下后面加索引、改表结构的大把时间。毕竟，数据量小的时候还能靠硬件扛，等数据涨到千万级，索引不合理，神仙也救不了。
