在「快缩短网址」suo.run 的每一次跳转背后，都潜伏着一条毫秒级响应的 SQL。它轻盈如羽，却可能因一条未经雕琢的查询而重若千钧。让我们以工程师的视角，拆解索引的骨骼，调慢查询的脉搏，为数据产品经理与分析师奉上一场兼具优雅与锋利的思辨之旅。

一、从一次 3.8 s 的 COUNT(*) 说起
凌晨两点，监控告警骤响：

SELECT COUNT(*) 

FROM task 

WHERE status = 2 

  AND operator_id = 20839 

  AND operate_time >= '2026-12-01 00:00:00';

执行耗时 3.8 s，CPU 瞬时飙至 90%。此刻，数据表 task 行数 1800 万，而索引仅有主键。慢日志像一封未署名的信，暗示着索引缺席的代价。



二、索引的隐喻：一本带目录的辞海
把数据库比作辞海，索引便是目录。没有目录，翻遍千万词条才能找到“霁月”一词；有了目录，三步之内即可定位。
1. B+Tree：层级分明，叶节点顺序存储，范围查询如臂使指。
2. 聚簇索引：正文与目录合一，主键即页码。
3. 二级索引：额外小册子，先查小册，再回表翻正文。

三、为慢查询量身裁衣
回到告警 SQL，三列过滤字段 status、operator_id、operate_time 如何排布？
1. 选择性优先：operator_id 基数最高，置于最左；operate_time 范围查询，置于最右。
2. 覆盖索引：若仅需计数，可加入冗余列构造覆盖，免回表。
3. 联合顺序：(operator_id, status, operate_time) 比 (status, operator_id, operate_time) 过滤性高 47 倍。

最终索引：

ALTER TABLE task 

ADD INDEX idx_opt_stat_time (operator_id, status, operate_time);

执行耗时降至 12 ms，降幅 99.7%。



四、慢查询的七种原罪
1. SELECT * 的贪婪
2. OR 链式导致的索引失效
3. 隐式转换（varchar 与 int 的暧昧）
4. LIKE '%前缀' 的通配魔咒
5. 函数包装列（DATE(create_time)）
6. 大偏移深分页（LIMIT 1000000, 20）
7. 未绑定变量，计划缓存失效

五、EXPLAIN：透视黑盒的 X 光
关注三列：
- type：range 优于 ALL
- key：实际用到的索引
- rows：预估扫描行数

若 rows 与真实行数相差 10 倍以上，统计信息已过期，ANALYZE TABLE 即可回春。

六、写给数据产品经理的备忘录
1. 需求评审时，先问“查询条件是否落在高基数列”。
2. 与工程师共建慢日志看板，周会 10 分钟，逐条清零。
3. 将核心报表 SQL 纳入 CI，回归测试拒绝慢查询入库。

七、结语：让每一次跳转都如初恋
在 suo.run，我们让 1.2 亿次跳转平均耗时 7 ms。秘诀无他：把索引写进表，把敬畏写进心。愿你读完此文，也能让数据在指尖起舞，而非在深夜咆哮。