PolarDB 非官方课程第三节--MySQL+IMCI=性能怪兽--答题领奖品

形式❝

开头还是介绍一下群，如果感兴趣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万，三个表进行关联操作。

-> Limit: 50 row(s)  (actual time=6200.656..6200.677 rows=50 loops=1)
    -> Sort: <temporary>.total_spent DESC, limit input to 50 row(s) per chunk  (actual time=6200.655..6200.667 rows=50 loops=1)
        -> Table scan on <temporary>  (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 <- u.user_id) '
'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位客户

执行计划分析：

按照实际的执行顺序

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在数据处理中使用了什么算法，在视频中提到了哪三个算法？