sql - 为什么根据此条件更改 where 子句会如此大幅度地减少执行时间？

Question

今天我遇到了 SQL 语句的问题，我可以通过添加其他条件来修复该问题，但我真的想知道为什么我的更改解决了该问题。

问题查询:

SELECT *
FROM
  (SELECT ah.*,
    com.location,
    ha.customer_number,
    d.name applicance_NAME,
    house.name house_NAME,
    dr.name RULE_NAME
FROM actionhistory ah
INNER JOIN community com
ON (t.city_id = com.city_id)
INNER JOIN house_address ha
ON (t.applicance_id   = ha.applicance_id
AND ha.status_cd = 'ACTIVE')
INNER JOIN applicance d
ON (t.applicance_id = d.applicance_id)
INNER JOIN house house
ON (house.house_id = t.house_id)
LEFT JOIN the_rule tr
ON (tr.the_rule_id = t.the_rule_id)
WHERE actionhistory_id    >= 'ACT100010000' 
ORDER BY actionhistory_id
)
WHERE rownum <= 30000;

“修复”

SELECT *
FROM
  (SELECT ah.*,
    com.location,
    ha.customer_number,
    d.name applicance_NAME,
    house.name house_NAME,
    dr.name RULE_NAME
FROM actionhistory ah
INNER JOIN community com
ON (t.city_id = com.city_id)
INNER JOIN house_address ha
ON (t.applicance_id   = ha.applicance_id
AND ha.status_cd = 'ACTIVE')
INNER JOIN applicance d
ON (t.applicance_id = d.applicance_id)
INNER JOIN house house
ON (house.house_id = t.house_id)
LEFT JOIN the_rule tr
ON (tr.the_rule_id = t.the_rule_id)
WHERE actionhistory_id    >= 'ACT100010000' and  actionhistory_id  <= 'ACT100030000'
ORDER BY actionhistory_id
)

所有 _id 列都是索引序列。 第一个查询的解释计划的成本为 372，第二个查询的解释计划成本为 14。它在 Oracle 11g 数据库上运行。

此外，如果where子句中的actionhistory_id小于ACT100000000，则原始查询立即返回。

Answer 1

这是因为 actionhistory_id 列上的索引造成的。

在第一个查询期间，Oracle 必须返回包含“ACT100010000”之后的记录索引的所有索引 block ，然后必须将索引与表匹配以获取所有记录，然后从表中提取 29999 条记录。结果集。

在第二个查询期间，Oracle 只需返回包含“ACT100010000”和“ACT100030000”之间记录的索引 block 。然后它从表中抓取索引 block 中表示的那些记录。与使用第一个查询相比，找到索引后抓取记录的步骤要少得多。

注意你的最后一行关于 id 是否小于 ACT100000000 - 在我看来，这些记录可能都在同一个内存块中(或在一组连续的 block 中)。

编辑:另请考虑贾斯汀所说的 - 我正在谈论实际性能，但他指出 id 作为 varchar 大大增加了潜在值(而不是数字)，并且估计的计划可能会反射(reflect)的时间比实际时间更长，因为优化器在执行之前不知道完整的范围。为了进一步优化，考虑到他的观点，您可以在 id 列上放置一个基于函数的索引，或者可以将其设为组合键，其中 varchar 部分位于一列中，数字部分位于另一列中。