形式❝开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共3000人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满,开8群近400 9群 200+,开10群PolarDB专业学习群 7月份开课)
这是PolarDB 的第三节课,这节课里面我们将开始接触技术,我们先从大家最感兴趣的提高MySQL的性能入手,针对复杂的SQL的问题如何解决,来切入PolarDB for MySQL的使用具体的方案。
首先什么是PolarDB IMCI,(In-Memory Column index,内存列索引),这是我们在使用PolarDB for MySQL的核心功能之一,通过添加IMCI功能后,MySQL瞬间可以从复杂语句的“小趴菜”,转变成复杂语句执行的“小钢炮”。
今天的课程我们就来说说,咱们让"MySQL" 开挂。
纠正视频中的一句话的问题:PoalrDB for MySQL 行存读+列存读最大不超过15个节点。
我们对比一下在PolarDB for MySQL,三张表数据量分别在1百万,10万,1万,三个表进行关联操作。
三张表 1百万,10万,1万
语句1
image-> Limit: 50 row(s) (actual time=6200.656..6200.677 rows=50 loops=1)
-> Sort:
.total_spent DESC, limit input to 50 row(s) per chunk (actual time=6200.655..6200.667 rows=50 loops=1)
-> Table scan on (actual time=0.002..30.373 rows=99987 loops=1)
-> Aggregate using temporary table (actual time=6136.153..6183.477 rows=99987 loops=1)
-> Nested loop inner join (cost=386399.09 rows=1011227) (actual time=0.104..4674.055 rows=1000000 loops=1)
-> Index scan on u using idx_users_user_id (cost=10094.85 rows=100066) (actual time=0.045..57.950 rows=100000 loops=1)
-> Index lookup on o using user_id (user_id=u.user_id) (cost=2.75 rows=10) (actual time=0.039..0.044 rows=10 loops=100000)
ALTER TABLE test.users COMMENT 'COLUMNAR=1';
ALTER TABLE test.orders COMMENT 'COLUMNAR=1';
'1', 'Select Statement', '', '', '', 'IMCI Execution Plan (max_dop = 2, max_query_mem = 429496729)'
'2', '└─Compute Scalar', '', '50', '16651.35', ''
'3', ' └─Limit', '', '50', '16651.32', 'Offset=0 Limit=50'
'4', ' └─Sort', '', '50', '16651.32', 'Sort Key: SUM(o.total_price) DESC'
'5', ' └─Hash Groupby', '', '1000000', '14247.27', 'Group Key: (u.user_name, u.user_id)'
'6', ' └─Hash Join', '', '1000000', '10267.30', 'Join Cond: u.user_id = o.user_id, DynamicFilter: (0: Inlist,Range
'7', ' ├─Table Scan', 'u', '100000', '4.00', ''
'8', ' └─Table Scan', 'o', '1000000', '40.00', 'DynamicFilter: ((0: Range -> o.user_id) (0: Inlist -> o.user_id))'
我们这里不去管MySQL本身的执行计划,因为没有过滤数据条件的SQL本身在行式引擎执行就是一个错误,从计算和数据存储和数据处理它就是一个问题。
在我们加入了IMCI节点后,整体语句的执行计划将在IMCI节点进行处理,在将结果返回给代理最终回馈客户。
我们来逐行分析这个IMCI执行语句的执行计划:
这条语句的初衷是从所有的数据中找到每个用户的总金额最高的前50位客户
执行计划分析:
按照实际的执行顺序
行 8: └─Table Scan (表 o)
表名: o ( orders 表)
行数估算: 1000000
Cost 估算: 40.00
行 7: ├─Table Scan (表 u)
表名: u ( users 表)
行数估算: 100000
Cost 估算: 4.00
解释: 对 users 表进行全表扫描。估算行数为 10 万。Cost 为 4.00 非常低,
行 6: └─Hash Join
行数估算: 1000000
Cost 估算: 10267.30
: Join Cond: u.user_id = o.user_id 表明这是 users 表 (u) 和 orders 表 (o) 之间的连接操作,连接条件是 user_id。Hash Join 是一种常见的、高效的连接算法,特别是当其中一张表(较小的表)可以完全放入内存中建立哈希表时。
行 5: └─Hash Groupby
行数估算: 1000000
Cost 估算: 14247.27
解释: Group Key: (u.user_name, u.user_id) 表示数据库对 user_name 和 user_id 进行分组,并计算聚合函数 (SUM(o.total_price))。Hash Groupby 是一种高效的分组方式,它通过哈希表来聚合数据
行 4: └─Sort
行数估算: 50
Cost 估算: 16651.32
行 3: └─Limit
行数估算: 50
Cost 估算: 16651.32
Offset=0 Limit=50 表示查询只返回前 50 条记录。这是为了满足“找出总金额最高的 50 个用户”的需求。Limit 操作通常在 Sort 之后。
行 2: └─Compute Scalar
行数估算: 50
Cost 估算: 16651.35
Compute Scalar 通常用于计算表达式,比如这里可能是对最终的 SUM(o.total_price) 结果进行一些格式化或最终的计算。
行 1: Select Statement
表示这是一个标准的 SELECT 语句的执行计划。
极低的 Table Scan Cost:
u 表扫描 Cost 4.00 (10万行) 和 o 表扫描 Cost 40.00 (100万行)。对传统的行存数据库(如 InnoDB)来说,百万行级别的全表扫描成本通常要很高。在列中行数的高低并不决定扫描成本的高低。
IMCI 优势: IMCI 将数据以列式存储的方式保存在内存中。当执行查询时,只需要读取查询涉及的列,内存访问速度远超磁盘,这大大降低了扫描成本。
IMCI 优势: IMCI 会为列数据构建高效的压缩索引结构,使 Hash Join 和 Hash Groupby 能够更快地处理大量数据。
同时需要注意,这里还动用了并行使用了2个并行。同时IMCI是一个内存计算引擎,并行和内存使用会将计算的速度继续推高。
通过使用IMCI,数据压缩了,存储在列存中,还可以并行计算,将数据装入到内存中进行处理,列式的计算引擎+列式存储+可动态添加的列式节点,让PolarDB for MySQL 变成了性能小怪兽。
本期的问题:
1 PolarDB 官方有一个称呼以下哪个是对的?
A 积木数据库 B 插件数据库 C Extension 数据库 D 以上都不对
2 PolarDB IMCI 的全拼是什么,当代先进数据库的特征是什么?
3 PolarDB IMCI在数据处理中使用了什么算法,在视频中提到了哪三个算法?
1 每次课程最先答对题目问题的,且在文章下面评论区回复的有中奖的机会。2 拿到奖品两次后,积极回答问题的同学,将进入下一个环节,学习之星的评选,我们将对这些同学有新的奖励模式。3 没有拿到过奖品的同学,有更多在每次答题中有优先获奖的权利,对比拿过奖品的同学。感谢积极参与此次活动的同学。另如果有同学可以介绍新人加入学习群体了,我们也有新的奖励,如果您介绍3位以上的同学真正进入并进行学习,我们将有奖品给到您,具体奖品在10群里面公布,加群请联系liuausitn3加微信进入10群。