PolarDB-X 存储引擎组件 GalaxyEngine 开源技术解读

 

PolarDB-X 是由阿里巴巴自主研发的云原生分布式数据库，融合了分布式 SQL 引擎 GalaxySQL 和分布式存储引擎 GalaxyEngine，其中 GalaxyEngine 是新一代面向分布式场景的 MySQL 发行版本，作为官方 MySQL 版本的一个分支，除了吸收和跟进官方版本的持续改进以外，尤其在分布式场景下，实现了 Lizard 分布式事务和全局一致性解决方案、 Galaxy X-Protocol 交互协议 pipeline request、 X-Engine 存储引擎、 Galaxy X-Paxos Cluster 保证数据零丢失并持续可用，以及共享的 RDS MySQL 内核企业级功能等，GalaxyEngine 遵循 GPLv2 License，希望通过开源，回馈社区，共建 MySQL 生态繁荣。

 

GalaxyEngine 开源的技术细节：

 

1. Lizard 分布式事务和全局一致性解决方案

1.1 问题背景

Lizard 事务系统主要解决 GalaxyEngine 的两个重要问题：

扩展性问题

在单机多核的场景下，MySQL InnoDB 的事务系统作为一个内存结构，存在严重的 Write Transaction 和 Read Query 的干扰，无法高效使用多核能力，Lizard SCN 单机事务系统，解绑读写之间对事务系统的争抢，能够在OLTP Read-Write 的真实业务场景满载多核能力。

分布式事务原子性和一致性问题

在多节点集群的场景下，由于数据分片，一个业务场景会有多个节点参与，单机事务无法保证多个节点参与的事务 Atomicity 以及查询的一致性，Lizard GCN 分布式事务系统，提供了一整套的解决方案来满足。

1.2 Lizard SCN 单机事务系统
 

MySQL InnoDB 事务系统

MySQL InnoDB 事务系统和 MVCC 主要包括三个主要结构: 活跃事务链表 Active Trx，查询事务 Read View，行记录 Record。

其多版本 MVCC 实现简略如下：
1.从 Active Trx 拷贝一个 Read View；

2.检索行记录，根据 TID 到 Read View 中进行二分查找，判断可见性。

Lizard SCN 事务系统

Lizard SCN 事务系统，使用 System Commit Number 来代替 Trx ID 进行多版本可见性判断，并使用 Transaction Slot 来保存事务的相关信息。

其写事务实现简略如下：
1.Begin 的时候，在 Transaction Table 中申请一个 Slot，其地址用 UBA 表示；
2.Insert 的时候，在行记录上新增 UBA 和 SCN 两个字段；
3.Commit 的时候，从 SCN 生成器生成一个 number，填写到 Slot 中。

其 MVCC 实现如下：
1.Query 申请一个当前 SCN 作为 Read View；
2.检索行记录的时候，根据行记录 SCN 和 Read View 比较数字大小，判断可见性。

Delayed Record Cleanout

Lizard SCN 事务系统，除了在 Commit 的时候，做少量的 Commit Cleanout，即行记录上回填 SCN，大部分的行记录 SCN 回填，都是 Delayed Record Cleanout，即在读取行记录上 SCN 时，发现是 NULL 值，就根据 UBA 地址查询 transaction slot 找到需要回填的 SCN，并做压力和负载的自动化优化。

Flashback Query

Lizard SCN 事务系统原生支持 Flashback query，其语法如下：

SELECT ... FROM tablename
  AS OF [SCN | TIMESTAMP] expr;

 

Lizard SCN 事务系统支持使用参数 INNODB_UNDO_RETENTION = number [seconds] 来定义支持多久的历史查询，时间越长，其占用的 UNDO 表空间也会相应的增加，例如：

mysql> SELECT * FROM tab AS OF TIMESTAMP '2020-12-17 16:40:40';
+----+---------+---------------------+
| id | version | gmt_modify |
+----+---------+---------------------+
| 1 |       1 | 2020-12-17 16:40:38 |
| 2 |       1 | 2020-12-17 16:40:39 |
+----+---------+---------------------+

