形式❝开头还是介绍一下群，如果感兴趣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群。
