StoneDB开源地址
https://github.com/stoneatom/stonedb
设计:小艾
审核:丁奇、李浩
编辑:宇亭
作者:王若添
中国科学技术大学-软件工程-在读硕士、StoneDB 内核研发实习生
performance_schema 简介
MySQL 启动后会自动创建四个 database
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
其中的 performance schema 用于监控 MySQL server 在一个较低级别的运行过程中的资源消耗、资源等待等情况。它提供了一种在数据库运行时实时检查 server 的内部执行情况的方法,该数据库主要关注数据库运行过程中的性能相关的数据,与更为常见的 information_schema 不同,information_schema 主要关注 server 运行过程中的元数据信息。
performance_schema 中的事件只记录在本地 server 的 performance_schema 中,其表中数据发生变化时不会被写入 binlog 中,也不会通过复制机制被复制到其他 server 中。
表的分类
可以将 performance_schema 库下的表按照监视不同的纬度就行分组。
-
语句事件记录表,这些表记录了语句事件信息
mysql> show tables like '%statement%';
+----------------------------------------------------+
| Tables_in_performance_schema (%statement%) |
+----------------------------------------------------+
| events_statements_current |
| events_statements_histogram_by_digest |
| events_statements_history |
| events_statements_summary_by_digest |
| events_statements_summary_by_host_by_event_name |
| ... |
-
等待事件记录表,与语句事件类型的相关记录表类似
mysql> show tables like '%wait%';
+-----------------------------------------------+
| Tables_in_performance_schema (%wait%) |
+-----------------------------------------------+
| data_lock_waits |
| events_waits_current |
| events_waits_history |
| events_waits_history_long |
| ... |
-
事务事件记录表,记录事务相关的事件的表
mysql> show tables like '%transaction%';
+------------------------------------------------------+
| Tables_in_performance_schema (%transaction%) |
+------------------------------------------------------+
| binary_log_transaction_compression_stats |
| events_transactions_current |
| events_transactions_history |
| ... |
使用场景
对于语句事件记录表中的 events_statements_summary_by_digest 表举例,这个表记录了基于 SQL 语句摘要的统计信息。如果我们想要了解该 stonedb 进程上执行过的所有类型 SQL 的频次,我们可以使用 SELECT DIGEST_TEXT,COUNT_STAR FROM events_statements_summary_by_digest 查询该表,其中
-
DIGEST_TEXT: 这个列是 SQL 语句的标准化版本,即删除了 SQL 语句中的特定数据(例如,具体的值、表名、列名等)后的 SQL 语句。所有逻辑上相同的 SQL 语句(即使具体的值不同)都会有相同的 DIGEST_TEXT。这使得我们可以统计和分析相同逻辑 SQL 语句的执行情况。
-
COUNT_STAR: 这个列是每个 SQL 语句摘要的执行次数。这可以帮助我们识别哪些 SQL 语句被执行的次数最多,可能对系统的性能影响最大。
这个查询返回的结果就是每种 SQL 语句的标准化版本及其执行次数。这可以帮助我们理解哪些类型的 SQL 语句最常被执行,进而可以对这些 SQL 语句进行优化以提高系统的性能。
创建新的元数据表
如果我们希望在 performance_schema 库中新增加一个描述列式二级引擎列相关信息的元数据表 mock_columns,用来描述加载到 mock_columns 的列式数据情况,比如被加载到了 mock 引擎中的列名列号,所属表名,ndv(number of disctinct value)等信息。
以 t1 表为例
create table t1 (c1 int PRIMAEY_KEY);
// 安装二级引擎mock的动态链接库
INSTALL PLUGIN mock SONAME "ha_mock.so";
// 指定t1的二级引擎为mock
ALTER TABLE t1 SECONDARY_ENGINE=ha_mock;
执行下面的 sql 可以将 innodb 中数据 load 到二级引擎 mock 中
ALTER TABLE t1 SECONDARY_LOAD;
在代码层面,我们需要在加载 innodb 表到 mock 引擎(sql_table.cc 中的 secondary_engine_load_table 函数)的同时将各列的元数据信息存起来,比如可以存在一个全局的 meta_column_columns 映射表中,以便之后执行器在查询中可以读到这些列信息。
函数调用栈如下图:
查询元数据表
将 t1 表加载到 mock 引擎中后,我们就可以执行 SELECT * FROM mock_columns 进行查询。
代码实现上简单来说我们需要新建一个类 table_mock_columns 实现 PFS_engine_table 这个抽象类,在深入细节之前,先了解下 MySQL 中存储引擎 handler 接口的基本概念:
MySQL 架构可分为 SQL 层和存储引擎层,而且支持插件式存储引擎,不同的存储引擎只需实现 handler 这个抽象类包含的方法即可作为 MySQL 的引擎进行数据存取,常见的存储引擎有 innodb、myisam 等(上文提到的 mock 引擎也是一种存储引擎)。而负责 MySQL 元数据信息的引擎是 perfschema 引擎。显然 ha_perfschema 需要继承 handler 抽象类,ha_perfschema 类主要的成员变量 PFS_engine_table *m_table,performance_schema 中所有的 table 类都需要继承该抽象类(也可以理解该类的一个主要作用是充当读取记录的游标,详细信息见后文)。
PFS_engine_table 的初始化
PFS_engine_table 中的存在一个类型为 PFS_engine_table_share *的成员变量 m_table_share,
其数据被所有打开该表的句柄共享的。其中包含一些回调函数,如打开表 m_open_table,写操作 m_write_row 和删除所有行 m_delete_all_rows 等。
还包含一个 Plugin_table 类型的代表表定义的变量 m_table_def(类似于 CREATE TABLE 类型 SQL 的形式,包括表名,列名及列类型等信息)。我们需要做的就是在创建 PFS_engine_table 类型的 column 表时填充这些变量和函数。如定义表 mock_columns 的表结构:
Plugin_table table_mock_columns::s_table_def(/* Schema name */"performance_schema",/* Name */"mock_columns",/* Definition */" TABLE_ID int unsigned NOT NULL,\\n"" TABLE_NAME VARCHAR(64) NOT NULL,\\n"" COLUMN_ID int unsigned NOT NULL,\\n"" NDV bigint unsigned NOT NULL,\\n"" ENCODING varchar(64) DEFAULT NULL,\\n"/* Options */" ENGINE=PERFORMANCE_SCHEMA CHARACTER SET utf8mb4 COLLATE utf8mb4_bin",/* Tablespace */nullptr);
)
实现相关虚函数
PFS_engine_table 中主要的虚函数有以下三个(暂时不关注索引相关的读取函数):
int rnd_init(bool scan)
int rnd_next(void)
int read_row_values(TABLE *table, unsigned char *buf, Field **fields, bool read_all)
如果我们希望在 performance_schema 库下新增一张元数据表,需要重载以上三个方法,rnd_init 函数做一些初始化工作,rnd_next 函数从全局映射表 meta_column_columns 中将下一条记录取到 m_table 游标中,read_row_values 函数负责将 m_table 游标中存储的数据读出并返回。
查询该表时候,MySQL 执行器中的函数调用链如下 (参数已省略):TableScanIterator::Read()→handler::ha_rnd_next()→ha_perfschema::rnd_next()→table_mock_columns::rnd_next(), 执行后会将下一条记录取出到 m_table 游标中暂存,然后 ha_perfschema::rnd_next()会调用 read_row_values()函数, 将 m_table 中的一行数据读出填充到 Field 列表字段查询结束。
最后的查询结果如下:
mysql> SELECT * FROM `mock_columns`;
+----------+------------+------------+-----+------------+
| TABLE_ID | TABLE_NAME | COLUMN_ID | NDV | ENCODING |
+----------+------------+------------------+------------+
| 87 | t1 | 0 | 0 | dictionary |
+----------+------------+------------------+------------+
1 row in set (4.68 sec)
删除元数据表
performance_schema 中的表是不进行持久化的,这些表主要用来收集和存储 MySQL 服务器的实时性能数据,以便于用户进行性能分析和问题诊断。这些数据存储在内存中,并且在 MySQL 服务器重启后会被清空。这种设计是有意为之的,因为 performance_schema 中的数据主要用于实时性能分析,而不是长期存储。如果需要长期保留这些数据,我们需要自己定期收集并存储这些数据。
用户也可以执行如下 SQL 将从 innodb 主引擎中加载到二级引擎 mock 的表卸手动载掉:
ALTER TABLE t1 SECONDARY_UNLOAD;
执行表卸载的时候需要自动把加载到二级引擎 mock 上的表中对应的列信息删除掉,对应到源码层面就是当用户执行该 SQL 时,mock 引擎将之前加载到 meta_mock_columns 映射表中需要被卸载表的数据清除掉。
结束语
经过对 performance_schema 相关表的介绍和源码探索,我们已对如何在 performance_schema 库中创建一张我们需要的元数据表有了较为详细的理解。希望这篇分析能为您在深入研究或进行二次开发时提供有益的参考。
❝本文基于 MySQL 8.0.33 源码进行分析
❞
StoneDB 介绍
StoneDB 是石原子科技自主设计研发的国内首款完全兼容于 MySQL 生态的开源 一体化实时 HTAP 数据库产品,具备行列混存、智能索引等核心特性,为 MySQL 数据库提供在线数据实时就近分析服务,能够高效解决 MySQL 数据库在分析型应用场景中面临的能力问题。同时,StoneDB 使用多存储引擎架构的设计,事务引擎具有数据强一致特性,具备完整的事务并发处理能力,使得 StoneDB 可以替代 MySQL 数据库满足在线事务处理场景的需求,使用 MySQL 的用户,通过 StoneDB 可以实现 TP+AP 混合负载,分析性能提升 10 倍以上显著提升,不需要进行数据迁移,也无需与其他 AP 集成,弥补 MySQL 分析领域的空白。
开源仓库
https://github.com/stoneatom/stonedb