mysql> SELECT * FROM tab AS OF TIMESTAMP '2020-12-17 16:40:55';
+----+---------+---------------------+
| id | version | gmt_modify |
+----+---------+---------------------+
| 1 |       2 | 2020-12-17 16:40:54 |
| 2 |       2 | 2020-12-17 16:40:54 |
+----+---------+---------------------+

 

Lizard SCN 性能表现

在高并发和多核的真实 OLTP Read-Write 场景下，Lizard SCN 能很好的满载多核的能力，突破事务系统的瓶颈。

1.3 Lizard GCN 分布式事务系统

两阶段提交

Lizard GCN 分布式事务系统建立在 SCN 事务系统的基础上，对 Transaction Slot 进行了扩充，允许接受外部提交号，即 Global Commit Number，并进行持久化，为了保证分布式事务的原子性，这里引用 MySQL XA 的两阶段提交来完成分布式事务：

SET SESSION innodb_commit_seq = [GCN];
XA START xid

......

XA COMMIT xid;

 

或者

XA START xid;

......

XA COMMIT xid $GCN;

全局一致性

Lizard GCN 使用 GCN 作为 Read View 进行全局一致性的判断：
1.Query 从 TSO 获取一个当前 GCN；
2.检索记录，并根据 GCN 数字大小比较进行可见性比较。

其支持两种语法：

SET SESSION innodb_snapshot_seq = [GCN]

 

或者

SELECT ... FROM tablename
  AS OF GCN expr;

TSO 解决方案

PolarDB-X 采用了 TSO 的架构方案，为此 GalaxyEngine 提供了一个方便快捷的生成全局版本号的机制，即 Sequence Engine，Sequence Engine 采用了兼容商业数据库语法，并使用 InnoDB 存储引擎作为持久化方法。

GalaxyEngine Sequence 支持两种格式的 SEQUENCE,  即 NUMBER SEQUENCE 和 TIMESTAMP SEQUENCE, 使用分别如下：

1.NUMBER SEQUENCE

CREATE SEQUENCE [IF NOT EXISTS] schema.sequence_name
   [START WITH <constant>]
   [MINVALUE <constant>]
   [MAXVALUE <constant>]
   [INCREMENT BY <constant>]
   [CACHE <constant> | NOCACHE]
   [CYCLE | NOCYCLE]
  ;

1. SELECT [nextval | currval]
      FROM seq;
 
 2. SELECT [nextval(seq) | currval(seq)];
 
 3. SELECT [seq.currval | seq.nextval]
      FROM dual;

 

NUMBER SEQUENCE 生成一个单调唯一的数字；

2.TIMESTAMP SEQUENCE

CREATE SEQUENCE [IF NOT EXISTS] schema.sequence_name
   [CACHE <constant> | NOCACHE]
   TIMESTEAMP;

其生成的格式如下：
[TIMESTAMP 42 bits + SEQUENCE 16 bits + UNUSED 6 bits]
分别是：42个 bit 的时间戳，16个 bit 的数字，另外还有预留的6个 bit。

XA 事务完整性

MySQL XA 实现了一套两阶段提交协议，以便在分布式事务系统中使用，但原生的 MySQL XA 存在完整性问题，假如在分布式场景中，Node1, Node2 ... NodeN 作为节点参与方，XA 使用 Two-Phase Commit Protocol  (2PC) 保证分布式事务的原子性，但对于每个节点中的 Binlog Storage 和 InnoDB Storage 两个参与方，MySQL 目前没有机制保证在每个阶段(Prepare 或者 Commit) 不同 Storage 参与方之间的一致性，这也源于Binlog Storage 本身没有 UNDO 的机制保证有关，这样 2PC 的崩溃恢复协议也就无法获得有效的节点事务状态，GalaxyEngine 除了使用两阶段提交协议的 External Coordinator 以外，引入了使用 GTID 补偿协议的 Internal Coordinator 来保证 Storage 之间的一致性。

