postgresql 优化 order by 对索引使用的影响

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: --原始sql SELECT * FROM tops_order.eticket WHERE ( issue_complete_date >= '2015-10-01 00:00:00+08' AND issue_compl


--原始sql
SELECT
    *
FROM
    tops_order.eticket
WHERE
    (
        issue_complete_date >= '2015-10-01 00:00:00+08'
        AND issue_complete_date < '2016-03-28 00:00:00+08'
        AND is_domestic = 't'
        AND customer_id IN ('53a3bfa545cebf2700d727e3')
    )
ORDER BY create_date DESC 
OFFSET 0
LIMIT 10;
--执行计划,使用的是idx_create_date索引
Limit  (cost=0.56..13959.07 rows=10 width=2633)
  ->  Index Scan Backward using idx_create_date on eticket  (cost=0.56..9207036.72 rows=6596 width=2633)
        Filter: (is_domestic AND (issue_complete_date >= '2015-10-01 00:00:00+08'::timestamp with time zone) AND (issue_complete_date < '2016-03-28 00:00:00+08'::timestamp with time zone) AND ((customer_id)::text = '53a3bfa545cebf2700d727e3'::text))

--表索引信息
Indexes:
    "pk_eticket" UNIQUE CONSTRAINT, btree (id)
    "idx_create_date" btree (create_date)
    "idx_customer_id" btree (customer_id)


                    
--修改其排序方式,使用idx_customer_id索引
SELECT
    *
FROM
    tops_order.eticket
WHERE
    (
        issue_complete_date >= '2015-10-01 00:00:00+08'
        AND issue_complete_date < '2016-03-28 00:00:00+08'
        AND is_domestic = 't'
        AND customer_id IN ('53a3bfa545cebf2700d727e3')
    )
ORDER BY to_char(create_date,'yyyy-mm-dd hh24:mi:ss:ms') DESC 
OFFSET 0
LIMIT 10;

Limit  (cost=96657.89..96657.92 rows=10 width=2633)
  ->  Sort  (cost=96657.89..96674.38 rows=6596 width=2633)
        Sort Key: (to_char(create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text))
        ->  Bitmap Heap Scan on eticket  (cost=1819.88..96515.36 rows=6596 width=2633)
              Recheck Cond: ((customer_id)::text = '53a3bfa545cebf2700d727e3'::text)
              Filter: (is_domestic AND (issue_complete_date >= '2015-10-01 00:00:00+08'::timestamp with time zone) AND (issue_complete_date < '2016-03-28 00:00:00+08'::timestamp with time zone))
              ->  Bitmap Index Scan on idx_customer_id  (cost=0.00..1818.23 rows=25823 width=0)
                    Index Cond: ((customer_id)::text = '53a3bfa545cebf2700d727e3'::text)

在上面的sql中由于ORDER BY create_date DESC的原因,pg使用了idx_create_date索引,但其并不是最有效的,请问pg为什么会使用那个索引,而不使用 idx_customer_id这个索引(其更高效啊),除了我上面的方法,还有什么办法可以避免吗?




devflight=# set work_mem='1GB';
SET
devflight=# show work_mem;
 work_mem 
----------
 1GB
explain (analyze,verbose,costs,timing,buffers)
SELECT
    *
FROM
    tops_order.eticket
WHERE
    (
        issue_complete_date >= '2015-10-01 00:00:00+08'
        AND issue_complete_date < '2016-03-28 00:00:00+08'
        AND is_domestic = 't'
        AND customer_id IN ('53a3bfa545cebf2700d727e3')
    )
ORDER BY create_date DESC 
OFFSET 0
LIMIT 10;
--第一次执行,不考虑缓存
Limit  (cost=0.56..14494.42 rows=10 width=2628) (actual time=77326.839..423643.180 rows=10 loops=1)
   Output: id, order_type...其它字段省略
   Buffers: shared hit=778155 read=410205
   ->  Index Scan Backward using idx_create_date on tops_order.eticket  (cost=0.56..9209400.56 rows=6354 width=2628) (actual time=77326.834..423643.149 rows=10 loops=1)
         Output: id, order_type...其它字段省略
         Filter: (eticket.is_domestic AND (eticket.issue_complete_date >= '2015-10-01 00:00:00+08'::timestamp with time zone) AND (eticket.issue_complete_date < '2016-03-28 00:00:00+08'::timestamp with time zone) AND ((eticket.customer_id)::text = '53a3bfa545cebf2700d72
7e3'::text))
         Rows Removed by Filter: 1279957
         Buffers: shared hit=778155 read=410205
 Total runtime: 423643.357 ms
 --第二次执行,考虑缓存
 Limit  (cost=0.56..14494.44 rows=10 width=2628) (actual time=767.403..4279.628 rows=10 loops=1)
   Output: id, order_type...其它字段省略
   Buffers: shared hit=1189156
   ->  Index Scan Backward using idx_create_date on tops_order.eticket  (cost=0.56..9209412.56 rows=6354 width=2628) (actual time=767.400..4279.606 rows=10 loops=1)
         Output: id, order_type...其它字段省略
         Filter: (eticket.is_domestic AND (eticket.issue_complete_date >= '2015-10-01 00:00:00+08'::timestamp with time zone) AND (eticket.issue_complete_date < '2016-03-28 00:00:00+08'::timestamp with time zone) AND ((eticket.customer_id)::text = '53a3bfa545cebf2700d72
7e3'::text))
         Rows Removed by Filter: 1280127
         Buffers: shared hit=1189156
 Total runtime: 4279.777 ms

 
 

explain (analyze,verbose,costs,timing,buffers)
SELECT
    *
FROM
    tops_order.eticket
WHERE
    (
        issue_complete_date >= '2015-10-01 00:00:00+08'
        AND issue_complete_date < '2016-03-28 00:00:00+08'
        AND is_domestic = 't'
        AND customer_id IN ('53a3bfa545cebf2700d727e3')
    )
ORDER BY to_char(create_date,'yyyy-mm-dd hh24:mi:ss:ms') DESC 
OFFSET 0
LIMIT 10;
--第一次执行,不考虑缓存
 Limit  (cost=93008.42..93008.44 rows=10 width=2628) (actual time=24797.439..24797.444 rows=10 loops=1)
   Output: id, order_type, (to_char(create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text))...其它字段省略
   Buffers: shared hit=2419 read=16685
   ->  Sort  (cost=93008.42..93024.30 rows=6354 width=2628) (actual time=24797.436..24797.439 rows=10 loops=1)
         Output: id, order_type, (to_char(create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text)) ...其它字段省略
         Sort Key: (to_char(eticket.create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text))
         Sort Method: top-N heapsort  Memory: 45kB
         Buffers: shared hit=2419 read=16685
         ->  Bitmap Heap Scan on tops_order.eticket  (cost=1744.15..92871.11 rows=6354 width=2628) (actual time=1473.866..24796.587 rows=32 loops=1)
               Output: id, order_type, to_char(create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text)...其它字段省略
               Recheck Cond: ((eticket.customer_id)::text = '53a3bfa545cebf2700d727e3'::text)
               Filter: (eticket.is_domestic AND (eticket.issue_complete_date >= '2015-10-01 00:00:00+08'::timestamp with time zone) AND (eticket.issue_complete_date < '2016-03-28 00:00:00+08'::timestamp with time zone))
               Rows Removed by Filter: 20282
               Buffers: shared hit=2414 read=16685
               ->  Bitmap Index Scan on idx_customer_id  (cost=0.00..1742.56 rows=24800 width=0) (actual time=1467.166..1467.166 rows=20314 loops=1)
                     Index Cond: ((eticket.customer_id)::text = '53a3bfa545cebf2700d727e3'::text)
                     Buffers: shared hit=1 read=387
 Total runtime: 24798.126 ms
 --第二次执行,考虑缓存
  Limit  (cost=93008.42..93008.44 rows=10 width=2628) (actual time=90.570..90.576 rows=10 loops=1)
   Output: id, order_type, (to_char(create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text)) ...其它字段省略
   Buffers: shared hit=19099
   ->  Sort  (cost=93008.42..93024.30 rows=6354 width=2628) (actual time=90.567..90.569 rows=10 loops=1)
         Output: id, order_type, (to_char(create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text)) ...其它字段省略
         Sort Key: (to_char(eticket.create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text))
         Sort Method: top-N heapsort  Memory: 45kB
         Buffers: shared hit=19099
         ->  Bitmap Heap Scan on tops_order.eticket  (cost=1744.15..92871.11 rows=6354 width=2628) (actual time=13.735..90.135 rows=32 loops=1)
               Output: id, order_type, to_char(create_date, 'yyyy-mm-dd hh24:mi:ss:ms'::text) ...其它字段省略
               Recheck Cond: ((eticket.customer_id)::text = '53a3bfa545cebf2700d727e3'::text)
               Filter: (eticket.is_domestic AND (eticket.issue_complete_date >= '2015-10-01 00:00:00+08'::timestamp with time zone) AND (eticket.issue_complete_date < '2016-03-28 00:00:00+08'::timestamp with time zone))
               Rows Removed by Filter: 20282
               Buffers: shared hit=19099
               ->  Bitmap Index Scan on idx_customer_id  (cost=0.00..1742.56 rows=24800 width=0) (actual time=8.259..8.259 rows=20314 loops=1)
                     Index Cond: ((eticket.customer_id)::text = '53a3bfa545cebf2700d727e3'::text)
                     Buffers: shared hit=388
 Total runtime: 90.875 ms


相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
2月前
|
关系型数据库 分布式数据库 数据库
PolarDB常见问题之加了索引但是查询没有使用如何解决
PolarDB是阿里云推出的下一代关系型数据库,具有高性能、高可用性和弹性伸缩能力,适用于大规模数据处理场景。本汇总囊括了PolarDB使用中用户可能遭遇的一系列常见问题及解答,旨在为数据库管理员和开发者提供全面的问题指导,确保数据库平稳运行和优化使用体验。
|
7月前
|
SQL 关系型数据库 测试技术
沉浸式学习PostgreSQL|PolarDB 20: 学习成为数据库大师级别的优化技能
在上一个实验《沉浸式学习PostgreSQL|PolarDB 19: 体验最流行的开源企业ERP软件 odoo》 中, 学习了如何部署odoo和polardb|pg. 由于ODOO是非常复杂的ERP软件, 对于关系数据库的挑战也非常大, 所以通过odoo业务可以更快速提升同学的数据库优化能力, 发现业务对数据库的使用问题(如索引、事务对锁的运用逻辑问题), 数据库的代码缺陷, 参数或环境配置问题, 系统瓶颈等.
852 1
|
8天前
|
存储 缓存 关系型数据库
关系型数据库数据库表设计的优化
您可以优化关系型数据库的表设计,提高数据库的性能、可维护性和可扩展性。但请注意,每个数据库和应用程序都有其独特的需求和挑战,因此在实际应用中需要根据具体情况进行调整和优化。
11 4
|
8天前
|
缓存 监控 关系型数据库
关系型数据库优化查询语句
记住每个数据库和查询都是独特的,所以最好的优化策略通常是通过测试和分析来确定的。在进行任何大的更改之前,始终备份你的数据并在测试环境中验证更改的效果。
16 5
|
10天前
|
存储 SQL 关系型数据库
关系型数据库存储优化
关系型数据库存储优化
20 1
|
21天前
|
SQL 关系型数据库 分布式数据库
|
1月前
|
存储 JSON 关系型数据库
PostgreSQL Json应用场景介绍和Shared Detoast优化
PostgreSQL Json应用场景介绍和Shared Detoast优化
|
3月前
|
SQL 算法 关系型数据库
PolarDB-X的XPlan索引选择
对于数据库来说,正确的选择索引是基本的要求,选错索引轻则导致查询缓慢,重则导致数据库整体不可用。PolarDB-X存在多种不同的索引,局部索引、全局索引、列存索引、归档表索引。本文主要介绍一种CN上的局部索引算法:XPlan索引选择。
125765 13
PolarDB-X的XPlan索引选择
|
4月前
|
弹性计算 关系型数据库 数据库
开源PostgreSQL在倚天ECS上的最佳优化实践
本文基于倚天ECS硬件平台,以自顶向下的方式从上层应用、到基础软件,再到底层芯片硬件,通过应用与芯片的硬件特性的亲和性分析,实现PostgreSQL与倚天芯片软硬协同的深度优化,充分使能倚天硬件性能,帮助开源PostgreSQL应用实现性能提升。
|
4月前
|
关系型数据库 定位技术 索引
在关系型数据库中,常见的索引种类包括哪些
在关系型数据库中,常见的索引种类包括哪些
486 0