Question

sql非常简单。 “orders_express_idx”btree（快递）。快递是指数。

运作良好。因为表达a存在。

select * from orders where express =  'a'  order by id desc limit 1;

Limit  (cost=0.43..1.29 rows=1 width=119)
->  Index Scan Backward using orders_pkey on orders  (cost=0.43..4085057.23 rows=4793692 width=119)
     Filter: ((express)::text = 'a'::text)

工作缓慢。数据不存在。我使用限制。

select * from orders where express =  'b'  order by id desc limit 1;

 Limit  (cost=0.43..648.86 rows=1 width=119)
 ->  Index Scan Backward using orders_pkey on orders  (cost=0.43..4085061.83 rows=6300 width=119)
     Filter: ((express)::text = 'a'::text)

运作良好。数据不存在。但我没有使用限制。

select * from orders where express =  'b'  order by id desc;

Sort  (cost=24230.91..24246.66 rows=6300 width=119)
Sort Key: id
->  Index Scan using orders_express_idx on orders  (cost=0.56..23833.35 rows=6300 width=119)
     Index Cond: ((express)::text = 'a'::text)

Answer 1

https://www.postgresql.org/docs/9.6/static/using-explain.html

带着

去找seciotn

以下是显示LIMIT效果的示例：

并进一步：

这是与上面相同的查询，但我们添加了LIMIT，以便不是全部需要检索行，并且计划者改变了主意该怎么办。请注意索引扫描的总成本和行数节点显示为运行完成。但是，限制在仅检索这些行中的五分之一后，预计节点将停止，所以它的总成本只有五分之一，这就是实际成本估计的查询成本。该计划优于添加a 将节点限制为上一个计划，因为限制无法避免支付位图扫描的启动成本，因此总成本将是超过25个单位的东西。

所以基本上 - 是的。添加LIMIT会更改计划，因此对于较小的数据集（预期）可以变得更有效，但影响可能是负面的（取决于统计和设置（扫描成本，effective_cache_size等）...... < / p>

如果你给出上述查询的执行计划，我们会解释发生了什么。但基本上这是记录在案的行为 - LIMIT改变计划，从而改变执行时间 - 是的。

如果数据为none，则使用限制非常慢

1 个答案: