【GreatSQL优化器-03】查询开销估算

news/2024/12/25 14:44:35/文章来源:https://www.cnblogs.com/greatsql/p/18556136

【GreatSQL优化器-03】查询开销估算

一、cost和read_time介绍

GreatSQL的优化器在创建执行计划的时候是根据每张表的行数和数据分布以及读数据硬盘消耗等信息来判断先查询哪张表后查询哪张表，要不要使用索引，这些表资源信息就被称为cost，俗称为"开销"。在这之前已经执行了update_ref_and_keys（参考【GreatSQL优化器-02】）和extract_const_tables（参考【GreatSQL优化器-01】），拿到了const tables信息和表的keyuse_array索引信息，这里就开始计算单张表扫描的开销，做一个初步的估计，用来给后面的choose_table_order()搜索最佳表顺序提供原始数据信息。

优化器通过estimate_rowcount函数初步计算单表开销，这个函数最后会计算出3个重要的数据。

名称 说明 计算公式
found_records 表的总行数 tab->table()->file->stats.records
read_time 读取所有数据需要的开销 io_cost + cpu_cost + import_cost
worst_seeks 扫描全表需要的最差开销 find_worst_seeks(tab->table(), tab->found_records, tab->read_time)根据上面2项计算得出

下面用一个简单的例子来说明这三个数字怎么查看：

greatsql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT,date1 DATETIME);
greatsql> INSERT INTO t1 VALUES (1,10,'2021-03-25 16:44:00.123456'),(2,1,'2022-03-26 16:44:00.123456'),(3,4,'2023-03-27 16:44:00.123456'),(5,5,'2024-03-25 16:44:00.123456');
greatsql> CREATE TABLE t2 (cc1 INT PRIMARY KEY, cc2 INT);
greatsql> INSERT INTO t2 VALUES (1,3),(2,1),(3,2),(4,3),(5,15);
greatsql> CREATE INDEX idx1 ON t1(c2);
greatsql> CREATE INDEX idx2 ON t1(c2,date1);
greatsql> CREATE INDEX idx2_1 ON t2(cc2);
greatsql> SET optimizer_trace = 'enabled=ON' ;greatsql> SELECT * FROM t2,t1,(select 10) t3 where t1.c1=t2.cc2;
+-----+------+----+------+---------------------+----+
| cc1 | cc2  | c1 | c2   | date1               | 10 |
+-----+------+----+------+---------------------+----+
|   3 |    2 |  2 |    1 | 2022-03-26 16:44:00 | 10 |
|   1 |    3 |  3 |    4 | 2023-03-27 16:44:00 | 10 |
|   4 |    3 |  3 |    4 | 2023-03-27 16:44:00 | 10 |
|   2 |    1 |  1 |   10 | 2021-03-25 16:44:00 | 10 |
+-----+------+----+------+---------------------+----+
> SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;{"rows_estimation": [{"table": "`t2`",  -- 按照上面查询顺序t2放第一个"table_scan": {"rows": 5, 因为t2非const表，因此这里显示的是所有行"cost": 0.25, 这个是t2查询5条的开销，"worst_seeks": 2 这里是另外加上去的，为了查看方便}},{"table": "`t1`", 按照上面查询顺序t1放第二个"table_scan": {"rows": 4, 因为t1非const表，因此这里显示的是所有行"cost": 0.25,"worst_seeks": 2 这里是另外加上去的，为了查看方便}},{"table": " `t3`", 按照上面查询顺序t3放第三个"rows": 1,"cost": 1, ※这里有疑问，实际的read_time=worst_seeks=0.25，但是代码用了固定值1"worst_seeks": 0.25 这里是另外加上去的，为了查看方便"table_type": "system", 因为t3是const表，因此这里显示的system"empty": false}]},

附表：代价系数

