【GreatSQL优化器-17】DYNAMIC RANGE

【GreatSQL优化器-17】DYNAMIC RANGE

一、DYNAMIC RANGE介绍

GreatSQL 的优化器有一种扫描方式是动态范围扫描方式,类似于“已读乱回”模式,这种模式是在表有多个索引的情况下,对驱动表连接的时候部分选择索引的情况。优化器没有找到好的索引可以使用,但发现在知道前面表的列值后,可能会使用某些索引。对于前面表中的每个行组合,优化器检查是否可以使用 range 或 index merge 访问方法来检索行。虽然这不是很快,但比执行完全没有索引的连接要快。

下面用一个简单的例子来说明直方图怎么应用在优化器。

CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT,date1 DATETIME);
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'),(7,null,'2020-03-25 16:44:00.123456'),(8,10,'2020-10-25 16:44:00.123456'),(11,16,'2023-03-25 16:44:00.123456');
CREATE TABLE t2 (cc1 INT PRIMARY KEY, cc2 INT);
INSERT INTO t2 VALUES (1,3),(2,1),(3,2),(4,3),(5,15);
CREATE TABLE t3 (ccc1 INT, ccc2 varchar(100));
INSERT INTO t3 VALUES (1,'aa1'),(2,'bb1'),(3,'cc1'),(4,'dd1'),(null,'ee');
CREATE INDEX idx1 ON t1(c2);
CREATE INDEX idx2 ON t1(c2,date1);
CREATE INDEX idx2_1 ON t2(cc2);
CREATE INDEX idx3_1 ON t3(ccc1);

greatsql> EXPLAIN SELECT * FROM t1 join t3 ON t1.c1=t3.ccc1 or t1.c2<5;
+----+-------------+-------+------------+------+-------------------+------+---------+------+------+----------+------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys     | key  | key_len | ref  | rows | filtered | Extra                                          |
+----+-------------+-------+------------+------+-------------------+------+---------+------+------+----------+------------------------------------------------+
|  1 | SIMPLE      | t3    | NULL       | ALL  | idx3_1            | NULL | NULL    | NULL |    5 |   100.00 | NULL                                           |
|  1 | SIMPLE      | t1    | NULL       | ALL  | PRIMARY,idx1,idx2 | NULL | NULL    | NULL |    7 |    43.67 | Range checked for each record (index map: 0x7) |
-- 这里的结果出现了Range checked,说明进行了DYNAMIC_RANGE
+----+-------------+-------+------------+------+-------------------+------+---------+------+------+----------+------------------------------------------------+

greatsql> SELECT * FROM t1 join t3 ON t1.c1=t3.ccc1 or t1.c2<5;
+----+------+---------------------+------+------+
| c1 | c2   | date1               | ccc1 | ccc2 |
+----+------+---------------------+------+------+
|  1 |   10 | 2021-03-25 16:44:00 |    1 | aa1  |
|  2 |    1 | 2022-03-26 16:44:00 |    1 | aa1  |
|  3 |    4 | 2023-03-27 16:44:00 |    1 | aa1  |
|  2 |    1 | 2022-03-26 16:44:00 |    2 | bb1  |
|  3 |    4 | 2023-03-27 16:44:00 |    2 | bb1  |
|  2 |    1 | 2022-03-26 16:44:00 |    3 | cc1  |
|  3 |    4 | 2023-03-27 16:44:00 |    3 | cc1  |
|  2 |    1 | 2022-03-26 16:44:00 |    4 | dd1  |
|  3 |    4 | 2023-03-27 16:44:00 |    4 | dd1  |
|  2 |    1 | 2022-03-26 16:44:00 | NULL | ee   |
|  3 |    4 | 2023-03-27 16:44:00 | NULL | ee   |
+----+------+---------------------+------+------+

