最近发生一件事情,之前我没有细想,这个基于POSTGRESQL的数据库优化问题,就是关于建立了索引,在高并发的问题。
工作比较忙,事情比较多其实很多事情就无暇顾及,这点还是得说,给更多的时间和人力在优化数据库上,是可以降低成本的,但这样的方式因为不明显,或者并不被注意到,而无人理会。
这就是数据库添加了索引和数据库SQL优化是两个概念,Bitmap Index Scan 和 index scan在高并发的情况下,那个更好的问题。
我们做一个练习先来把这个问题复现一下。
test=#
test=# DROP TABLE IF EXISTS users CASCADE;
NOTICE: table "users" does not exist, skipping
bigserial PRIMARY KEY,
user_id bigint NOT NULL,
status text NOT NULL,
created_at timestamptz NOT NULL,
amount numeric
);DROP TABLE
test=#
test=# CREATE TABLE users (
test(# user_id bigint PRIMARY KEY,
test(# user_name text
test(# );
CREATE TABLE
test=#
test=# INSERT INTO users
test-# SELECT id, 'user_' || id
test-# FROM generate_series(1, 1000) id;
INSERT 0 1000
test=#
test=#
test=# DROP TABLE IF EXISTS orders;
NOTICE: table "orders" does not exist, skipping
DROP TABLE
test=#
test=# CREATE TABLE orders (
test(# order_id bigserial PRIMARY KEY,
test(# user_id bigint NOT NULL,
test(# status text NOT NULL,
test(# created_at timestamptz NOT NULL,
test(# amount numeric
test(# );
CREATE TABLE
test=#
test=#
test=#
test=# INSERT INTO orders (user_id, status, created_at, amount)
test-# SELECT
test-# (random() * 999 + 1)::int,
test-# CASE WHEN random() < 0.7 THEN 'PAID' ELSE 'NEW' END,
test-# now() - (random() * interval '30 days'),
test-# random() * 1000
test-# FROM generate_series(1, 1000000);
INSERT 0 1000000
test=#
test=#
test=# \timing
Timing is on.
test=# EXPLAIN (ANALYZE, BUFFERS)
test-# SELECT
test-# u.user_name,
test-# count(*)
test-# FROM
test-# orders o
test-# JOIN users u ON o.user_id = u.user_id
test-# WHERE
test-# o.user_id = 42
test-# AND o.status = 'PAID'
test-# GROUP BY u.user_name;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
------------------
Finalize GroupAggregate (cost=16619.87..16622.31 rows=1 width=16) (actual time=27.053..29.310 rows=1.00 loops=1)
Group Key: u.user_name
Buffers: shared hit=9382
-> Gather Merge (cost=16619.87..16622.29 rows=2 width=16) (actual time=27.006..29.271 rows=3.00 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=9382
-> Partial GroupAggregate (cost=15619.84..15622.03 rows=1 width=16) (actual time=22.965..23.018 rows=1.00 loops=3)
Group Key: u.user_name
Buffers: shared hit=9382
-> Sort (cost=15619.84..15620.57 rows=291 width=8) (actual time=20.692..21.811 rows=235.67 loops=3)
Sort Key: u.user_name
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=9382
Worker 0: Sort Method: quicksort Memory: 25kB
Worker 1: Sort Method: quicksort Memory: 25kB
-> Nested Loop (cost=0.28..15607.93 rows=291 width=8) (actual time=0.116..19.546 rows=235.67 loops=3)
Buffers: shared hit=9366
-> Parallel Seq Scan on orders o (cost=0.00..15596.00 rows=291 width=8) (actual time=0.041..12.387 rows=235.6
7 loops=3)
Filter: ((user_id = 42) AND (status = 'PAID'::text))
Rows Removed by Filter: 333098
Buffers: shared hit=9346
-> Materialize (cost=0.28..8.30 rows=1 width=16) (actual time=0.005..0.010 rows=1.00 loops=707)
Storage: Memory Maximum Storage: 17kB
Buffers: shared hit=20
-> Index Scan using users_pkey on users u (cost=0.28..8.29 rows=1 width=16) (actual time=0.027..0.037 r
ows=1.00 loops=3)
Index Cond: (user_id = 42)
Index Searches: 3
Buffers: shared hit=20
Planning:
Buffers: shared hit=60
Planning Time: 0.257 ms
Execution Time: 29.372 ms
(33 rows)
Time: 30.414 ms
test=#
test=#
test=#
test=#
test=# CREATE INDEX idx_orders_user
test-# ON orders(user_id);
CREATE INDEX
Time: 251.459 ms
test=#
test=# CREATE INDEX idx_orders_status
test-# ON orders(status);
CREATE INDEX
Time: 302.121 ms
test=#
test=# EXPLAIN (ANALYZE, BUFFERS)
SELECT
u.user_name,
count(*)
FROM
orders o
JOIN users u ON o.user_id = u.user_id
WHERE
o.user_id = 42
AND o.status = 'PAID'
GROUP BY u.user_name;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
--
HashAggregate (cost=2929.47..2929.48 rows=1 width=16) (actual time=20.371..20.414 rows=1.00 loops=1)
Group Key: u.user_name
Batches: 1 Memory Usage: 32kB
Buffers: shared hit=930 read=3
-> Nested Loop (cost=12.35..2925.97 rows=699 width=8) (actual time=0.465..15.479 rows=707.00 loops=1)
Buffers: shared hit=930 read=3
-> Index Scan using users_pkey on users u (cost=0.28..8.29 rows=1 width=16) (actual time=0.017..0.029 rows=1.00 loops=1)
Index Cond: (user_id = 42)
Index Searches: 1
Buffers: shared hit=3
-> Bitmap Heap Scan on orders o (cost=12.08..2910.69 rows=699 width=8) (actual time=0.423..6.631 rows=707.00 loops=1)
Recheck Cond: (user_id = 42)
Filter: (status = 'PAID'::text)
Rows Removed by Filter: 279
Heap Blocks: exact=927
Buffers: shared hit=927 read=3
-> Bitmap Index Scan on idx_orders_user (cost=0.00..11.90 rows=997 width=0) (actual time=0.183..0.188 rows=986.00 loops=1
)
Index Cond: (user_id = 42)
Index Searches: 1
Buffers: shared read=3
Planning:
Buffers: shared hit=29 read=2
Planning Time: 0.383 ms
Execution Time: 20.485 ms
(24 rows)
Time: 21.646 ms
test=#
test=#
test=#
test=# DROP INDEX idx_orders_user;
DROP INDEX
Time: 1.940 ms
test=# DROP INDEX idx_orders_status;
DROP INDEX
Time: 1.755 ms
test=#
test=# CREATE INDEX idx_orders_user_status
test-# ON orders (user_id, status);
CREATE INDEX
Time: 331.547 ms
test=#
test=#
test=# EXPLAIN (ANALYZE, BUFFERS)
test-# SELECT
test-# u.user_name,
test-# count(*)
test-# FROM
test-# orders o
test-# JOIN users u ON o.user_id = u.user_id
test-# WHERE
test-# o.user_id = 42
test-# AND o.status = 'PAID'
test-# GROUP BY u.user_name;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
----------------
HashAggregate (cost=37.18..37.19 rows=1 width=16) (actual time=13.835..13.870 rows=1.00 loops=1)
Group Key: u.user_name
Batches: 1 Memory Usage: 32kB
Buffers: shared hit=4 read=3
-> Nested Loop (cost=0.70..33.69 rows=699 width=8) (actual time=0.065..10.329 rows=707.00 loops=1)
Buffers: shared hit=4 read=3
-> Index Scan using users_pkey on users u (cost=0.28..8.29 rows=1 width=16) (actual time=0.012..0.023 rows=1.00 loops=1)
Index Cond: (user_id = 42)
Index Searches: 1
Buffers: shared hit=3
-> Index Only Scan using idx_orders_user_status on orders o (cost=0.42..18.41 rows=699 width=8) (actual time=0.038..3.787 rows=
707.00 loops=1)
Index Cond: ((user_id = 42) AND (status = 'PAID'::text))
Heap Fetches: 0
Index Searches: 1
Buffers: shared hit=1 read=3
Planning:
Buffers: shared hit=22 read=1
Planning Time: 0.212 ms
Execution Time: 13.919 ms
(19 rows)
Time: 14.738 ms
test=#
test=#
这里我们分析一下
Bitmap index
idx_orders_user
↓
Bitmap Index Scan
↓ (构建 bitmap)
Bitmap Heap Scan
↓ (回表 + Filter status)
Nested Loop
↓
HashAggregate
Buffers: shared hit=930 read=3
Heap Blocks: exact=927
Memory Usage: 32kB
index scan
idx_orders_user_status
↓
Index Only Scan
↓
Nested Loop
↓
HashAggregate
Buffers: shared hit=4 read=3 Heap Fetches: 0
其实从上面看一个关键的问题,使用了bitmap会浪费更多的内存,每个进程都要产生930 Buffer hit ,而使用index only scan 只用了 4 buffer hit
差距很大,这个问题在单一的查询中并不是一个关键尤其对现在大内存的数据库服务器,而如果并发超高的情况下就不痛,如果我们有100个并发的情况下,那么区别就比较大了
93000 和 400 的区别,这个内存的区别就变得越来越大了,
93,000 pages × 8 KB ≈ 744,000 KB ≈ 726 MB
400 pages × 8 KB ≈ 3,200 KB ≈ 3.1 MB
同时会产生更多的CPU的消耗,这里就不赘述了,所以在PostgreSQL优化的过程中,要注意查询中是否因为单独建立索引而导致走了bitmap 而因为没有建立联合索引去走index scan.
其实这里还有另一个问题,就是PostgreSQL或者其他的数据库产品都不会考虑你的一个SQL运行的并发性,他们仅仅是针对一次的操作来判断COST,因为bitmap调用IO更少,在数据库中更少的IO是SQL运行中希望看到的,同时我们也可以看到,下面的PG的COST的计算模式。
Total Cost =
Seq/Index Page Cost
+ CPU tuple cost
+ CPU operator cost
但在并发高的情况下,的确更少的CPU的计算,更少的内存更有利,但是,如果是一个有充足的CPU和内存的数据库服务器呢?
其实也是一样,当buffer hit 越多的情况下,会发生内存方面的轻量级的锁,而锁本身也会消耗内存,和CPU。
所以对一些SQL的优化还是要细致一些,我觉得这才是AI优化SQL对数据库重要的。
置顶
PostgreSQL 平时没事,怎么就一个SQL下去就不行了?,原来是老毛病了!
在测试浪潮 KaiwuDB-lite 后,留下几个大字 "你别挨骂了"
PostgreSQL 现世报,客户吐槽不如SQL SERVER 与 国产数据库搞兼容性
阿里云 PolarDB for MySQL IMCI 绞杀SQL优化专家,My GOD!!
阿里云DTS 我冤枉,其实我很委屈--客户大爷们,咱们换个位置也理解一下吧!
SQLite 开发中的数据库开发规范 --如何提升业务系统性能避免基础BUG
微软布局PostgreSQL 就在昨天发布新品--云厂商爱PG到底是个什么梗!!
2022年 Sqlite白皮书对比DuckDB差异 -- 什么叫做关公战秦琼
阿里云产品选择困难症,RDS 还是 PolarDB 希望能讲明白
SQLite3 为什么会打败PostgreSQL 的原因分析,PostgreSQL 在移动端也是不错的选择
SQLite3 打败了 PostgreSQL 终究还是没能挽回--世界最大装机量是真的
回复群友问题,PostgreSQL Extensions 哪些是常用的
PostgreSQL 2025杭州大会--掐指一算,原来待在这里 7年了!
回复群友问题,PostgreSQL Extensions 哪些是常用的
说搞国产数据库生态,骗鬼呢? 群里服务商吐槽后的 “大实话”
“MySQL” 2025年我用上物化视图功能,谁家的MySQL有这个功能?
民营企业领导问 外部客户数据库选型为什么是 OceanBase
PostgreSQL 真实压测,分析PG18 17 16 15 14 之间在处理SQL和系统性能稳定性的差异
PostgreSQL 迁移到 PolarDB 2万5千里长征,太难了,太难了 (今天DISS阿里云某部门)
Oracle 26i 的一个功能演进后,云厂商利用会不会造出千年老妖样的“数据库”
“一顿海鲜引发”(3)一分钟定位数据库问题,试用得京东卡和礼物!
“一顿海鲜引发”(1):DBA、架构师与数据库运维工具的爱恨情仇
DBA 从“修电脑的” 到 上演一套 “数据治理” 大戏 --- 维护DBA生存空间,体现个体价值
老板说 MongoDB 测试环境这么贵,弄单机? 开发说要复制集测试? 你们这群XXX!!
国庆节2号 PostgreSQL 停机罢工 协助 解决问题得 66.66元的红包
外媒评论区疯狂了,开发人员各种观点---北美AI替换程序员引发境外程序员业界震动
MySQL 8 的老大难问题,从5.7延续至今,这个问题有这么难?
一篇为MySQL用户,分析版本核心差异的文章--8.028-8.4的差异
云上DBA是诸葛亮,云下的DBA是 关云长,此话怎讲? 4点变化直击要害
MongoDB 开始接客户应用系统 AI 改造的活了--OMG 这世界太疯狂
一篇将PostgreSQL 日志问题说的非常详细附带分析解决方案的文章 (翻译)
企业DBA 应该没听说过 Supabase,因为他不单纯 !!
Oracle 推出原生支持 Oracle 数据库的 MCP 服务器,助力企业构建智能代理应用
PolarDB MySQL SQL 优化指南 (SQL优化系列 5)
开发欺负我 Redis 的大 keys的问题,我一个DBA怎么解决?
IF-Club 你提意见拿礼物 AustinDatabases 破 10000
开发欺负我 Redis 的大 keys的问题,我一个DBA怎么解决?
OceanBase 相关文章
OceanBase 光速快递 OB Cloud “MySQL” 给我,Thanks a lot
和架构师沟通那种“一坨”的系统,推荐只能是OceanBase,Why ?
OceanBase Hybrid search 能力测试,平换MySQL的好选择
写了3750万字的我,在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究
OceanBase 6大学习法--OBCA视频学习总结第六章
OceanBase 6大学习法--OBCA视频学习总结第五章--索引与表设计
OceanBase 6大学习法--OBCA视频学习总结第五章--开发与库表设计
OceanBase 6大学习法--OBCA视频学习总结第四章 --数据库安装
OceanBase 6大学习法--OBCA视频学习总结第三章--数据库引擎
OceanBase 架构学习--OB上手视频学习总结第二章 (OBCA)
OceanBase 6大学习法--OB上手视频学习总结第一章
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)
跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)
跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)
聚焦SaaS类企业数据库选型(技术、成本、合规、地缘政治)
OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB
“合体吧兄弟们!”——从浪浪山小妖怪看OceanBase国产芯片优化《OceanBase “重如尘埃”之歌》
MongoDB 相关文章
MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾
MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项
MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"
MongoDB “升级项目” 大型连续剧(1)-- 可“生”可不升
MongoDB 大俗大雅,上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通
MongoDB 年底活动,免费考试名额 7个公众号获得
MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB 双机热备那篇文章是 “毒”
MongoDB 会丢数据吗?在次补刀MongoDB 双机热备
MONGODB ---- Austindatabases 历年文章合集
MongoDB 麻烦专业点,不懂可以问,别这么用行吗 ! --TTL
PolarDB 已经开放的课程
PolarDB 非官方课程第八节--数据库弹性弹出一片未来--结课
PolarDB 非官方课程第七节--数据备份还原瞬间完成是怎么做到的--答题领奖品
PolarDB 非官方课程第六节--数据库归档还能这么玩--答题领奖品
PolarDB 非官方课程第五节--PolarDB代理很重要吗?--答题领奖品
PolarDB 非官方课程第四节--PG实时物化视图与行列数据整合处理--答题领奖品
PolarDB 非官方课程第三节--MySQL+IMCI=性能怪兽--答题领奖品
PolarDB 非官方课程第二节--云原生架构与特有功能---答题领奖品
PolarDB 非官方课程第一节-- 用户角度怎么看PolarDB --答题领奖品
免费PolarDB云原生课程,听课“争”礼品,重塑云上知识,提高专业能力
PolarDB 相关文章
非“厂商广告”的PolarDB课程:用户共创的新式学习范本--7位同学获奖PolarDB学习之星
“当复杂的SQL不再需要特别的优化”,邪修研究PolarDB for PG 列式索引加速复杂SQL运行
数据压缩60%让“PostgreSQL” SQL运行更快,这不科学呀?
这个 PostgreSQL 让我有资本找老板要 鸡腿 鸭腿 !!
用MySQL 分区表脑子有水!从实例,业务,开发角度分析 PolarDB 使用不会像MySQL那么Low
MySQL 和 PostgreSQL 可以一起快速发展,提供更多的功能?
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火
PostgreSQL 相关文章
PostgreSQL 新版本就一定好--由培训现象让我做的实验
说我PG Freezing Boom 讲的一般的那个同学,专帖给你,看看这次可满意
邦邦硬的PostgreSQL技术干货来了,怎么动态扩展PG内存 !
3种方式 PG大版本升级 接锅,背锅,不甩锅 以客户为中心做产品
"PostgreSQL" 不重启机器就能调整 shared buffer pool 的原理
说我PG Freezing Boom 讲的一般的那个同学专帖给你看这次可满意
PostgreSQL Hybrid能力岂非“小趴菜”数据库可比 ?
PostgreSQL 新版本就一定好--由培训现象让我做的实验
PostgreSQL 无服务 Neon and Aurora 新技术下的新经济模式 (翻译)
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
PostgreSQL 添加索引导致崩溃,参数调整需谨慎--文档未必完全覆盖场景
PostgreSQL SQL优化用兵法,优化后提高 140倍速度
PostgreSQL 运维的难与“难” --上海PG大会主题记录
PostgreSQL 什么都能存,什么都能塞 --- 你能成熟一点吗?
全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始 PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!
病毒攻击PostgreSQL暴力破解系统,防范加固系统方案(内附分析日志脚本)
PostgreSQL 远程管理越来越简单,6个自动化脚本开胃菜
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 如何通过工具来分析PG 内存泄露
PostgreSQL 分组查询可以不进行全表扫描吗?速度提高上千倍?
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然,不是PG的锅
PostgreSQL 字符集乌龙导致数据查询排序的问题,与 MySQL 稳定 "PG不稳定"
PostgreSQL Patroni 3.0 新功能规划 2023年 纽约PG 大会 (音译)
PostgreSQL 玩PG我们是认真的,vacuum 稳定性平台我们有了
PostgreSQL DBA硬扛 垃圾 “开发”,“架构师”,滥用PG 你们滚出 !(附送定期清理连接脚本)
DBA 失职导致 PostgreSQL 日志疯涨
这个 PostgreSQL 让我有资本找老板要 鸡腿 鸭腿 !!
MySQL相关文章
一篇为MySQL用户,分析版本核心差异的文章--8.028-8.4的差异
那个MySQL大事务比你稳定,主从延迟低,为什么? Look my eyes! 因为宋利兵宋老师
MySQL timeout 参数可以让事务不完全回滚
MySQL 让你还用5.7 出事了吧,用着用着5.7崩了
MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验
用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊
MYSQL --Austindatabases 历年文章合集
超强外挂让MySQL再次兴盛,国内神秘组织拯救MySQL行动

本文分享自 AustinDatabases 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!