天天看點
傳回

GalaxyEngine Overview

簡介

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 中進行二分查找，判斷可見性
GalaxyEngine Overview

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 比較數字大小，判斷可見性。
GalaxyEngine Overview

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 能很好的滿載多核的能力，突破事務系統的瓶頸。

GalaxyEngine Overview

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;
GalaxyEngine Overview

全局一緻性

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, 使用分别如下：

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 生成一個單調唯一的數字；

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 之間的一緻性。

GalaxyEngine Overview

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 進行傳遞，消息處理模型如下：

GalaxyEngine Overview

多個 Client 可以共用 connection 的 TCP 網絡通道，提高網絡通道的使用率， 根據請求的 message 的 session id 進行消息分發，然後放置到任務隊列中，由背景線程池子產品進行處理，這樣就形成了高效的處理方式。

3. X-Engine 存儲引擎

X-Engine是阿裡資料庫産品事業部自研的OLTP資料庫存儲引擎，作為自研資料庫POLARDB X的存儲引擎，已經廣泛應用在阿裡集團内部諸多業務系統中，其中包括交易曆史庫，釘釘曆史庫等核心應用，為業務大幅縮減了成本。

X-Engine 整體架構

X-Engine使用了LSM作為基礎架構，目标是作為一個通用的高性能低成本存儲引擎，追求讀寫性能更為均衡，是以在其上做了大量工程優化，主要圍繞幾個方向進行：

    1. 利用LSM-tree先天優勢，提升了系統寫性能天花闆。
    1. 優化LSM-tree的compaction操作，以降低對系統性能的沖擊，使得系統性能表現趨于平穩。
    1. 利用持久化資料層隻讀特點，發揮壓縮優勢降低成本。
    1. 利用天然分層結構，結合硬體能力使用冷熱分層結構，降低綜合成本。
    1. 利用精細化通路機制和緩存技術，彌補LSM-tree讀性能短闆。
GalaxyEngine Overview

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性能測試

）

GalaxyEngine Overview

4. RDS MySQL 企業級功能

RDS MySQL 是阿裡雲在雲上提供的 MySQL 雲資料庫産品，并在核心上定制了企業級功能，同時也作為GalaxyEngine 的基礎功能，并進行開源。

4.1 Purge Large Table Asynchronously

使用 InnoDB 存儲引擎時，直接删除大表或者大檔案會導緻檔案系統層面出現嚴重的穩定性問題，為了避免這個問題，GalaxyEngine 會啟動一個背景線程來異步清理資料檔案。當删除單個表空間時，會将對應的資料檔案先重命名為臨時檔案，并使用 DDL LOG 保證 crash safe，然後清除線程将異步、緩慢地清理檔案。

使用如下參數來配置此功能：

參數 說明
innodb_data_file_purge 是否啟用異步清除政策。
innodb_data_file_purge_all_at_shutdown 正常關機時全部清理。
innodb_data_file_purge_dir 臨時檔案目錄。
innodb_data_file_purge_immediate 是否直接清理資料檔案。
innodb_data_file_purge_interval 清理時間間隔。機關：ms。
innodb_data_file_purge_max_size 每次清理單個檔案大小的最大值。機關：MB。
innodb_print_data_file_purge_process 是否列印檔案清理工作程序。

​使用如下查詢檢視 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 機制介紹

回收機制

執行 DROP TABLE/DATABASE 語句時，隻保留相關的表對象，并移動到專門的 recycle bin 目錄中。其它對象的删除政策如下：

  • 如果是與表無關的對象，根據操作語句決定是否保留，不做回收。
  • 如果是表的附屬對象，可能會修改表資料的，做删除處理，例如 Trigger 和 Foreign key。 但 Column statistics 不做清理，随表進入資源回收筒。

執行 TRUNCATE TABLE 語句時，将原始表移動到專門的recycle bin目錄中，并在原位置使用相同的結建構立新表。

清理機制

資源回收筒會啟動一個背景線程，來異步清理超過 recycle_bin_retention 時間的表對象。在清理資源回收筒表的時候，如果遇到大表，會再啟動一個背景線程異步删除大表。

權限機制：

RDS MySQL執行個體啟動時，會初始化一個名為__recycle_bin__的資料庫，作為資源回收筒使用的專有資料庫。__recycle_bin__是系統級資料庫，您無法直接進行修改和删除。對于資源回收筒内的表，雖然您無法直接執行drop table語句，但是可以使用call dbms_recycle.purge_table() 進行清理。

另外賬号需要在原表和資源回收筒表都需要具有DROP權限。

命名機制：

Recycle Bin會從不同的資料庫回收到統一的__recycle_bin__資料庫中，是以需要保證目标表表名唯一，是以定義了如下命名格式：

"__" + [Storage Engine] + [SE private id]

Recycle Bin 相關參數

recycle_bin 是否打開資源回收筒，session/global 級别。
recycle_bin_retention 資源回收筒保留時間，機關：秒。預設為604800。
recycle_scheduler 是否打開資源回收筒的異步清理任務線程。預設值：OFF。
recycle_scheduler_interval 資源回收筒異步清理任務輪詢間隔，機關：秒。預設為30。
recycle_scheduler_purge_table_print 是否列印異步清理現場工作的詳細日志。

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 statistics查詢表和索引的統計資訊，包括如下兩個表：
    • TABLE_STATISTICS：記錄讀取和修改的行。
    • INDEX_STATISTICS：記錄索引的讀取行。
  • Performance point 提供執行個體的詳細性能資訊，友善您更快更準确地量化SQL的開銷。Performance point包括如下三個次元：
    • CPU：包括執行任務的總時間（Elapsed time）、CPU執行任務的時間（CPU time）等。
    • LOCK：包括伺服器MDL鎖時間、存儲事務鎖時間、互斥沖突（僅調試模式）、讀寫鎖沖突等。
    • IO：資料檔案讀寫時間、日志檔案寫入時間、邏輯讀取、實體讀取、實體異步讀取等。

Object statistics 使用方法

  1. 确認參數 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 開源位址:

https://github.com/ApsaraDB/galaxyengine

GalaxyEngine 後續還有更多更廣泛的開源和文檔支援計劃，敬請關注。

存儲 sql cloud native 關系型資料庫 mysql OLTP 分布式資料庫 資料庫 流計算 rds view解決方案 listview解決方案 存儲資料計算 centreon mysql不能使用 ceresdb安全資料存儲管理
上一篇: 帶你讀《揚帆遠航 5G 融合應用實踐精編》第一章5G助力經濟社會數字化轉型1.2我國5G網絡發展初具規模
下一篇: 帶你讀《揚帆遠航 5G 融合應用實踐精編》第一章5G助力經濟社會數字化轉型1.3 我國5G産業鍊逐漸成熟

繼續閱讀