greatsql> SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
             "attaching_conditions_to_tables": {
              "original_condition": "((`t1`.`c1` = `t3`.`ccc1`) or (`t1`.`c2` < 5))",
              "attached_conditions_computation": [
                {
                  "table": "`t1`",
                  "rechecking_index_usage": { -- 这里对t1进行了recheck
                    "recheck_reason": "not_first_table",
                    "range_analysis": {
                      "table_scan": {
                        "rows": 7,
                        "cost": 3.05
                      },
                      "potential_range_indexes": [
                        {
                          "index": "PRIMARY",
                          "usable": true,
                          "key_parts": [
                            "c1"
                          ]
                        },
                        {
                          "index": "idx1",
                          "usable": true,
                          "key_parts": [
                            "c2",
                            "c1"
                          ]
                        },
                        {
                          "index": "idx2",
                          "usable": true,
                          "key_parts": [
                            "c2",
                            "date1",
                            "c1"
                          ]
                        }
                      ],
                      "best_covering_index_scan": {
                        "index": "idx2",
                        "cost": 0.952742,
                        "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": [
                        ],
                        "analyzing_roworder_intersect": {
                          "usable": false,
                          "cause": "too_few_roworder_scans"
                        }
                      },
                      "analyzing_index_merge_union": [
                        {
       
<think>好的,用户需要解决的是在安装GreatSQL Server 8.0.32时遇到的依赖问题,具体是缺少liblber-2.4.so.2的64位版本。首先,我得确认这个库的来源。通常,liblber是OpenLDAP的一部分,属于其中的一个库。因此,用户可能需要安装OpenLDAP的相关软件包。 接下来,我需要考虑不同的Linux发行版,用户提到的是.el8,说明是RHEL或CentOS 8系统。在基于RPM的系统上,可以使用yum或dnf来查找和安装依赖。用户可能需要先检查是否已经安装了OpenLDAP的库,或者是否存在版本冲突。有时候,软件包名称可能有所不同,所以需要用yum provides命令来查找哪个包提供这个库。 另外,用户可能需要启用EPEL仓库或其他第三方仓库,如果默认仓库中没有所需的版本。如果系统自带的OpenLDAP版本不兼容,可能需要手动下载或编译指定版本的库,但这样可能会带来维护上的问题,需要谨慎处理。 还要考虑到依赖关系,安装liblber时可能需要同时安装其他依赖库,比如libsasl2等。用户需要按照提示逐一安装。如果遇到冲突,可能需要卸载现有不兼容的版本,但要注意这可能会影响其他依赖该库的应用程序。 最后,建议用户安装完成后使用ldconfig更新动态链接库缓存,并通过ldd验证GreatSQL是否成功链接到正确的库版本。如果所有方法都无效,可能需要联系GreatSQL的支持团队获取更详细的帮助。</think>以下是解决 $liblber-2.4.so.2()(64bit)$ 依赖问题的分步指南: ### 一、确认依赖关系来源 该库属于 $OpenLDAP$ 的客户端库组件,可通过以下命令验证: ```bash ldd /usr/local/greatsql/bin/mysqld | grep liblber ``` ### 二、RHEL/CentOS 8 解决方案 1. 添加EPEL仓库: ```bash dnf install epel-release ``` 2. 安装完整版OpenLDAP套件: ```bash dnf install openldap-devel-2.4.46-18.el8.x86_64 ``` 3. 验证安装结果: ```bash rpm -ql openldap-devel | grep liblber-2.4.so.2 ``` ### 三、兼容性处理(若遇冲突) 当出现版本冲突时,可创建符号链接: ```bash ln -sf /usr/lib64/liblber-2.4.so.2.10.12 /opt/greatsql/custom_lib/ echo "/opt/greatsql/custom_lib" > /etc/ld.so.conf.d/greatsql.conf ldconfig ``` ### 四、替代方案 对于使用 `yum` 的场景: ```bash yum install compat-openldap-2.4.46 ``` ### 五、编译安装(最终手段) 1. 下载源码: ```bash wget ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.46.tgz ``` 2. 编译配置: ```bash ./configure --prefix=/opt/custom_openldap --enable-syslog --enable-dynamic ``` 3. 选择性编译: ```bash make depend && make -C libraries/liblber/ ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值