代价系数 值 说明
ROW_EVALUATE_COST 0.1 扫描一行需要的开销
KEY_COMPARE_COST 0.05 比较row id需要的开销
MEMORY_TEMPTABLE_CREATE_COST 1.0 创建临时表的开销，等于读10行
MEMORY_TEMPTABLE_ROW_COST 0.1 读或写一行到临时表
DISK_TEMPTABLE_CREATE_COST 20.0 创建MyISAM表的开销
DISK_TEMPTABLE_ROW_COST 0.5 按顺序生成 MyISAM 行的开销
MEMORY_BLOCK_READ_COST 0.25 读一个block从一个memory buffer pool
IO_BLOCK_READ_COST 1.0 从磁盘读取block

二、estimate_rowcount代码执行过程

实际代码执行过程如下，其中test_quick_select()函数在下面第三节介绍：

bool JOIN::make_join_plan() {if (estimate_rowcount()) return true;
}bool JOIN::estimate_rowcount() {// 遍历每张表，计算每张表的上面3个值for (JOIN_TAB *tab = join_tab; tab < tab_end; tab++) {// 计算下面几个值tab->set_records(tab->found_records = tab->table()->file->stats.records);const Cost_estimate table_scan_time = tab->table()->file->table_scan_cost();tab->read_time = table_scan_time.total_cost();tab->worst_seeks =find_worst_seeks(tab->table(), tab->found_records, tab->read_time);// 这个函数是副功能，用于发现可能用于 GROUP BY 或 DISTINCT 查询的索引或可能用于 SKIP SCAN 的索引。// 主要给skip_scan_keys和const_keys添加可以用的索引add_loose_index_scan_and_skip_scan_keys(this, tab);// 如果上面计算得到的read_time<= 2.0那就不做快速查询test_quick_select()直接返回了，但是如果大于的话就要找是否有索引用快速查询来估算开销了。get_quick_record_count();}
}

上面涉及的参数值见下表。

细项 说明 计算公式
table_scan_cost() 引擎层读表的开销 ((stats.data_file_length) / IO_SIZE + 2) * table->cost_model()->page_read_cost(1.0)
find_worst_seeks() 全表扫描所需的最多开销 worst_seeks = min(table->file->worst_seek_times(tab->found_records / 10), tab->read_time * 3); min_worst_seek = table->file->worst_seek_times(2.0); 结果为：std::max(worst_seeks, min_worst_seek);

三、计算单表cost举例说明

例子1：SELECT * FROM t1 join t2 ON t1.c1=t2.cc1 and t2.cc1=t1.c1 or t1.c1=5;{"rows_estimation": [{"table": "`t1`","range_analysis": {"table_scan": {"rows": 4,"cost": 3.5 这里算出来的开销大于2了，因此要走test_quick_select()估算},"potential_range_indexes": [ 这里开始循环t1的所有索引，找出条件涉及的索引{"index": "PRIMARY", 条件涉及到了t1.c1，因此这里PRIMARY索引被使用"usable": true,"key_parts": ["c1"]},{"index": "idx1", 条件不涉及idx1，因此这里idx1索引不被使用"usable": false,"cause": "not_applicable"},{"index": "idx2", 条件不涉及idx2，因此这里idx2索引不被使用"usable": false,"cause": "not_applicable"}],"best_covering_index_scan": { 通过find_shortest_key()找到的最短的索引，指覆盖所有需要的数据的联合索引table->covering_keys"index": "idx2", 这个值为table->covering_keys，联合索引包含了主键信息"cost": 1.40548, 开销小于上面的最早算出来的3.5，因此被选择。这里io_cost=1.00548，cpu_cost=4行*0.1（读每行开销）"chosen": true},"setup_range_conditions": [ 没有找到mm tree],"group_index_range": { 不是GROUP语句"chosen": false,"cause": "not_single_table"},"skip_scan_range": { 没有配置skip_scan，不需要skip_scan"chosen": false,"cause": "not_single_table"}}},{"table": "`t2`","table_scan": {"rows": 5,"cost": 1 表t2算出来的开销小于2，因此不继续用快速查询计算了。}}]},
-- t1选择索引 idx2，因为cost更小
-- t2的选择结果需要结合后面的choose_table_order()看，下一期再讲
greatsql> EXPLAIN SELECT * FROM t1 join t2 ON t1.c1=t2.cc1 and t2.cc1=t1.c1 or t1.c1=5;
+----+-------------+-------+------------+-------+---------------+--------+---------+------+------+----------+---------------------------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key    | key_len | ref  | rows | filtered | Extra                                                   |
+----+-------------+-------+------------+-------+---------------+--------+---------+------+------+----------+---------------------------------------------------------+
|  1 | SIMPLE      | t1    | NULL       | index | PRIMARY       | idx2   | 11      | NULL |    4 |   100.00 | Using index                                             |                               这里选择了idx2索引扫描，跟上面算出来的结论一致
|  1 | SIMPLE      | t2    | NULL       | index | PRIMARY       | idx2_1 | 5       | NULL |    5 |   100.00 | Using where; Using index; Using join buffer (hash join) |
+----+-------------+-------+------------+-------+---------------+--------+---------+------+------+----------+---------------------------------------------------------+

