我有 98w 行数据。当我想用 pub_time 对数据进行排序时，我发现了一件有趣的事情。
这是SQL：
select *
from t_p_blog_article_info t
order by t.pub_time desc
花了19s。
select *
from t_p_blog_article_info t
where t.pub_time > to_date( '1900-01-01 01:00:00', 'yyyy-mm-dd hh24:mi:ss ')
order by t.pub_time desc
它花费了0.2s。
我想知道，为什么？
您的表上可能有一个关于 pub_time 的索引。
因此，第二个查询可以利用该索引只返回指定日期之后的那些非空日期的记录，而第一个查询必须查询整个表。
有多种可能性。您可能会在 pub_time 中过滤掉大量具有无效/空日期的行，但我怀疑您不会注意到/提及其中的大量行。
让我印象深刻的三件事是：
1 - 您有一个涉及 pub_time 的索引或复合索引，并且 where 子句中的限制触发使用不同的访问路径
2 - 当您运行第一个查询时，您没有可用于优化器的统计信息。运行第二个查询时，由于运行第一个查询时发生的一些信息缓存，选择了更好的访问路径。这可以通过多次运行第一个查询并查看是否有显着的性能改进来验证。
3 - 与第一点类似，优化器可能只是根据 where 子句的含义选择更好的访问路径。也许给出不必处理空/无效值的提示就足够了 - 您的系统可能会避免一次或多次全表扫描以清除无效/空 pub_times。
查明此类事情的原因正在迅速成为一项经验冒险——如果不知道您的平台和版本，我很难说更多。从标签中我认为您正在使用 oracle，在这种情况下，您应该能够使用某种形式的“解释查询”或“解释计划”工具来更好地了解正在发生的事情。有关 oracle 优化器的更多信息，请参见http://docs.oracle.com/cd/B10500_01/server.920/a96533/optimops.htm（这是针对 Oracle 9i v9.2，但它对版本有很好的解释-独立的概念）