政务库3000万行数据，索引乱建拖垮系统根治实录

最新推荐文章于 2026-09-10 23:25:00 发布

原创最新推荐文章于 2026-09-10 23:25:00 发布 · 389 阅读

本内容遵循CC 4.0 BY-SA版权协议

政务库3000万行数据，索引乱建拖垮系统根治实录

去年在阜阳做不动产登记系统二期运维的时候，我遇到了从业以来最离谱的一次数据库故障。那天下午三点政务大厅的办事窗口突然全部卡住，不动产查询页面转圈半分钟直接白屏，数据库服务器CPU直接冲到100%，连接池瞬间被打满，新的业务请求根本连不上库。我们紧急切了备机，不到半小时备机也被拖垮，整个政务服务直接停摆。最后排查下来，问题根源就是开发团队为了临时解决一个慢查询，随手给表加了7个索引，后续没人清理，半年下来这张3000万行的不动产登记表上堆了29个冗余索引，写入性能直接被拖垮，加上几个没优化的全表扫描SQL，直接把整个系统干崩了。那次故障之后我才真正意识到，数据库工程里的索引策略根本不是“建得越多越快”，恰恰相反，乱建索引比没索引的危害要大10倍。

一、故障回溯：从窗口卡顿到根因定位

故障发生的时候，我们第一时间登上数据库服务器，top命令看CPU使用率四个核心全跑满，IO等待直接冲到60%以上，show processlist里几百个连接全部处于“statistics”和“Sending data”状态，根本没法正常执行查询。一开始我们以为是有人写了恶意SQL，把慢查询日志打开之后扫了一眼，发现TOP 10的慢查询里，有6条都是走了全表扫描，执行时间全部超过了20秒。 1、我们先拿pt-index-usage工具扫了全库所有索引，结果出来之后所有人都傻了：核心业务表estate_register上一共建了29个索引，其中18个索引从创建那天起，从来没有被任何一条SQL使用过，完全是死索引。剩下的11个索引里，还有5个是完全冗余的，比如已经建了联合索引(cert_type, register_time)，又单独建了cert_type的单列索引，完全没有存在的意义。 2、接着我们用Explain逐条分析那几条慢SQL，发现有一条查询不动产权证编号的SQL，开发人员明明给cert_no字段建了普通索引，但是执行计划里type还是ALL，直接走了全表扫描。仔细一看才发现，SQL里写的是where cert_no = 123456，但是cert_no字段是varchar类型，隐式类型转换直接让索引失效了，等于白建。 3、最后统计写入性能指标，单表的每秒写入TPS峰值只有不到80，正常情况下这个表的写入TPS至少能跑到500以上，20多个无用索引每次插入数据都要同步更新，直接把写入性能拖到了原来的1/6。

二、索引清理与重构的工程化落地

当时政务系统不能长时间停机，我们制定了非常稳妥的分步优化方案，全程业务零中断，用了三天时间把所有问题全部解决。 1、第一步先做索引标记，所有未使用的索引全部重命名，前缀改成idx_deprecated_，保留72小时观察期，观察期内如果没有任何SQL用到这些索引，再执行删除操作。我们分了三批删除索引，每天最多删6个，每次删完之后立刻观察慢查询日志和服务器负载，确认没有异常再继续下一步，全程没有引发任何二次故障。 2、第二步重构核心查询的索引，针对不动产查询最高频的“权利人+证件类型+登记时间”组合查询，我们设计了联合覆盖索引，把查询条件、返回字段全部放进索引，让查询不需要回表：

CREATE INDEX idx_estate_owner_cert_time ON estate_register(

owner_name, cert_type, register_time,

cert_no, address, register_status

);

这个索引上线之后，之前那条跑20秒的查询直接降到了25毫秒，性能提升了800倍。 3、第三步修复隐式类型转换的问题，把所有相关SQL里的查询参数改成字符串类型，同时给cert_no字段的查询单独补充了一个选择性极高的唯一索引，不动产权证编号的等值查询耗时直接稳定在1毫秒以内。整个优化完成之后，这张3000万行的核心表上的索引数量从29个降到了7个，服务器CPU日常使用率从之前的85%降到了15%，写入TPS从80回升到了520，所有慢查询全部清零，政务窗口再也没有出现过卡顿的情况。

三、政务库索引策略的避坑经验

经过这次故障，我总结出了政务类数据库索引建设的几条铁律，这么多年一直沿用至今。 1、单张核心业务表的索引数量绝对不能超过8个，超过这个阈值之后，写入性能的损耗会开始指数级上升，后续维护成本也会成倍增加。 2、所有新增索引必须走评审流程，开发人员不能直接在生产环境建索引，必须提交Explain前后对比报告，经过DBA和技术负责人双重审核之后才能上线。 3、每个月做一次全库索引巡检，用sys.schema_unused_indexes视图排查未使用的索引，及时清理冗余垃圾，避免索引越堆越多。 4、绝对禁止在字符串字段上用数字类型做等值查询，隐式类型转换是政务库里最常见的索引失效原因，90%的开发人员都踩过这个坑。