为什么你的查询总是慢吞吞？
你有没有遇到过这种情况：系统刚上线时查数据飞快，可随着业务增长，同样的查询越来越卡。点一下“搜索”，咖啡都凉了还没出结果。问题很可能出在索引上。
数据库就像一个巨大的电子表格，数据越多，找起来越费劲。索引就是给这张表加目录，让数据库不用全表扫描就能快速定位数据。
别乱建索引，反而拖慢写入
有人一觉得慢，就给每个字段都加上索引。结果呢？新增一条记录要更新十几个索引，写入速度直线下降。这就好比你在Excel里每列都建个筛选器，打开文件都卡。
实际场景中，比如用户登录，我们只关心“用户名”和“密码”。这时候在 username 字段上建索引，查询立刻从几秒降到毫秒级。
CREATE INDEX idx_username ON users(username);复合索引有讲究，顺序不能乱
如果你经常按“城市 + 年龄”筛选用户，别分别建两个单列索引。应该创建一个复合索引，并注意顺序。
一般把区分度高、筛选条件更严格的字段放前面。比如 age 的值比 city 更分散，那就把 age 放前面。
CREATE INDEX idx_city_age ON user_profiles(city, age);这样组合查询能命中索引。但如果你只查 city，也能用上这个索引；反过来只查 age，那就用不上了。
监控慢查询，找出“罪魁祸首”
MySQL 有个 slow query log，可以把执行超过1秒的SQL记下来。定期看看这些“慢家伙”，往往能发现缺失的索引。
比如这条：
SELECT * FROM orders WHERE status = 'pending' AND created_at > '2024-01-01';如果 status 和 created_at 都没索引，就得扫几万行。加上复合索引后，速度立竿见影。
CREATE INDEX idx_status_created ON orders(status, created_at);索引不是一劳永逸，得定期“体检”
业务变了，查询模式也会变。以前查得多的字段，现在可能没人用了。这些“僵尸索引”白白占用空间，还影响写入性能。
可以用数据库自带的工具查看索引使用频率。长期不被使用的，考虑删掉。就像清理手机里不用的APP，释放存储，运行更流畅。