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

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: --原始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数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
SQL 关系型数据库 测试技术
沉浸式学习PostgreSQL|PolarDB 20: 学习成为数据库大师级别的优化技能
在上一个实验《沉浸式学习PostgreSQL|PolarDB 19: 体验最流行的开源企业ERP软件 odoo》 中, 学习了如何部署odoo和polardb|pg. 由于ODOO是非常复杂的ERP软件, 对于关系数据库的挑战也非常大, 所以通过odoo业务可以更快速提升同学的数据库优化能力, 发现业务对数据库的使用问题(如索引、事务对锁的运用逻辑问题), 数据库的代码缺陷, 参数或环境配置问题, 系统瓶颈等.
955 1
|
4月前
|
监控 关系型数据库 数据库
PostgreSQL的索引优化策略?
【8月更文挑战第26天】PostgreSQL的索引优化策略?
116 1
|
3月前
|
缓存 关系型数据库 数据库
如何优化 PostgreSQL 数据库性能?
如何优化 PostgreSQL 数据库性能?
149 2
|
4月前
|
监控 关系型数据库 数据库
如何优化PostgreSQL的性能?
【8月更文挑战第4天】如何优化PostgreSQL的性能?
274 7
|
4月前
|
SQL 关系型数据库 MySQL
SQL Server、MySQL、PostgreSQL:主流数据库SQL语法异同比较——深入探讨数据类型、分页查询、表创建与数据插入、函数和索引等关键语法差异,为跨数据库开发提供实用指导
【8月更文挑战第31天】SQL Server、MySQL和PostgreSQL是当今最流行的关系型数据库管理系统,均使用SQL作为查询语言,但在语法和功能实现上存在差异。本文将比较它们在数据类型、分页查询、创建和插入数据以及函数和索引等方面的异同,帮助开发者更好地理解和使用这些数据库。尽管它们共用SQL语言,但每个系统都有独特的语法规则,了解这些差异有助于提升开发效率和项目成功率。
483 0
|
4月前
|
关系型数据库 数据库 PostgreSQL
PostgreSQL索引维护看完这篇就够了
PostgreSQL索引维护看完这篇就够了
328 0
|
7月前
|
存储 JSON 关系型数据库
PostgreSQL Json应用场景介绍和Shared Detoast优化
PostgreSQL Json应用场景介绍和Shared Detoast优化
|
7月前
|
弹性计算 关系型数据库 数据库
开源PostgreSQL在倚天ECS上的最佳优化实践
本文基于倚天ECS硬件平台,以自顶向下的方式从上层应用、到基础软件,再到底层芯片硬件,通过应用与芯片的硬件特性的亲和性分析,实现PostgreSQL与倚天芯片软硬协同的深度优化,充分使能倚天硬件性能,帮助开源PostgreSQL应用实现性能提升。
|
关系型数据库 Go 数据库
《提高查询速度:PostgreSQL索引实用指南》
《提高查询速度:PostgreSQL索引实用指南》
598 0
|
关系型数据库 分布式数据库 数据库
PolarDB for PostgreSQL 14:全局索引
PolarDB for PostgreSQL 14 相较于 PostgreSQL 14,提供了更多企业级数据库的特性。本实验将体验其中的全局索引功能。