看另一个例子：

例子2：SELECT * FROM t1 join t2 ON t1.c1=t2.cc1 and t1.c1<5;{"rows_estimation": [{"table": "`t1`","range_analysis": {"table_scan": {"rows": 4,"cost": 3.5 这里算出来的开销大于2了，因此要走test_quick_select()估算},"potential_range_indexes": [{"index": "PRIMARY", 条件涉及到了t1.c1，因此这里PRIMARY索引被使用"usable": true,"key_parts": ["c1"]},{"index": "idx1", 条件不涉及idx1，因此这里idx1索引不被使用"usable": false,"cause": "not_applicable"},{"index": "idx2", 条件不涉及idx2，因此这里idx2索引不被使用"usable": false,"cause": "not_applicable"}],"best_covering_index_scan": { 找到联合索引，包含了主键信息"index": "idx2","cost": 1.40548,"chosen": true},"setup_range_conditions": [],"group_index_range": { 不是GROUP语句"chosen": false,"cause": "not_single_table"},"skip_scan_range": { 没有配置skip_scan，不需要skip_scan"chosen": false,"cause": "not_single_table"},"analyzing_range_alternatives": {"range_scan_alternatives": [{"index": "PRIMARY", 根据get_best_group_min_max算出来的mm tree找到的最佳索引"ranges": ["c1 < 5"],"index_dives_for_eq_ranges": true,"rowid_ordered": true,"using_mrr": false,"index_only": false,"in_memory": 0,"rows": 3, 范围扫描c1 < 5找到的符合的条数3条"cost": 1.31293, 比上面算出来的cost低，因此被选择"chosen": true}],"analyzing_roworder_intersect": {"usable": false,"cause": "too_few_roworder_scans" 因为tree->n_ror_scans < 2，所以没有被选择}},"chosen_range_access_summary": { 总结上面所有计算的结果得出结论"range_access_plan": {"type": "range_scan", 结论是走索引范围扫描"index": "PRIMARY","rows": 3,"ranges": ["c1 < 5"]},"rows_for_plan": 3, 找到3条数据"cost_for_plan": 1.31293,"chosen": true}}},{"table": "`t2`","range_analysis": {"table_scan": {"rows": 5,"cost": 3.6 这里算出来的开销大于2了，因此要走test_quick_select()估算},"potential_range_indexes": [{"index": "PRIMARY", 涉及到主键列，因此用到了"usable": true,"key_parts": ["cc1"]},{"index": "idx2_1", 没有涉及cc2，因此没有用到"usable": false,"cause": "not_applicable"}],"best_covering_index_scan": { 找到的非唯一索引，开销比上面的小，被选择"index": "idx2_1","cost": 1.50439,"chosen": true},"setup_range_conditions": [],"group_index_range": {"chosen": false,"cause": "not_single_table"},"skip_scan_range": {"chosen": false,"cause": "not_single_table"},"analyzing_range_alternatives": {"range_scan_alternatives": [{"index": "PRIMARY","ranges": ["cc1 < 5"],"index_dives_for_eq_ranges": true,"rowid_ordered": true,"using_mrr": false,"index_only": false,"in_memory": 0,"rows": 4, 根据cc1 < 5条件找到4条数据记录"cost": 1.4133, 开销更小，被选择"chosen": true}],"analyzing_roworder_intersect": {"usable": false,"cause": "too_few_roworder_scans"}},"chosen_range_access_summary": { 总结上面所有计算的结果得出结论"range_access_plan": {"type": "range_scan",  结论是走索引范围扫描"index": "PRIMARY","rows": 4,"ranges": ["cc1 < 5"]},"rows_for_plan": 4, 找到4条记录"cost_for_plan": 1.4133,"chosen": true}}}]},-- 结论：t1表用了范围扫描，跟上面结论一致
-- t2的选择结果需要结合后面的best_access_path()看，下一期再讲
greatsql> EXPLAIN SELECT * FROM t1 join t2 ON t1.c1=t2.cc1 and t1.c1<5;
+----+-------------+-------+------------+--------+---------------+---------+---------+-----------+------+----------+-------------+
| id | select_type | table | partitions | type   | possible_keys | key     | key_len | ref       | rows | filtered | Extra       |
+----+-------------+-------+------------+--------+---------------+---------+---------+-----------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | range  | PRIMARY       | PRIMARY | 4       | NULL      |    3 |   100.00 | Using where |                                    
|  1 | SIMPLE      | t2    | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | db1.t1.c1 |    1 |   100.00 | NULL        |
+----+-------------+-------+------------+--------+---------------+---------+---------+-----------+------+----------+-------------+