GTID 补偿协议的主要工作原理：
1.在单个节点崩溃恢复阶段，根据 Binlog File 构建 Binlog GTID 集合；
2.在单个节点崩溃恢复阶段，根据 InnoDB GTID_EXECUTED 以及 TRANSACTION UNDO HISTORY 构建 InnoDB GTID 集合；
3.构建集合的差集，使用 Binlog Event 进行补偿 InnoDB 丢失的事务，恢复单个节点；
4.完成单个节点的补偿后，XA 组件开始分布式集群的两阶段提交事务的崩溃恢复。

2. Galaxy X-protocol 交互协议

MySQL 原生 Client/Server Protocol 使用停等的方式进行交互，以及 one-thread-per-connection 的线程处理模型，极大的影响了资源利用率，Galaxy X-protocol 在 MySQL X Protocol 的基础上，重新定义了消息格式，并分离了 CONNECTION<->SESSION<->THREAD  三者，实现请求的 Pipeline，最大化提升吞吐能力。

消息格式

Galaxy X-protocol 消息格式：
===========================
 4 bytes Session ID
 1 bytes Protocol Version
 4 bytes Message Length
 1 bytes Message Type
 x bytes Payload
===========================

消息处理模型

消息通过使用 google protobuf 进行传递，消息处理模型如下：

多个 Client 可以共用 connection 的 TCP 网络通道，提高网络通道的利用率， 根据请求的 message 的 session id 进行消息分发，然后放置到任务队列中，由后台线程池模块进行处理，这样就形成了高效的处理方式。

3. X-Engine 存储引擎

X-Engine是阿里数据库产品事业部自研的OLTP数据库存储引擎，作为自研数据库POLARDB X的存储引擎，已经广泛应用在阿里集团内部诸多业务系统中，其中包括交易历史库，钉钉历史库等核心应用，为业务大幅缩减了成本。

X-Engine 整体架构

X-Engine使用了LSM作为基础架构，目标是作为一个通用的高性能低成本存储引擎，追求读写性能更为均衡，因此在其上做了大量工程优化，主要围绕几个方向进行：
1. 利用LSM-tree先天优势，提升了系统写性能天花板。
2. 优化LSM-tree的compaction操作，以降低对系统性能的冲击，使得系统性能表现趋于平稳。
3. 利用持久化数据层只读特点，发挥压缩优势降低成本。
4. 利用天然分层结构，结合硬件能力使用冷热分层结构，降低综合成本。
5. 利用精细化访问机制和缓存技术，弥补LSM-tree读性能短板。

X-Engine 使用方法

X-Engine 是 MySQL 的一个存储引擎，在 MySQL 体系中的位置与 InnoDB 类似，因此使用 X-Engine 只需要在引擎初始化及启动开启 X-Engine 参数，同时在建表时指定 engine 类型为 xengine 即可。

建表语法

CREATE TABLE t1 (
  c1 int PRIMARY KEY,
  c2 int
) ENGINE = xengine;

 

X-Engine 性能水准

