数据库删表别急，索引有时候还得留着，不然查数据就麻烦了

（根据知乎用户“程序员小富”在相关问题下的分享整理）

“数据库删表别急，索引有时候还得留着，不然查数据就麻烦了”这句话，听起来像是技术圈里的一句玩笑话，但背后其实藏着不少在实际工作中用教训换来的经验，很多人，尤其是刚接触数据库管理或者应用开发的新手，可能会觉得，一张数据表都被决定要删掉了，那附着在这张表上的索引，不就是跟着表一起消失的“附属品”吗？就像房子都拆了，里面的家具自然也就没了，还需要单独考虑家具的去留吗？这么想，从结果上看，表删了索引确实也没了，但问题恰恰出在“删表”这个动作执行之前的那段思考和决策过程里，如果把删表看作一个项目或一个重大变更，那么忽略对索引的评估,很可能在将来埋下意想不到的麻烦种子。

我们得明白索引是干什么的，用一个不太专业但很形象的比喻，数据库的表就像一本厚厚的电话簿，里面记录了所有人的姓名、电话和地址，如果没有索引，你想找“张三”的电话，就只能从第一页开始，一页一页地翻，直到找到为止，这就是所谓的“全表扫描”，速度非常慢，而索引就像是这本书最前面的按拼音排序的姓名目录，你通过目录能迅速定位到“张三”名字所在的页码，直接翻到那一页就能找到信息，速度快了成百上千倍，索引的核心价值就是“加速查询”。

回到“删表”的场景，为什么删表前要考虑索引呢？主要有以下几个容易被忽视的层面。

第一，是删除操作的性能本身可能受索引影响，这个点有点反直觉，一般人会觉得，删表就是一个瞬间完成的命令，管它有没有索引呢？但实际上，对于大型数据库管理系统，删除一张表并非简单地“抹去”数据，尤其是在表数据量非常大（比如几百万甚至上亿行）的情况下，数据库引擎在执行删除操作时，可能需要处理与这些数据相关联的所有索引条目，每一个索引都是一棵小小的“树”或者一个有序的结构，删除主表数据时，数据库需要同步地去所有这些索引结构里把对应的条目也删干净，以保证数据的一致性，索引越多、越复杂，这个“清理现场”的工作量就越大，可能导致删除操作本身耗费的时间远超预期，甚至在高负载的系统上引发短暂的性能波动，在决定删表前，了解表上有哪些索引、数量多少，有助于更准确地预估操作耗时和风险,选择在业务低峰期进行。

第二，也是更关键的一点，索引是数据库设计和业务逻辑的“活化石”，一张生产环境中的表，尤其是核心业务表，它上面建立的索引往往不是凭空而来的，每一个索引的诞生，很可能都对应着一个或多个重要的业务查询需求，可能是某个高频的报表生成、可能是用户端某个关键功能的过滤条件、也可能是后台某个定时任务的核心逻辑，当业务负责人或架构师决定要删除某张表时，他们思考的维度可能是“业务下线了”、“数据模型重构了”、“有新的替代方案了”，当初为了优化那些查询而创建的索引，其背后所代表的业务访问模式，是否也随着表的删除而100%彻底消失了呢？这需要打一个问号。

（根据CSDN博客专家“风一样的码农”在相关技术文章中的观点）

如果在删表前没有仔细审查索引，可能会造成一种“信息割裂”，举个例子，假设公司决定下线一个旧的订单系统，新建一个更先进的系统，旧系统的核心订单表orders_old计划被删除，在删表前，有经验的数据库管理员或开发者会去做一件事：查看orders_old表上的所有索引，他可能会发现，上面有一个联合索引是(customer_id, create_time)，这个索引的存在强烈暗示着，历史上业务层经常需要“查询某个客户在某段时间内的所有订单”，在设计和开发新订单系统时，开发团队就必须确保新的数据模型和API能够高效地支持这个查询需求，如果忽略了旧表索引这个重要的“线索”，新系统可能在没有优化的情况下就直接上线，导致“查询用户历史订单”这个功能性能极差，用户体验大幅下降，到时候再回头排查，才发现是忽略了历史访问模式，但旧表已删,追悔莫及。

第三，索引的存在有助于数据迁移和归档过程的优化，很多时候，“删表”并不是简单粗暴地一删了之，而是伴随着数据迁移或归档的操作，把当前表里的部分冷数据迁移到历史档案库，或者汇总到另一张统计表中，然后再删除原表，在这个过程中，如果原表上存在合适的索引，那么针对迁移条件的查询（例如where create_time < '2020-01-01'）速度会非常快，能极大地提升数据迁移作业的效率，反之，如果缺乏索引，迁移脚本可能跑得慢如蜗牛,严重影响整个项目的进度。

第四，对于临时性或不确定的删除操作，索引的保留思维更重要，有些时候，删表可能是一种“尝试”或“清理”，但后续发现有误，需要从备份恢复，或者，表删除后，突然有临时的、紧急的审计需求，需要查询已经下线系统的历史数据，如果备份恢复流程复杂，而该表恰好有完整的索引，那么查询这些恢复出来的临时数据也会顺畅很多,这是一种更偏向于风险控制和应对意外的考量。

“数据库删表别急，索引有时候还得留着”这个说法，其精髓不在于物理上保留索引（因为表删了索引自然不存在），而在于倡导一种审慎和追溯的思维方式，它提醒我们在执行像删表这样的破坏性操作前，应该“让子弹飞一会儿”，停下来花点时间，把表上的索引列表拿出来好好端详一番，把这些索引当作是读懂过去业务诉求、评估当前操作影响、规划未来系统设计的重要参考资料，通过分析索引，我们可以问自己几个问题：这些索引为什么而建？对应的查询现在还有吗？在新的架构下如何满足？删除操作会不会因为索引太多而变慢？

磨刀不误砍柴工，这种对索引的“留恋”与“审视”，不是技术上的优柔寡断，而是工程师专业性和责任感的体现，能有效避免“表删了，麻烦却来了”的尴尬局面，下次当你手指放在回车键上，准备执行那条DROP TABLE命令时，不妨先敲一个SHOW INDEX FROM [表名]看看,或许会有意想不到的收获。