自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(2835)
  • 收藏
  • 关注

原创 作品:Python 实现的 Java 解析器(metasequoia-java)

水杉 Java 解析器为纯 Python 开发,不依赖其他第三方包,在任意环境下直接 pip 安装即可(在词法解析层,我们采用有限状态自动机实现;在语法解析层,我们采用调用的方式实现。与其他解析逻辑一样,我们采用词法解析与语法解析分离的解析器实现方案。

2025-01-05 23:20:05 394

原创 MySQL 源码|113 - 抽象语法树:(5) 枚举类型的节点 ②

文档中对枚举值描述部分由 AI 生成。

2025-05-02 18:44:36 921

原创 MySQL 源码|112 - 抽象语法树:(4) 枚举类型的节点 ①

文档中对枚举值描述部分由 AI 生成。

2025-05-02 18:42:50 777

原创 MySQL 源码|111 - 抽象语法树:(3) 字符串类型的节点

LEX_STRING。

2025-05-02 17:53:19 651

原创 MySQL 源码|110 - 抽象语法树:(2) 关键字和标识符

LEX_SYMBOL。

2025-05-02 17:49:31 415

原创 MySQL 源码|109 - 抽象语法树:(1) 节点的基类

除此以外,还定义了各个子类将会重写的方法,这些我们在梳理各个子类时再逐个梳理。类中,MySQL 定义了大量的枚举值和枚举值映射规则。类,大部分 MySQL 抽象语法树的节点都使用了。MySQL 抽象语法树的绝大部分节点继承自。的定义如下,其中定义了。为结构体,继承自结构体。

2025-05-02 17:46:44 311

原创 MySQL 源码|108 - 词法解析:状态转移逻辑(其他符号)

【代码】MySQL 源码|108 - 词法解析:状态转移逻辑(其他符号)

2025-03-24 21:51:18 928

原创 MySQL 源码|107 - 词法解析:状态转移逻辑(字面值)

语句逻辑,继续执行另一个状态的处理逻辑,则在描述中将这种情况也描述为重置了自动机状态以方便理解。Unicode 字符串字面值的格式为。如果在实现中,通过没有跳出。字符串字面值的格式为。

2025-03-24 21:50:09 816

原创 MySQL 源码|106 - 词法解析:状态转移逻辑(标识符)

方法在哈希表中进行搜索,构造 Token 对象写入。时,说明上一个 Token 是标识符且当前字符是。属性中,并返回 Token 类型。而其他英文字符,或多字节字符则会被置为。时,说明之前两个 Token 分别是标识符和。对象的当前 Token 构造。开头标识符或关键字,会先从。开头的标识符或关键字会经过。,然后因为下一个字符不是。开头的语法元素也会通过。函数中,直接根据当前。

2025-03-24 21:48:51 247

原创 MySQL 源码|105 - 词法解析:状态转移逻辑(运算符)

等,均不需要在词法解析层处理,在词法解析层,我们只需要关注会构成终结符 Token 的运算符即可。所有基于关键字的运算符(例如。

2025-03-24 21:47:36 533

原创 MySQL 源码|104 - 关键字类型的终结符

MySQL 参考手册:https://dev.mysql.com/doc/refman/8.4/en/keywords.html。除以上字面值外,还包含一个对应两个关键字。

2025-02-25 22:08:33 172

原创 MySQL 源码|103 - 非关键字类型的终结符

【代码】MySQL 源码|103 - 非关键字类型的终结符。

2025-02-24 22:46:55 249

原创 水杉语法解析器|编译器生成 Python 代码原理

编译器用于根据定义的语法规则,自动生成解析逻辑的 Python 代码。

2025-02-06 08:24:47 654

原创 【作品】metasequoia-parser 水杉语法解析器

使用函数创建语法类的构造器,使用构造器的方法添加语义组,在语法定义完成后调用构造器的build方法构造语法类(Grammar使用函数创建语义组,其参数为语义组名称(name)和语义组备选规则的列表(rules使用函数创建备选规则,其参数为符号列表(symbols)和规约函数(actionstart="S",01"),012"),0"),

2025-02-06 08:16:53 215

原创 MySQL 源码|101 - 优化器:分区裁剪

分区裁剪(partition pruning)是指,对于针对分区表的查询,找出在查询过程中不需要访问的分区,即可以假设为空的分区。分区裁剪只受WHERE条件过滤条件和关联条件的影响,不受关联顺序的影响,因此不需要依赖执行计划。MySQL 在中,基于范围分析模块()实现了分区裁剪。

2025-01-30 16:09:08 1014

原创 MySQL 源码|100 - 优化器:条件表达式的优化

子句中的过滤条件进行处理,将嵌套的多层条件表达式中的。推断并移除条件表达式中的始终为假或始终为真的。在传播的过程中,对常量的类型进行优化。进行传播,将常量推广到其他字段和。在 MySQL 中,通过。子句中的关联条件,以及。将条件表达式中等于常量的。,则通过多重等式谓词。|推断并移除恒等式。

2025-01-30 09:08:08 275

原创 099 - 优化器:优化 WHERE、HAVING 和 JOIN 子句中的条件表达式

在 MySQL 中,函数用于优化WHERE子句、HAVING子句中的过滤条件,或JOIN子句中的关联条件。在该函数中,递归地分析条件谓词cond以及关联条件join_list,将转化的多重等式谓词合并到cond_equal中。如果谓词cond恒为真则将cond_value置为COND_TRUE,恒为假则置为COND_FALSE,否则置为COND_OK。其中将等式谓词合并为多重等式谓词等式谓词多重等式谓词多重等式谓词多重等式谓词y = 42当优化WHERE子句和JOIN。

2025-01-29 22:32:33 566

原创 MySQL 源码|98 - 优化器:将多层等式谓词转换为多重等式谓词

被置为真,则计算当前层级谓词数量,即当前层级多重等式谓词的数量与无法合并的谓词数量之和,然后执行 步骤 3 - 步骤 5;,虽然每个表达式需要分别分析,但是它们没有更高层的 MEP 需要继承,也不会存在多个层级。通常来说,在分析过程中我们不会单独留下这些独立等式,而是会将其中的。会才需要继承更高层的 MEP 表达式,令条件表达式中存在多个层级。合并后的 MEP 中,以此类推,不需要继承,不会存在多个层级。时,如果能够被替换则替换,如果不能替换,则保留。|如果当前层级谓词数量为 0,即当前层级的。

2025-01-29 09:08:10 906

原创 MySQL 源码|97 - 优化器:将单个等式谓词转换为多重等式谓词|V20241207

中所有字段类型相同,虽然会导致一些等式谓词无法被消除,但是可以让各个字段对应的常量之间能够共用。如果要放宽这个条件,则会导致每个字段都必须存储它自己的常量,导致实现更加复杂。,因为它不会影响 NULL 和 FALSE 的区别,而且可以使物化后的表更小。|类似的,如果字段和常量分别为字符串类型和时间类型,则不需要将其转换为。中已存在的常量的值是否相同,如果不相同的则会将恒为假的标记(|当等式一侧是字段,另一侧是常量时,将其中的字段项存入。中恒为假的标记已被置为 1,则不会再考虑新添加的常量。

2024-12-07 11:32:02 739

原创 MySQL 源码|96 - 优化器:多重等式谓词(MEP)|V20241204

中存在嵌套关系,显然不方便于计算,在优化过程中,需要将行的每一对元素拆分为一个。优化器需要对谓词进行评估,以决定如何有效地进行查询。,我们可以将每一组等式条件合并到一起,从而方便索引选择和查询。在这些元素中,可以包含若干个字段以及零个或一个常量。的形式,从而使其中隐含的等式条件可以被利用。,表示其中的每个元素之间都是相等的,即等价于。为方便表述,我们在 MySQL 存在的各种。等条件,不便于选择索引和执行查询。在 SQL 的优化过程中,我们将。是的等式两边分别是两行,即。,无法表示出其中隐含的。

2024-12-04 08:30:33 438

原创 MySQL 源码|95 - 优化器:复制 Query_block 的可优化条件|V20241105

Item 是可以被这样处理的。如果是在常规执行(conventional execution)中,则不会创建副本,而是不会复制并返回永久性的子句(permanent clause)。函数复制关联条件,并将复制的关联条件通过调用。中关联表的关联条件,对于每个关联条件。,如果关联条件不为空且不是常规执行语句(条件的一次性副本,并将它们存储到。),且不是常规执行语句()且不是常规执行语句(方法获取其关联条件(

2024-11-05 08:02:26 386 1

原创 MySQL 源码|94 - 优化器:临时表配置对象及字段类型统计|V20241020

在优化器主函数中,多次调用了函数用于统计字段类型的数量,并将其结果记录在用于临时表配置的类型对象中。在调用函数时,提供了类型的临时表配置对象,即。

2024-10-20 11:09:31 832

原创 MySQL 源码|93 - 优化器:使用超图优化器的主要逻辑|V20241016

下面,我们来梳理,相较于不使用超图优化器,当使用超图优化器时优化器的主要逻辑有什么差异。|对这个 SELECT 语句中使用的所有派生表 / 视图执行优化,包括在半连接中的派生表 / 视图【即不使用超图优化器的 Step 6】|创建一个指向求和函数的指针数组,以加速求和函数的计算【即不使用超图优化器的 Step 4】条件,并允许在当前语句的执行过程中随意修改该副本【即不使用超图优化器的 Step 5】参数作为窗口边界,或者作为窗口函数中的偏移量【即不使用超图优化器的 Step 2】

2024-10-16 21:37:35 789

原创 MySQL 源码|92 - 优化器:不使用超图优化器的主要逻辑|V20241016

MySQL 源码|83 - SQL 语句的执行过程|V20240918MySQL 源码|82 - 词法解析和语法解析的入口逻辑|V20240917MySQL 源码|87 - SELECT 语句解析后的执行过程|V20240922。

2024-10-16 08:30:03 503

原创 本地 Github 连接方法(2024.10.12 有效)

下载 “watt toolkit”,地址:https://steampp.net/|选择 “网络加速” 功能。|选择 “Github”

2024-10-12 08:29:10 342

原创 MySQL 源码|91 - 优化器:JOIN 类的 optimize() 函数

函数是进入查询优化阶段的入口,在这个阶段中,会引用逻辑(等价)查询重写(logical (equivalent) query rewrites),基于成本的连接优化(cost-based join optimization)以及基于规则的访问路径选择(rule-based access path selection)来实现优化。一旦找到最优执行计划,则成员函数就会创建 / 初始化所有查询执行所需的结构。函数中,是否使用超图优化器的逻辑差异很大。因此,我们分开梳理是否使用超图优化器的两种场景。

2024-10-11 08:34:38 500

原创 MySQL 源码|90 - 优化器:优化器的主要调用结构|V20241010

来完成对查询语句中使用的所有 full-text 函数的初始化,并且递归地完成查询语句内部的每个查询表达式中的 full-text 函数的初始化。我们之所以较晚地执行这个步骤,是因为我们需要首先确定 full-text 函数是否将用于 full-text 索引的扫描,已经该扫描是否已经排序。子查询的一部分,那么包含当前查询的引擎(engine)可能希望在查询结果至上添加它自己的迭代器,来对当前查询进行物化。特别地,这个逻辑会在优化递归的 CTE 中的 SELECT 表达式时被使用,用于获取非递归。

2024-10-10 08:17:45 992

原创 MySQL 源码|89 - 语法解析(V2):SHOW 语句 Part1 - BINLOG 及主从同步|V20241008

下面我们梳理用于解析SHOW语句,其中涉及的 symbol 及 symbol 之间的关系如下(图中绿色节点为字符串字面值涉及节点、蓝色节点为其他语义组、灰色节点为其他终结符,其中未展示其他使用。

2024-10-08 22:04:41 705

原创 MySQL 源码|88 - DML 优化器:DML 语句的执行过程|V20241008

根据,我们知道在 MySQL 中,DML 的执行逻辑入口为函数,该函数在中被定义,在中被实现。

2024-10-08 08:12:24 978

原创 MySQL 源码|87 - SELECT 语句解析后的执行过程|V20240922

中被实现,在经过检查逻辑后,根据在 Bison 语法解析器中传入的。,此时调用的是第 2 个构造函数,此时其。的子类,其中重写了基类中的虚函数。的子类,并重写了基类中的虚函数。语句的语义组如下,其返回值为。语句为例来具体分析这个过程。

2024-09-22 12:35:01 753

原创 MySQL 源码|86 - 词法解析(V2):词法解析入口逻辑(my_sql_parser_lex)|V20240922

这个函数作为词法解析的入口,连接了词法解析与语法解析的逻辑,理解其具体逻辑对后续理解词法解析、语法解析至关重要。函数解析一个 Token,该函数会解析下一个 Token,将 Token 的语义值和开始、结束位置存储到。该函数的返回值为 Token 的类型,即 Bison 语法解析器的终结符的编码。|如果需要则根据当前 Token 类型和字面值,存储已解析的 Token。中,则返回已提前解析的 Token,其中 Token 的类型来自。:用于根据当前 Token 类型和字面值,存储已解析的 Token。

2024-09-22 11:00:51 977

原创 Shell|GNU Bash 参考手册:3 基础 Shell 特性|V20240922

部分借鉴自通义千问 AI。

2024-09-22 08:18:20 312

原创 Shell|GNU Bash 参考手册:3.8 Shell 脚本|V20240922

部分借鉴自通义千问 AI。

2024-09-22 08:09:33 476

原创 Shell|GNU Bash 参考手册:3.7 执行命令|V20240922

部分借鉴自通义千问 AI。

2024-09-22 08:01:42 1183

原创 Shell|GNU Bash 参考手册:3.6 重定向|V20240921

部分借鉴自通义千问 AI。

2024-09-21 18:24:45 419

原创 Shell|GNU Bash 参考手册:3.5 Shell 扩展|V20240921

部分借鉴自通义千问 AI。

2024-09-21 17:51:53 679

原创 MySQL 源码|85 - 语法解析(V2):语法解析入口逻辑|V20240919

在 MySQL 的 Bison 语法文档中,使用声明了语义组为语法解析的入口。下面我们从入口语义组出发,梳理 MySQL 解析的入口逻辑,其中涉及的 symbol 及 symbol 之间的关系如下(图中绿色节点为字符串字面值涉及节点、蓝色节点为其他语义组、灰色节点为其他终结符;其中。

2024-09-19 22:35:09 1133

原创 Shell|GNU Bash 参考手册:3.4 Shell 参数|V20240919

部分借鉴自通义千问 AI。

2024-09-19 13:08:39 855

原创 MySQL 源码|84 - 语法解析(V2):DDL 的 PARTITION BY 子句|V20240919

下面梳理用于解析子句的。

2024-09-19 08:38:16 1114

原创 MySQL 源码|83 - SQL 语句的执行过程|V20240918

然后,进一步将解析树转换为抽象语法树(AST),以备解析(resolve)之用。):使用提供的解析器状态和对象创建上下文,将一个 SQL 语句转换成一个准备解决的抽象语法树(AST)。使用提供的解析器状态和对象创建上下文,将一个 SQL 语句转换成一个准备解决的抽象语法树(AST)。函数中,不同类型的 SQL 语句有不同的处理方法,但 DQL、DML 等语法均调用了。从文本字符串中解析一个 SQL 命令,并将生成的抽象语法树(AST)传递给查询执行器。是语法解析中各类语句的根节点的基类,其中定义了。

2024-09-18 22:18:46 1120

Kaggle:tmdb-box-office-prediction(转结构化数据,用于 SQL 练习)

原数据源(将其训练集结构化): https://www.kaggle.com/c/tmdb-box-office-prediction/data 数据量级+建表语句(含字段含义注释)详见博客: https://dataartist.blog.csdn.net/article/details/132268426 共 15 个表: - movies:电影表 - belongs_to_collection:电影系列表 - person:人员表(演员与剧组人员) - cast_rela:电影与演员的关联表 - crew_rela:电影与剧组人员的关联表 - genres:电影体裁表 - genres_rela:电影与体裁关联表 - keywords:电影关键词表 - keywords_rela:电影与关键词关联表 - production_companies:电影制作公司表 - production_companies_rela:电影与制作公司关联表 - production_countries:电影制作国家表 ……

2023-08-14

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除