有一个项目，大概跑了两年数据量比较大，偶尔会出现系统效率响应变慢的情况。
由于现场不能停工，第一反应是不是历史数据太大了，使用存储过程，分批把历史数据删除剩下几百万。
发现两个模块都慢，最终分析代码发现两个模块都调用了一个方法。方法执行的 sql 如下：

怀疑可能是 UNION 走了全表导致的，然后加了如下索引
CREATE INDEX IX_STATUS_WCSSOURCE ON TTT(STATUS, WCSSOURCE);

系统就正常了。
但是没搞懂的是，为什么清除历史数据了还是慢，而且期间运行了几年也没有卡顿。
备注：使用的是删除，主键此时还是比较大的数值

最简单的处理方法 ，explain plan ，看下 SQL 的执行计划。

这个组合索引并不优，不如分开建索引。

换成临时表都比 union 快

表要做碎片整理吧

这个表名起的

感谢，主要不能理解的是为什么数据量不大，查询也会有影响

能详细说一下吗？

表名是我替换了的，防止被同事看到

主要不能理解的是为什么数据量不大，查询也会有影响

sql 查询已经进行优化了，但是没理解的是为什么数据量不大也会受影响，之前都是正常运行的

你这个也不放个 explain plan ,我们表结构索引都不知道,怎么给你看么

union 一般来说包含两个操作 select 和 distinct 。 你可以试试 union all 。

并且你要是执行的是 del,表空间没有释放,你尝试新建个表,把数据倒进去,再执行这个 sql 试试

＃6 他的意思可能是，数据虽然删除了，但是磁盘文件的对应空间并没有回收然后重写让剩下的数据在一起，那么此时查询数据库从磁盘读取数据时，每次读取依然只能读取的非常少的条数，读取磁盘的次数和数据量并没有显著降低，那么查询性能自然也不会有很大提升，不过如果你是时间有序数据，只是删除更早以前的数据，那这个问题影响应该不会很大吧

这个我当时也考虑了的，把相关数据删除之后，使用数据库文件收缩把，空间回收了的

好的，感谢由于事态比较紧急，处于夜间突发，所以当时没有考虑太多，只是尝试性加了一下索引，下次尝试这个思路试一下

数据删除后，存储空间会碎片化，可以 coalesce 合并一下；同理 index 的节点也有类似的问题，可以 rebuid 一下，你会发现空间释放出来很多。

真没必要太多猜测和尝试，正如一楼所说的，数据库性能

真没必要太多猜测和尝试，正如一楼所说的，explain plan ，看下 SQL 的执行计划，基本就能定位数据库性能问题。

对的同意楼上，不要猜测，看下执行计划。数据库做的这方面还是很好的

t.，x.这种写法要改正
sql 优化的问题，一定要贴执行计划
优化的两个重要原则 1 建立高效索引 2 避免回表