为什么你的查询总是慢半拍？
你有没有遇到过这种情况：打开一个老项目，点一下搜索，转圈圈转了十秒才出结果。或者导出一份报表，等得咖啡都凉了还没反应。其实问题可能不在服务器，而在于缺少合适的索引创建。
数据库就像图书馆，数据是书。如果没有目录，想找一本《Python入门》只能一本本翻。索引就是给数据库建目录，让系统直接定位到目标位置，不用全表扫描。
什么时候该考虑加索引？
当你发现某些查询特别慢，尤其是带 WHERE、ORDER BY 或 JOIN 的语句，基本就可以怀疑是索引问题。比如用户登录时根据手机号查记录，如果没在手机号字段建索引，每次都要扫几百万条数据，那体验肯定卡。
常见适合建索引的字段包括：主键、外键、状态标记（比如 is_deleted）、时间戳（如 create_time）以及经常用于搜索的字段，像订单号、用户名这类唯一性较高的列。
怎么创建一个有效的索引？
以 MySQL 为例，最简单的语法就是在 ALTER TABLE 后加上 INDEX 关键字：
ALTER TABLE users ADD INDEX idx_phone (phone);这条命令给 users 表的 phone 字段加了个叫 idx_phone 的索引。之后再按手机号查，速度通常能从几秒降到毫秒级。
如果经常按多个条件一起查，比如“状态为激活且注册时间在过去一周”，可以创建联合索引：
ALTER TABLE users ADD INDEX idx_status_time (status, create_time);注意顺序很重要。联合索引遵循最左匹配原则，上面这个索引支持单独查 status，也支持 status + create_time 联合查询，但不支持只查 create_time。
索引也不是越多越好
有人觉得，既然索引能提速，那就每个字段都加上。这其实是误区。每增加一个索引，写入数据时就要多维护一份结构，INSERT、UPDATE、DELETE 都会变慢。而且索引占用磁盘空间，太多会拖累整体性能。
举个例子，一张日志表每天写入十万条，如果你给七八个字段都建了索引，插入速度可能下降一半。这种情况下，宁愿查的时候慢一点，也要保证写入流畅。
更合理的做法是分析慢查询日志，找出真正影响大的 SQL，针对性地建索引。可以用 EXPLAIN 命令看看执行计划，确认是否命中索引。
实际场景中的小优化
有个朋友做后台管理系统，列表页加载特别慢。一看代码，是按部门筛选员工，但部门字段没索引。加上之后，页面打开时间从 8 秒降到 0.3 秒。他自己都说，早知道两分钟的事能省这么多投诉。
还有个电商项目，订单表超过两百万条数据。原本按用户 ID 查订单要两秒多，建了 idx_user_id 索引后，几乎瞬间出结果。用户反馈明显变好了，客服都说少接了不少催单电话。
这些都不是什么高深技术，就是把该建的索引补上。关键是要有意识，在开发阶段就考虑查询路径，而不是等到上线后被用户骂了才去救火。