RDS X-Engine在保证3~5倍的空间压缩的前提下，保证了与InnoDB相近的性能水准。测试报告详见RDS MySQL 文档官网(X-Engine性能测试：https://help.aliyun.com/document_detail/163250.html?spm=a2c6h.12873639.0.0.56594c1eJOhOJu）

4. RDS MySQL 企业级功能

RDS MySQL 是阿里云在云上提供的 MySQL 云数据库产品，并在内核上定制了企业级功能，同时也作为GalaxyEngine 的基础功能，并进行开源。

4.1 Purge Large Table Asynchronously

使用 InnoDB 存储引擎时，直接删除大表或者大文件会导致文件系统层面出现严重的稳定性问题，为了避免这个问题，GalaxyEngine 会启动一个后台线程来异步清理数据文件。当删除单个表空间时，会将对应的数据文件先重命名为临时文件，并使用 DDL LOG 保证 crash safe，然后清除线程将异步、缓慢地清理文件。

使用如下参数来配置此功能：

使用如下查询查看 Purge 进度：

mysql> select * from information_schema.innodb_purge_files;
+--------+---------------------+--------------------+---------------+-------------------------+--------------+
| log_id | start_time | original_path | original_size | temporary_path | current_size |
+--------+---------------------+--------------------+---------------+-------------------------+--------------+
|      0 | 2021-05-14 14:40:01 | ./file_purge/t.ibd | 146800640 | ./#FP_210514 14:40:01_9 | 79691776 |
+--------+---------------------+--------------------+---------------+-------------------------+--------------+
1 row in set (0.20 sec)

4.2 Recycle Bin

由于 MySQL DDL 语句无法回滚，开发或运维人员如果误操作（例如 DROP/TRUNCATE TABLE）可能会导致数据丢失。Recycle Bin 功能，临时将删除的表转移到回收站，还可以设置保留的时间，方便找回数据，同时提供了工具包（DBMS_RECYCLE）便于快捷使用。

Recycle Bin 机制介绍

1.回收机制：
执行 DROP TABLE/DATABASE 语句时，只保留相关的表对象，并移动到专门的 recycle bin 目录中。其它对象的删除策略如下：

• 如果是与表无关的对象，根据操作语句决定是否保留，不做回收。
• 如果是表的附属对象，可能会修改表数据的，做删除处理，例如 Trigger 和 Foreign key。但 Column statistics 不做清理，随表进入回收站。

执行TRUNCATE TABLE语句时，将原始表移动到专门的recycle bin目录中，并在原位置使用相同的结构创建新表。

2.清理机制：
回收站会启动一个后台线程，来异步清理超过 recycle_bin_retention 时间的表对象。在清理回收站表的时候，如果遇到大表，会再启动一个后台线程异步删除大表。

3.权限机制：
RDS MySQL实例启动时，会初始化一个名为__recycle_bin__的数据库，作为回收站使用的专有数据库。__recycle_bin__ 是系统级数据库，您无法直接进行修改和删除。对于回收站内的表，虽然您无法直接执行drop table语句，但是可以使用call dbms_recycle.purge_table('<TABLE>');进行清理。

另外账号需要在原表和回收站表都需要具有DROP权限。

4.命名机制：
Recycle Bin会从不同的数据库回收到统一的__recycle_bin__数据库中，所以需要保证目标表表名唯一，所以定义了如下命名格式：

"__" + <Storage Engine> + <SE private id>

Recycle Bin 相关参数

Recycle Bin 接口设计

-- Purge Table
dbms_recycle.purge_table('<TABLE>');

-- Restore table
dbms_recycle.restore_table('<RECYCLE_TABLE>','<DEST_DB>','<DEST_TABLE>');

-- Show tables

mysql> call dbms_recycle.show_tables();
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| SCHEMA          | TABLE         | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME       | PURGE_TIME          |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| __recycle_bin__ | __innodb_1063 | product_db    | t1           | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1064 | product_db    | t2           | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1065 | product_db    | parent       | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1066 | product_db    | child        | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
4 rows in set (0.00 sec)

4.3 Returning

GalaxyEngine 提供 returning 功能，支持 DML 语句返回 Resultset，同时提供了工具包（DBMS_TRANS）便于您快捷使用。

Returning 语法：

DBMS_TRANS.returning(<Field_list>,<Statement>);

例如：

mysql> call dbms_trans.returning("*", "insert into t(id) values(NULL),(NULL)");
+----+------+---------------------+
| id | col1 | col2 |
+----+------+---------------------+
| 1 |    1 | 2019-09-03 10:39:05 |
| 2 |    1 | 2019-09-03 10:39:05 |
+----+------+---------------------+
2 rows in set (0.01 sec)

mysql> call dbms_trans.returning("id, col1, col2", "update t set col1 = 2 where id >2");
+----+------+---------------------+
| id | col1 | col2 |
+----+------+---------------------+
| 3 |    2 | 2019-09-03 10:41:06 |
| 4 |    2 | 2019-09-03 10:41:06 |
+----+------+---------------------+
2 rows in set (0.01 sec)

mysql> call dbms_trans.returning("id, col1, col2", "delete from t where id < 3");
+----+------+---------------------+
| id | col1 | col2 |
+----+------+---------------------+
| 1 |    1 | 2019-09-03 10:40:55 |
| 2 |    1 | 2019-09-03 10:40:55 |
+----+------+---------------------+
2 rows in set (0.00 sec)

 

4.4 Statement Concurrency Control

为了应对突发的数据库请求流量、资源消耗过高的语句访问以及SQL访问模型的变化， 保证实例持续稳定运行，GalaxyEngine 提供基于语句规则的并发控制 CCL（Concurrency Control），并提供了工具包（DBMS_CCL）便于您快捷使用。

功能设计

CCL规则定义了如下三个维度的特征：

• SQL command: SQL命令类型，例如SELECT、UPDATE、INSERT、DELETE等。
• Object: SQL命令操作的对象，例如TABLE、VIEW等。
• keywords: SQL命令的关键字。

规则持久化存储在系统表 mysql.concurrency_control.

接口设计

-- Add Rule
dbms_ccl.add_ccl_rule('<Type>','<Schema_name>','<Table_name>',<Concurrency_count>,'<Keywords>');

-- Delete Rule
dbms_ccl.del_ccl_rule(<Id>);

-- Show Rule
dbms_ccl.show_ccl_rule();

-- Flush Rule
dbms_ccl.flush_ccl_rule();

 

4.5 Statement Outline

生产环境中，SQL语句的执行计划经常会发生改变，导致数据库不稳定。GalaxyStore 利用 Optimizer Hint 和Index Hint 让 MySQL 稳定执行计划，该方法称为 Statement Outline，并提供了工具包（DBMS_OUTLN）便于快捷使用。

功能设计

 

Statement Outline支持官方MySQL 8.0 的所有 hint 类型，分为如下两类：

• Optimizer Hint 根据作用域和 hint 对象，分为 Global level hint、Table/Index level hint、Join order hint等。
• Index Hint 根据 Index Hint 的类型和范围进行分类。

增加的 outline 持久化存储在 mysql.outline 表中。

接口设计

-- Add optimizer Outline
dbms_outln.add_optimizer_outline('<Schema_name>','<Digest>','<query_block>','<hint>','<query>');


-- Add Index Outline
dbms_outln.add_index_outline('<Schema_name>','<Digest>',<Position>,'<Type>','<Hint>','<Scope>','<Query>');


-- Delete Outline
dbms_outln.del_outline(<Id>);


-- Show Outline

mysql> call dbms_outln.show_outline();
+------+------------+------------------------------------------------------------------+-----------+-------+------+-------------------------------------------------------+------+----------+-------------------------------------------------------------------------------------+
| ID | SCHEMA | DIGEST | TYPE | SCOPE | POS | HINT | HIT | OVERFLOW | DIGEST_TEXT |
+------+------------+------------------------------------------------------------------+-----------+-------+------+-------------------------------------------------------+------+----------+-------------------------------------------------------------------------------------+
| 33 | outline_db | 36bebc61fce7e32b93926aec3fdd790dad5d895107e2d8d3848d1c60b74bcde6 | OPTIMIZER | | 1 | /*+ SET_VAR(foreign_key_checks=OFF) */                | 1 | 0 | SELECT * FROM `t1` WHERE `id` = ? |
| 32 | outline_db | 36bebc61fce7e32b93926aec3fdd790dad5d895107e2d8d3848d1c60b74bcde6 | OPTIMIZER | | 1 | /*+ MAX_EXECUTION_TIME(1000) */                       | 2 | 0 | SELECT * FROM `t1` WHERE `id` = ? |
| 34 | outline_db | d4dcef634a4a664518e5fb8a21c6ce9b79fccb44b773e86431eb67840975b649 | OPTIMIZER | | 1 | /*+ BNL(t1,t2) */                                     | 1 | 0 | SELECT `t1` . `id` , `t2` . `id` FROM `t1` , `t2`                                   |
| 35 | outline_db | 5a726a609b6fbfb76bb8f9d2a24af913a2b9d07f015f2ee1f6f2d12dfad72e6f | OPTIMIZER | | 2 | /*+ QB_NAME(subq1) */                                | 2 | 0 | SELECT * FROM `t1` WHERE `t1` . `col1` IN ( SELECT `col1` FROM `t2` ) |
| 36 | outline_db | 5a726a609b6fbfb76bb8f9d2a24af913a2b9d07f015f2ee1f6f2d12dfad72e6f | OPTIMIZER | | 1 | /*+ SEMIJOIN(@subq1 MATERIALIZATION, DUPSWEEDOUT) */  | 2 | 0 | SELECT * FROM `t1` WHERE `t1` . `col1` IN ( SELECT `col1` FROM `t2` ) |
| 30 | outline_db | b4369611be7ab2d27c85897632576a04bc08f50b928a1d735b62d0a140628c4c | USE INDEX | | 1 | ind_1 | 3 | 0 | SELECT * FROM `t1` WHERE `t1` . `col1` = ? AND `t1` . `col2` = ? |
| 31 | outline_db | 33c71541754093f78a1f2108795cfb45f8b15ec5d6bff76884f4461fb7f33419 | USE INDEX | | 2 | ind_2 | 1 | 0 | SELECT * FROM `t1` , `t2` WHERE `t1` . `col1` = `t2` . `col1` AND `t2` . `col2` = ? |
+------+------------+------------------------------------------------------------------+-----------+-------+------+-------------------------------------------------------+------+----------+-------------------------------------------------------------------------------------+
7 rows in set (0.00 sec)

4.6 Performance Insight

Performance Insight 是专注于实例负载监控、关联分析、性能调优的利器，帮助您迅速评估数据库负载，找到性能问题的源头，提升数据库的稳定性。

Performance Insight 介绍

 

Performance Insight由如下两部分组成：

 

• Object statisticsObject statistics查询表和索引的统计信息，包括如下两个表：
  TABLE_STATISTICS：记录读取和修改的行。
  INDEX_STATISTICS：记录索引的读取行。

 

• Performance pointPerformance point 提供实例的详细性能信息，方便您更快更准确地量化SQL的开销。Performance point包括如下三个维度：
  CPU：包括执行任务的总时间（Elapsed time）、CPU执行任务的时间（CPU time）等。
  LOCK：包括服务器MDL锁时间、存储事务锁时间、互斥冲突（仅调试模式）、读写锁冲突等。
  IO：数据文件读写时间、日志文件写入时间、逻辑读取、物理读取、物理异步读取等。

Object statistics 使用方法

 

确认参数 OPT_TABLESTAT 和 OPT_INDEXSTAT 的值为 ON。示例如下：

mysql> show variables like "opt_%_stat";
  +---------------+-------+
  | Variable_name | Value |
  +---------------+-------+
  | opt_indexstat | ON |
  | opt_tablestat | ON |
  +---------------+-------+

mysql> select * from TABLE_STATISTICS limit 10;
  +--------------+--------------+-----------+--------------+------------------------+---------------+--------------+--------------+
  | TABLE_SCHEMA | TABLE_NAME | ROWS_READ | ROWS_CHANGED | ROWS_CHANGED_X_INDEXES | ROWS_INSERTED | ROWS_DELETED | ROWS_UPDATED |
  +--------------+--------------+-----------+--------------+------------------------+---------------+--------------+--------------+
  | mysql | db |         2 | 0 |                      0 | 0 |            0 | 0 |
  | mysql | engine_cost | 2 |            0 | 0 |             0 | 0 |            0 |
  | mysql | proxies_priv |         1 | 0 |                      0 | 0 |            0 | 0 |
  | mysql | server_cost | 6 |            0 | 0 |             0 | 0 |            0 |
  | mysql | tables_priv |         2 | 0 |                      0 | 0 |            0 | 0 |
  | mysql | user | 7 |            0 | 0 |             0 | 0 |            0 |
  | test | sbtest1 |      1686 | 142 |                    184 | 112 |           12 | 18 |
  | test | sbtest10     | 1806 |          125 | 150 |           105 | 5 |           15 |
  | test | sbtest100 |      1623 | 141 |                    182 | 110 |           10 | 21 |
  | test | sbtest11 | 1254 |          136 | 172 |           110 | 10 |           16 |
  +--------------+--------------+-----------+--------------+------------------------+---------------+--------------+--------------+

  mysql> select * from INDEX_STATISTICS limit 10;
  +--------------+--------------+------------+-----------+
  | TABLE_SCHEMA | TABLE_NAME | INDEX_NAME | ROWS_READ |
  +--------------+--------------+------------+-----------+
  | mysql | db | PRIMARY |         2 |
  | mysql | engine_cost | PRIMARY | 2 |
  | mysql | proxies_priv | PRIMARY |         1 |
  | mysql | server_cost | PRIMARY | 6 |
  | mysql | tables_priv | PRIMARY |         2 |
  | mysql | user | PRIMARY | 7 |
  | test | sbtest1 | PRIMARY |      2500 |
  | test | sbtest10 | PRIMARY | 3007 |
  | test | sbtest100    | PRIMARY |      2642 |
  | test | sbtest11 | PRIMARY | 2091 |
  +--------------+--------------+------------+-----------+

Performance point 使用方法

Performance point 的相关参数

mysql> show variables like "%performance_point%";
  +---------------------------------------+-------+
  | Variable_name | Value |
  +---------------------------------------+-------+
  | performance_point_dbug_enabled | OFF |
  | performance_point_enabled | ON |
  | performance_point_iostat_interval | 2 |
  | performance_point_iostat_volume_size | 10000 |
  | performance_point_lock_rwlock_enabled | ON |
  +---------------------------------------+-------+

在 performance_schema 数据库查询 events_statements_summary_by_digest_supplement 表

mysql> select * from events_statements_summary_by_digest_supplement limit 10;
  +--------------------+----------------------------------+-------------------------------------------+--------------+
  | SCHEMA_NAME | DIGEST | DIGEST_TEXT | ELAPSED_TIME | ......
  +--------------------+----------------------------------+-------------------------------------------+--------------+
  | NULL | 6b787dd1f9c6f6c5033120760a1a82de | SELECT @@`version_comment` LIMIT ? | 932 |
  | NULL | 2fb4341654df6995113d998c52e5abc9 | SHOW SCHEMAS |         2363 |
  | NULL | 8a93e76a7846384621567fb4daa1bf95 | SHOW VARIABLES LIKE ? | 17933 |
  | NULL | dd148234ac7a20cb5aee7720fb44b7ea | SELECT SCHEMA ( ) |         1006 |
  | information_schema | 2fb4341654df6995113d998c52e5abc9 | SHOW SCHEMAS | 2156 |
  | information_schema | 74af182f3a2bd265678d3dadb53e08da | SHOW TABLES |         3161 |
  | information_schema | d3a66515192fcb100aaef6f8b6e45603 | SELECT * FROM `TABLE_STATISTICS` LIMIT ? | 2081 |
  | information_schema | b3726b7c4c4db4b309de2dbc45ff52af | SELECT * FROM `INDEX_STATISTICS` LIMIT ? |         2384 |
  | information_schema | dd148234ac7a20cb5aee7720fb44b7ea | SELECT SCHEMA ( ) | 129 |
  | test | 2fb4341654df6995113d998c52e5abc9 | SHOW SCHEMAS |          342 |
  +--------------------+----------------------------------+-------------------------------------------+--------------+

 

注：需要同步打开 performance schema。

GalaxyEngine 后续还有更多更广泛的开源和文档支持计划，敬请关注。
GalaxyEngine 开源地址: https://github.com/ApsaraDB/galaxyengine

 

文章转自公众号：阿里云数据库