扎伊采夫规则为啥重要？看完这些实例就明白

今天大半夜被报警短信吵醒，服务器又卡成狗了。揉着眼睛连上数据库，发现用户表查询速度跟蜗牛爬似的。凌晨三点二十三分的监控截图显示，一个简单的用户信息查询居然花了12秒——这破表里拢共才五十万条数据！

一、病急乱投医

我抄起键盘就给用户表加了三个索引：按注册时间建一个，按手机号建一个，还顺手给昵称字段也建了个。结果你猜怎么着？查询速度直接暴跌到28秒，服务器CPU报警声响得跟救护车似的。气得我当场抓掉三根头发，这破索引越加越慢！

二、翻技术黑历史

突然想起前年做的订单系统，当时给交易状态字段建了索引。那字段就四种状态：待付款、待发货、待收货、已完成。结果每次点"查询进行中订单"，数据库就跟便秘似的。后来删了索引反而秒开，当时还以为活见鬼了。

翻出当年的执行计划记录：

• 加索引前：全表扫描0.8秒
• 加索引后：索引查询+回表要3.4秒

三、扎老师救命

在技术论坛扒拉到凌晨五点，终于看到有人说「数据基数小的字段别乱建索引」。搜「数据库索引 坑」的关键词，跳出来个「扎伊采夫规则」——名字拗口得跟俄罗斯化肥似的。

规则核心就两句话：

• 字段值的种类少于总数的20%别建索引



• 值特别少的建索引等于自杀

立马打开用户表算数据：

• 性别字段：就男/女/未知三种
• VIP等级：0-6级总共7种



• 账户状态：正常/冻结两种

全是扎老师点名批评的重灾区！

四、现场开刀做手术

抄起剪刀把刚建的三个索引全删了，只保留用户ID主键索引。接着用扎老师教的筛选器：

• 手机号（50万独立值）✓
• 最近登录时间（40万不重复）✓
• 注册IP（38万唯一值）✓

给这三个字段建完复合索引，查询时间从28秒啪地掉到0.2秒！服务器监控图瞬间从珠穆朗玛峰变东非大平原。

五、血泪经验总结

上个月带新人做商品表优化，那小子又在商品颜色字段建索引（总共就红/白/黑/金四色）。我直接当着全组面演示：

1. 查红色商品：走索引0.5秒
2. 查黑色商品：全表扫描0.8秒

新人瞪眼看执行计划——数据库发现有30%数据是黑色，直接放弃索引！扎老师规则再次显灵：值太少会被优化器嫌弃，值太多又没意义，活像炒菜放盐的玄学。

晚上特地在文档里标红：

• 布尔值字段禁止建索引 ❌
• 状态码少于10种的别碰 ❌
• 经常被批量更新的绕道走 ❌

写完突然笑出声——去年这时候我还在往用户状态字段猛建索引，这打脸来得贼疼！