四、总结

从上面优化器最早的步骤我们认识了优化器的cost和计算方式，知道了如何初步估算单表的扫描cost并且按照最小cost选择最佳索引，这些单表估算出来的cost会在后面greedy_search（贪婪搜索）的时候用来做为计算依据，然后按照每张表的扫描开销对表进行排序，算出哪张表先扫描哪张表后扫描，最后得出最佳执行计划。

需要注意的是，上面的初步估算cost<=2的时候是不会进行后续快速扫描计算的，因此如果实际运用中想查看表的正确cost的话，需要根据当时表的实际数据量来做执行计划计算，而不是在空表或者数据量很小时候先做一次执行计划，然后用这个结果得出结论。

Enjoy GreatSQL 😃

关于 GreatSQL

GreatSQL是适用于金融级应用的国内自主开源数据库，具备高性能、高可靠、高易用性、高安全等多个核心特性，可以作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。

相关链接： GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区：

社区博客有奖征稿详情：https://greatsql.cn/thread-100-1-1.html

image-20230105161905827

技术交流群：

微信：扫码添加GreatSQL社区助手微信好友，发送验证信息加群。

image-20221030163217640

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/837210.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

PyODPS获取MaxComputer数据仓中业务表的最新更新时间并输出至表中

PyODPS获取MaxComputer数据仓中业务表的最新更新时间并输出至表中

