博客后台的文章列表偶尔卡到两秒，打开慢查询日志一看，是分类筛选的查询没走索引。这次排查让我对"索引"这味药有了更完整的认识。

排查过程

先用 EXPLAIN QUERY PLAN 看执行计划，发现 type 是全表扫描。给 category_id 加索引后，查询从两秒降到几十毫秒，立竿见影。

但索引不是免费午餐

每个索引都要占磁盘；每次 INSERT/UPDATE/DELETE，相关索引都要同步维护，写多查少的表盲目加索引反而变慢；低区分度的列（比如只有 0/1 的状态位）单独建索引意义不大，优化器可能直接放弃它。

几条经验

为 WHERE、JOIN、ORDER BY 实际用到的列建索引；组合索引遵循最左前缀；定期看真实的慢查询日志，而不是靠猜；数据量小的时候全表扫描可能比走索引还快，别急着优化。

数据库优化的本质是取舍，离开数据规模和访问模式谈最优解，都是耍流氓。