数据没删干净？表从数据库移除后竟还能继续用，究竟怎么回事

（引用来源：知乎专栏文章《记一次诡异的MySQL数据删除故障排查》作者：某技术博主）

这事儿听起来确实挺邪乎的,就像你把一个文件从电脑桌面上拖进了回收站，并且清空了回收站，结果第二天开机，那个文件的快捷方式居然还能点开，里面的内容也一切正常，这可不是什么灵异事件，在特定的数据库使用场景下，这种情况确实有可能发生。

想象一下这个场景：一个软件系统，比如一个网站或者一个手机APP，它的后端连接着一个数据库，数据库里有很多张表，就像很多个Excel表格一样，存储着用户信息、订单记录等等，有一天，开发人员或者运维人员可能因为系统升级、清理无用数据或者其他原因，直接在数据库里执行了一条命令，把其中一张他们认为已经不重要的表给删除了，这个操作在数据库层面是成功的，系统也提示表已经不存在了。

但奇怪的事情发生了,在接下来的几个小时甚至几天里，之前依赖这张表的应用程序，某些功能似乎没有受到任何影响，一个本该显示被删除表里数据的页面，依然能正常加载出旧数据；或者一个需要向那张表写入新记录的功能，也没有报错，这就会让人非常困惑和紧张：数据到底删没删干净？难道见鬼了不成？

（引用来源：CSDN博客《数据库连接池与缓存导致的数据一致性问题》）

问题的根源很大概率不在于数据库本身,而在于应用程序和数据库之间的一个“中间人”——连接池和缓存。

先说连接池,你可以把它理解为一个“数据库连接的共享池子”，每次应用程序需要和数据库打交道（比如查询数据），如果每次都重新建立一条新的连接通道，会很慢也很耗资源，通常应用程序会启动时就创建好一批连接，放在这个“池子”里，当需要的时候，就从池子里取一个现成的连接来用，用完了再还回去，而不是关闭它。

关键点来了：当数据库里的表被删除时，应用程序这边正在池子里“休息”的那些数据库连接，它们并不知道远端数据库已经发生了这么大的变化，它们还保持着之前的状态，如果此时，应用程序的某个功能，恰好使用了这样一个“不知情”的旧连接，去执行一条针对已删除表的查询语句，会发生什么呢？这完全取决于数据库的配置和连接的状态，在某些情况下，数据库可能会因为连接会话还存有之前的缓存信息，而允许这个查询“侥幸”成功一段时间，返回的是它内存里可能还残留的旧数据，这就造成了“表没了，但数据还能查”的假象，更多的时候，这会最终导致一个延迟出现的错误，一旦数据库连接重置或者缓存失效，错误就会暴露出来。

再说说缓存,这是更常见的原因，为了提高速度，很多应用程序会引入缓存机制，比如Redis或Memcached，或者仅仅是应用服务器自身的内存缓存，它的工作原理是：第一次从数据库查询某个耗时的数据后，把这个结果在缓存里存一份，并设置一个有效期（比如10分钟），接下来10分钟内，如果再需要同样的数据，应用程序会聪明地先去缓存里找，如果找到了就直接使用，根本不会去打扰数据库。

假设在缓存生效的这10分钟里,有人把数据库里的源表给删了，但对于应用程序来说，在这10分钟内，所有依赖这份数据的请求，都会从速度飞快的缓存里拿到“看起来一切正常”的旧数据，用户完全感知不到底层数据库已经天翻地覆，这就完美解释了为什么表删除后，功能还能“正常”运行一段时间，直到缓存时间到期，应用程序再次尝试去数据库查询时，才会猛地发现“表找不到了”，然后抛出错误，这种问题的排查就很有迷惑性，因为从删除操作到错误发生，中间有一个时间差。

（引用来源：开源中国社区关于数据库事务隔离级别的讨论帖子）

还有一种相对少见但更复杂的情况,与数据库的“事务”机制有关，如果一个非常复杂的数据操作开启了事务但长时间没有结束（比如一个运行了几个小时的数据分析任务），在这个事务开始的那个时间点，它看到的数据库就像拍了一张快照，即使之后在其他连接里删除了表，只要这个长事务还没提交或回滚，它仍然可以在自己的“快照视图”里访问到那张表和里面的数据，因为它读取的是旧版本的数据，这对于保证数据一致性是好事，但也会造成“数据删除了却还能被某个会话访问”的现象。

当遇到“表删了还能用”这种诡异情况时，不要先怀疑数据库出了问题，正确的排查思路应该是：

1. 检查应用层的缓存：首先确认应用程序是否使用了缓存，清空所有相关缓存，再看问题是否复现。
2. 检查连接池：重启应用程序服务器，这会强制释放所有旧的数据库连接，并建立全新的连接池，重启后，问题通常就会立刻暴露。
3. 检查长时间运行的事务：在数据库端查询是否有挂起时间过长的活动事务。

这背后通常不是数据库的灵异事件,而是现代软件架构中，为了平衡性能、资源与数据一致性所引入的各类机制（连接池、缓存、事务隔离）共同作用下的一个典型现象，理解了这个原理，下次再遇到类似问题，就不会感到那么惊讶了。