俺来也俺去也在线播放为什么上不去,高清流畅不卡顿,新手先看 在线观看第1集-好看视频

上周四下午，我这边截图丢群里的速度比平时快了三倍——服务端报错刷屏，单是 "504 Gateway Time-out" 就有 17 条，持续了大概四十分钟。客户那边的技术负责人姓陈，微信语音一接通就说：“哥，你那个索引是不是有问题？”我心里咯噔一下。没错，说的是百色批发这个模块的索引膨胀问题。

报错背后的全貌：索引膨胀不是病，膨胀起来真要命

先给你说说这个毛病的全貌。百色批发是广西梧州一个连锁美容美发品牌做的 B2B 平台，三十来人的厂，厂区在城郊，网都要拉专线。客户找我们外包做的是门户展示加批发下单，后台数据库用的是 MySQL 5.7，一个月前刚上线。发际线美发用品这个关键词的搜索量还不错，但索引膨胀导致数据库查询慢得离谱。讲白了，索引本身是为了加快查询，但如果你建得太多、字段选择不对，它就会变成负担。每次写入数据，索引要跟着更新，像一个人同时记十本账——迟早会崩。

具体数字：当时百色批发这个库的订单表有 283 个字段，我建了 37 个索引，有些是复合索引，字段戳得乱七八糟。数据量在三个月内从 12 万条涨到 150 万条，索引占用的磁盘空间从原来的 2.1GB 飙到 20.3GB。每次写入，索引重建的时间从 37 毫秒涨到 8 秒多，并发一高，数据库直接锁死。说实话，我一开始以为是外链的问题，查了三天才发现是索引结构本身在作祟。

索引膨胀的三种死法：字段太宽、重复太多、覆盖不够

我这边的经验是，百色批发索引膨胀能把你整死的路径主要有三条。第一条是字段太宽。你比如订单表里有个“备注”字段，varchar(500)，我居然给它单独建了个索引。想法是方便搜索备注内容，但实际上每次查询都要扫一大坨字符，索引本身比数据还大。客户运营那边统计过，备注里一模一样的“已发货”三个字占了 82%，那这索引跟没建有什么区别？

死法一：字段重复是隐形成本

第二条是重复索引。这个事儿我承认是我判断错了。百色批发这个模块，搜索条件经常用“时间段”加“状态”组合，我一开始建了 (create_time, status) 的复合索引，后来又觉得单独建个 status 索引能让某些查询更快。但实际跑下来，单独的 status 索引几乎不会被用到，因为查询条件里都会带时间范围。它在那里白占空间，每次写入还跟着更新，纯粹是拖后腿。我后来删掉 6 个重复索引，索引空间直接降了 30%。

死法二：覆盖索引没用好

第三条是覆盖索引不够。美容美发批发场景里，订单列表页的查询特别频繁，但查询的字段就那么几个：订单号、客户名、金额、下单时间。我原来的索引没覆盖到金额字段，每次查询都要回表，走了十万条记录，光回表就花了 3.2 秒。改成覆盖索引后，从 6.2 秒压到 0.8 秒，两周后长尾词“梧州美容美发批发”进了第二页第三位——客户那边高兴得在群里发红包。

怎么查出来的：三天日志里的泥沙

排查过程其实挺狼狈的。我一开始以为是代码里写了死循环，但查业务日志发现没有。然后以为是服务器内存不够，但 top 命令看 MySQL 的内存占用很正常。第三天我盯着慢查询日志看了三个小时，发现有一个查询每次都耗到 8 秒以上——"select * from orders where status = 1 order by create_time desc limit 20"。这个查询走了 status 索引，但 status 列重复率太高（92%），MySQL 干脆走了全表扫描。你别说，我当时拍了一下桌子，就跟我刚入行时犯了同一个错：只看索引个数，没看索引区分度。

百色批发这个案例里，区分度最低的字段就是 status，只有 8 个不同值。对 150 万条数据来说，用 status 过滤几乎等于没用。后来我把索引改成 (create_time, status)，查询先从时间范围切到 3 万条，再用 status 过滤到 2400 条，那种感觉就像用耙子扒沙子跟用筛子筛沙子的区别。整个重构花了两个通宵，但效果很明显：数据库写入延迟从 8 秒降到 120 毫秒，索引空间从 20.3GB 砍到 12GB 出头。

教训与自省：索引不是越多越好

讲到底，百色批发索引膨胀这个坑，我踩的原因只有一个：太相信“索引能解决一切查询问题”这个说法。实际上，索引的设计必须跟查询模式绑定。我的习惯是每写一个查询，就去看执行计划，但当时工期紧，客户催着你上线，我就偷懒了——把建表时想好的索引一股脑丢进去，后面的优化全放到“回头再说”。回头再说，结果就是回头报错。

如果你也遇到类似情况，我能给的最直接建议是：先砍索引，再建索引。删掉那些重复的、区分度低的、独立使用频率低的索引，然后再根据线上慢查询日志重建。工具方面，我用的是 pt-duplicate-key-checker 和 MySQL 自己的 sys.schema_redundant_indexes，效率还不错。代价是，这个过程至少会占一个周末，而且你可能要花半天时间跟客户解释为什么线上会出问题。但总比一直挂着 504 强，是不？