PyODPS获取MaxComputer数据仓中业务表的最新更新时间并输出1.准备两张数据表： 1.1 需要统计的库表中间表：CREATE TABLE IF NOT EXISTS dim_river_system_business_time (`id` STRING COMMENT 序号,`dept_name` STRING COMMENT ,`system_name` STRING COMMENT 所属系统,…
阅读更多...
powerdesigner同时显示列的name和code

powerdesigner同时显示列的name和code

参考来源：数据库设计工具-PowerDesigner中table视图显示name与code 1、Tools-->Display Preferences2、Table->Advanced3、Columns-->放大镜图标4、勾选【code】并调整顺序到datatype之前5、单击ok，成功
阅读更多...
RedisTemplate RedisConfig 序列化方式 fastjson2

RedisTemplate RedisConfig 序列化方式 fastjson2

Spring Data Redis 为我们提供了下面的Serializer：GenericToStringSerializer、Jackson2JsonRedisSerializer、JacksonJsonRedisSerializer、JdkSerializationRedisSerializer、OxmSerializer、StringRedisSerializer。序列化方式对比：JdkSerializationRedisSerializer: 使用…
阅读更多...
实验 20：备忘录模式

实验 20：备忘录模式

本次实验属于模仿型实验，通过本次实验学生将掌握以下内容： 1、理解备忘录模式的动机，掌握该模式的结构； 2、能够利用备忘录模式解决实际问题。[实验任务一]：多次撤销 改进课堂上的“用户信息操作撤销”实例，使得系统可以实现多次撤销（可以使用HashMap、ArrayList等集合…
阅读更多...
实验 21：观察者模式

实验 21：观察者模式

本次实验属于模仿型实验，通过本次实验学生将掌握以下内容： 1、理解观察者模式的动机，掌握该模式的结构； 2、能够利用观察者模式解决实际问题。[实验任务一]：股票提醒 当股票的价格上涨或下降5%时，会通知持有该股票的股民，当股民听到价格上涨的消息时会买股票，当价格下…
阅读更多...
MaskLLM：英伟达出品，用于大模型的可学习`N:M`稀疏化 | NeurIPS24

MaskLLM：英伟达出品，用于大模型的可学习`N:M`稀疏化 | NeurIPS24

来源：晓飞的算法工程笔记 公众号，转载请注明出处论文: MaskLLM: Learnable Semi-Structured Sparsity for Large Language Models论文地址：https://arxiv.org/abs/2409.17481 论文代码：https://github.com/NVlabs/MaskLLM创新性提出一种可学习的LLM半结构化剪枝方法MaskLLM…
阅读更多...
Codeforces 1145 题目分析

Codeforces 1145 题目分析

本文将分析 Codeforces 1145 (April Fools Day Contest 2019)。 题目分析 A 题目描述：使用“灭霸排序”算法可以得到的最长子串的长度。 解法：暴力。 B 题目描述：输入一个整数 \(\in [1,99]\)，若它的英文形式含有 knba 四个字母输出 NO 否则输出 YES。 解法：打表。 C 题目…
阅读更多...
3.2点对点ppp

3.2点对点ppp

001ppp协议特点 ppp协议能承载不同网络层分组，ip数据报里有其他网络层协议存在。 能在多种类型的链路上运行 和广播方式相比，需要一个网络地址的协商，传送前有个协商过程，确认资源。地址002ppp协议组成 将ip数据报封装到串行链路的方法 链路控制协议LCP--建立链路，身份验证…
阅读更多...
.net8报HTTP Error 500.30 - ASP.NET Core app failed to start

.net8报HTTP Error 500.30 - ASP.NET Core app failed to start

.net8调试正常，发布到IIS报HTTP Error 500.30 - ASP.NET Core app failed to start。 解决办法： 停止IIS站点，运行发布项目的“XXX.exe”，在运行窗口就可以看到具体的错误信息。 在根据具体错误信息解决。
阅读更多...
设计和训练人工智能模型的意义是什么？

设计和训练人工智能模型的意义是什么？

前一篇：《人工智能模型训练技术，正则化！》 序言：人工智能模型的真正价值在于其实际应用，而不仅仅停留在理论阶段。本节将通过一个简单而常见的应用场景，展示如何将前面几节所设计和训练的模型应用于实际问题。我们将使用训练好的模型对句子进行分类，具体来说，识别社交平…
阅读更多...
【分享】数据传输新挑战：内外网文件如何实现安全高效摆渡？

【分享】数据传输新挑战：内外网文件如何实现安全高效摆渡？

随着信息化的不断深入，越来越多的数据被电子化，这使得数据安全问题变得更加突出。全球42%的企业在过去一年中至少经历过一次数据泄露事故，30%的企业IT人员在数据泄露事故中被开除，50%的企业IT认为文件管控难度大、成本高。 为了保护核心数据，大部分企业都实施了内外网隔离…
阅读更多...
画图-利用画图工具修改聊天记录时间

画图-利用画图工具修改聊天记录时间

1、用Windows自带的画图工具 打开要修改的图片 选择“矩形”用矩形选中要修改的时间即可对其进行 移动 或者覆盖的操作
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023