av天天av无码av天天爽,av毛片,91无码成人视频,91精品久久久久久久久中文字幕,亚洲每日更新,翔田千里无码播放HD,淫色手机在线视频,亚洲最大在线

PolarDB-X 是由阿里巴巴自主研發(fā)的云原生分布式數(shù)據(jù)庫(kù)，融合了分布式 SQL 引擎 GalaxySQL 和分布式存儲(chǔ)引擎 GalaxyEngine，其中 GalaxyEngine 是新一代面向分布式場(chǎng)景的 MySQL 發(fā)行版本，作為官方 MySQL 版本的一個(gè)分支，除了吸收和跟進(jìn)官方版本的持續(xù)改進(jìn)以外，尤其在分布式場(chǎng)景下，實(shí)現(xiàn)了 Lizard 分布式事務(wù)和全局一致性解決方案、 Galaxy X-Protocol 交互協(xié)議 pipeline request、 X-Engine 存儲(chǔ)引擎、 Galaxy X-Paxos Cluster 保證數(shù)據(jù)零丟失并持續(xù)可用，以及共享的 RDS MySQL 內(nèi)核企業(yè)級(jí)功能等，GalaxyEngine 遵循 GPLv2 License，希望通過(guò)開(kāi)源，回饋社區(qū)，共建 MySQL 生態(tài)繁榮。

GalaxyEngine 開(kāi)源的技術(shù)細(xì)節(jié)：

1. Lizard 分布式事務(wù)和全局一致性解決方案

1.1 問(wèn)題背景

Lizard 事務(wù)系統(tǒng)主要解決 GalaxyEngine 的兩個(gè)重要問(wèn)題：

擴(kuò)展性問(wèn)題

在單機(jī)多核的場(chǎng)景下，MySQL InnoDB 的事務(wù)系統(tǒng)作為一個(gè)內(nèi)存結(jié)構(gòu)，存在嚴(yán)重的 Write Transaction 和 Read Query 的干擾，無(wú)法高效使用多核能力，Lizard SCN 單機(jī)事務(wù)系統(tǒng)，解綁讀寫(xiě)之間對(duì)事務(wù)系統(tǒng)的爭(zhēng)搶?zhuān)軌蛟贠LTP Read-Write 的真實(shí)業(yè)務(wù)場(chǎng)景滿(mǎn)載多核能力。

分布式事務(wù)原子性和一致性問(wèn)題

在多節(jié)點(diǎn)集群的場(chǎng)景下，由于數(shù)據(jù)分片，一個(gè)業(yè)務(wù)場(chǎng)景會(huì)有多個(gè)節(jié)點(diǎn)參與，單機(jī)事務(wù)無(wú)法保證多個(gè)節(jié)點(diǎn)參與的事務(wù) Atomicity 以及查詢(xún)的一致性，Lizard GCN 分布式事務(wù)系統(tǒng)，提供了一整套的解決方案來(lái)滿(mǎn)足。

1.2 Lizard SCN 單機(jī)事務(wù)系統(tǒng)

MySQL InnoDB 事務(wù)系統(tǒng)

MySQL InnoDB 事務(wù)系統(tǒng)和 MVCC 主要包括三個(gè)主要結(jié)構(gòu): 活躍事務(wù)鏈表 Active Trx，查詢(xún)事務(wù) Read View，行記錄 Record。

其多版本 MVCC 實(shí)現(xiàn)簡(jiǎn)略如下：

1.從 Active Trx 拷貝一個(gè) Read View；

2.檢索行記錄，根據(jù) TID 到 Read View 中進(jìn)行二分查找，判斷可見(jiàn)性。

Lizard SCN 事務(wù)系統(tǒng)

Lizard SCN 事務(wù)系統(tǒng)，使用 System Commit Number 來(lái)代替 Trx ID 進(jìn)行多版本可見(jiàn)性判斷，并使用 Transaction Slot 來(lái)保存事務(wù)的相關(guān)信息。

其寫(xiě)事務(wù)實(shí)現(xiàn)簡(jiǎn)略如下：

1.Begin 的時(shí)候，在 Transaction Table 中申請(qǐng)一個(gè) Slot，其地址用 UBA 表示；

2.Insert 的時(shí)候，在行記錄上新增 UBA 和 SCN 兩個(gè)字段；

3.Commit 的時(shí)候，從 SCN 生成器生成一個(gè) number，填寫(xiě)到 Slot 中。

其 MVCC 實(shí)現(xiàn)如下：

1.Query 申請(qǐng)一個(gè)當(dāng)前 SCN 作為 Read View；

2.檢索行記錄的時(shí)候，根據(jù)行記錄 SCN 和 Read View 比較數(shù)字大小，判斷可見(jiàn)性。

Delayed Record Cleanout

Lizard SCN 事務(wù)系統(tǒng)，除了在 Commit 的時(shí)候，做少量的 Commit Cleanout，即行記錄上回填 SCN，大部分的行記錄 SCN 回填，都是 Delayed Record Cleanout，即在讀取行記錄上 SCN 時(shí)，發(fā)現(xiàn)是 NULL 值，就根據(jù) UBA 地址查詢(xún) transaction slot 找到需要回填的 SCN，并做壓力和負(fù)載的自動(dòng)化優(yōu)化。

Flashback Query

Lizard SCN 事務(wù)系統(tǒng)原生支持 Flashback query，其語(yǔ)法如下：

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

Lizard SCN 事務(wù)系統(tǒng)支持使用參數(shù) INNODB_UNDO_RETENTION = number [seconds] 來(lái)定義支持多久的歷史查詢(xún)，時(shí)間越長(zhǎng)，其占用的 UNDO 表空間也會(huì)相應(yīng)的增加，例如：

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 性能表現(xiàn)

在高并發(fā)和多核的真實(shí) OLTP Read-Write 場(chǎng)景下，Lizard SCN 能很好的滿(mǎn)載多核的能力，突破事務(wù)系統(tǒng)的瓶頸。

1.3 Lizard GCN 分布式事務(wù)系統(tǒng)

兩階段提交

Lizard GCN 分布式事務(wù)系統(tǒng)建立在 SCN 事務(wù)系統(tǒng)的基礎(chǔ)上，對(duì) Transaction Slot 進(jìn)行了擴(kuò)充，允許接受外部提交號(hào)，即 Global Commit Number，并進(jìn)行持久化，為了保證分布式事務(wù)的原子性，這里引用 MySQL XA 的兩階段提交來(lái)完成分布式事務(wù)：

SET?SESSION?innodb_commit_seq = [GCN];
XA START?xid

......

XA COMMIT?xid;

或者

XA START?xid;

......

XA COMMIT?xid $GCN;

全局一致性

Lizard GCN 使用 GCN 作為 Read View 進(jìn)行全局一致性的判斷：

1.Query 從 TSO 獲取一個(gè)當(dāng)前 GCN；

2.檢索記錄，并根據(jù) GCN 數(shù)字大小比較進(jìn)行可見(jiàn)性比較。

其支持兩種語(yǔ)法：

SET?SESSION?innodb_snapshot_seq = [GCN]

或者

SELECT?... FROM?tablename
??AS?OF?GCN expr;

TSO 解決方案

PolarDB-X 采用了 TSO 的架構(gòu)方案，為此 GalaxyEngine 提供了一個(gè)方便快捷的生成全局版本號(hào)的機(jī)制，即 Sequence Engine，Sequence Engine 采用了兼容商業(yè)數(shù)據(jù)庫(kù)語(yǔ)法，并使用 InnoDB 存儲(chǔ)引擎作為持久化方法。

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 生成一個(gè)單調(diào)唯一的數(shù)字；

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個(gè) bit 的時(shí)間戳，16個(gè) bit 的數(shù)字，另外還有預(yù)留的6個(gè) bit。

XA 事務(wù)完整性

MySQL XA 實(shí)現(xiàn)了一套兩階段提交協(xié)議，以便在分布式事務(wù)系統(tǒng)中使用，但原生的 MySQL XA 存在完整性問(wèn)題，假如在分布式場(chǎng)景中，Node1, Node2 ... NodeN 作為節(jié)點(diǎn)參與方，XA 使用 Two-Phase Commit Protocol ?(2PC) 保證分布式事務(wù)的原子性，但對(duì)于每個(gè)節(jié)點(diǎn)中的 Binlog Storage 和 InnoDB Storage 兩個(gè)參與方，MySQL 目前沒(méi)有機(jī)制保證在每個(gè)階段(Prepare 或者 Commit) 不同 Storage 參與方之間的一致性，這也源于Binlog Storage 本身沒(méi)有 UNDO 的機(jī)制保證有關(guān)，這樣 2PC 的崩潰恢復(fù)協(xié)議也就無(wú)法獲得有效的節(jié)點(diǎn)事務(wù)狀態(tài)，GalaxyEngine 除了使用兩階段提交協(xié)議的 External Coordinator 以外，引入了使用 GTID 補(bǔ)償協(xié)議的 Internal Coordinator 來(lái)保證 Storage 之間的一致性。

GTID 補(bǔ)償協(xié)議的主要工作原理：

1.在單個(gè)節(jié)點(diǎn)崩潰恢復(fù)階段，根據(jù) Binlog File 構(gòu)建 Binlog GTID 集合；

2.在單個(gè)節(jié)點(diǎn)崩潰恢復(fù)階段，根據(jù) InnoDB GTID_EXECUTED 以及 TRANSACTION UNDO HISTORY 構(gòu)建 InnoDB GTID 集合；

3.構(gòu)建集合的差集，使用 Binlog Event 進(jìn)行補(bǔ)償 InnoDB 丟失的事務(wù)，恢復(fù)單個(gè)節(jié)點(diǎn)；

4.完成單個(gè)節(jié)點(diǎn)的補(bǔ)償后，XA 組件開(kāi)始分布式集群的兩階段提交事務(wù)的崩潰恢復(fù)。

2. Galaxy X-protocol 交互協(xié)議

MySQL 原生 Client/Server Protocol 使用停等的方式進(jìn)行交互，以及 one-thread-per-connection 的線(xiàn)程處理模型，極大的影響了資源利用率，Galaxy X-protocol 在 MySQL X Protocol 的基礎(chǔ)上，重新定義了消息格式，并分離了 CONNECTION<->SESSION<->THREAD ?三者，實(shí)現(xiàn)請(qǐng)求的 Pipeline，最大化提升吞吐能力。

消息格式

Galaxy X-protocol 消息格式：

===========================

4 bytes Session ID

1 bytes Protocol Version

4 bytes Message Length

1 bytes Message Type

x bytes Payload

===========================

消息處理模型

消息通過(guò)使用 google protobuf 進(jìn)行傳遞，消息處理模型如下：

多個(gè) Client 可以共用 connection 的 TCP 網(wǎng)絡(luò)通道，提高網(wǎng)絡(luò)通道的利用率，根據(jù)請(qǐng)求的 message 的 session id 進(jìn)行消息分發(fā)，然后放置到任務(wù)隊(duì)列中，由后臺(tái)線(xiàn)程池模塊進(jìn)行處理，這樣就形成了高效的處理方式。

3. X-Engine 存儲(chǔ)引擎

X-Engine是阿里數(shù)據(jù)庫(kù)產(chǎn)品事業(yè)部自研的OLTP數(shù)據(jù)庫(kù)存儲(chǔ)引擎，作為自研數(shù)據(jù)庫(kù)POLARDB X的存儲(chǔ)引擎，已經(jīng)廣泛應(yīng)用在阿里集團(tuán)內(nèi)部諸多業(yè)務(wù)系統(tǒng)中，其中包括交易歷史庫(kù)，釘釘歷史庫(kù)等核心應(yīng)用，為業(yè)務(wù)大幅縮減了成本。

X-Engine 整體架構(gòu)

X-Engine使用了LSM作為基礎(chǔ)架構(gòu)，目標(biāo)是作為一個(gè)通用的高性能低成本存儲(chǔ)引擎，追求讀寫(xiě)性能更為均衡，因此在其上做了大量工程優(yōu)化，主要圍繞幾個(gè)方向進(jìn)行：

1. 利用LSM-tree先天優(yōu)勢(shì)，提升了系統(tǒng)寫(xiě)性能天花板。
2. 優(yōu)化LSM-tree的compaction操作，以降低對(duì)系統(tǒng)性能的沖擊，使得系統(tǒng)性能表現(xiàn)趨于平穩(wěn)。

3. 利用持久化數(shù)據(jù)層只讀特點(diǎn)，發(fā)揮壓縮優(yōu)勢(shì)降低成本。
4. 利用天然分層結(jié)構(gòu)，結(jié)合硬件能力使用冷熱分層結(jié)構(gòu)，降低綜合成本。

5. 利用精細(xì)化訪問(wèn)機(jī)制和緩存技術(shù)，彌補(bǔ)LSM-tree讀性能短板。

X-Engine 使用方法

X-Engine 是 MySQL 的一個(gè)存儲(chǔ)引擎，在 MySQL 體系中的位置與 InnoDB 類(lèi)似，因此使用 X-Engine 只需要在引擎初始化及啟動(dòng)開(kāi)啟 X-Engine 參數(shù)，同時(shí)在建表時(shí)指定 engine 類(lèi)型為 xengine 即可。

建表語(yǔ)法

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

X-Engine 性能水準(zhǔn)

RDS X-Engine在保證3~5倍的空間壓縮的前提下，保證了與InnoDB相近的性能水準(zhǔn)。測(cè)試報(bào)告詳見(jiàn)RDS MySQL 文檔官網(wǎng)(X-Engine性能測(cè)試：https://help.aliyun.com/document_detail/163250.html?spm=a2c6h.12873639.0.0.56594c1eJOhOJu）

4. RDS MySQL 企業(yè)級(jí)功能

RDS MySQL 是阿里云在云上提供的 MySQL 云數(shù)據(jù)庫(kù)產(chǎn)品，并在內(nèi)核上定制了企業(yè)級(jí)功能，同時(shí)也作為GalaxyEngine 的基礎(chǔ)功能，并進(jìn)行開(kāi)源。

4.1 Purge Large Table Asynchronously

使用 InnoDB 存儲(chǔ)引擎時(shí)，直接刪除大表或者大文件會(huì)導(dǎo)致文件系統(tǒng)層面出現(xiàn)嚴(yán)重的穩(wěn)定性問(wèn)題，為了避免這個(gè)問(wèn)題，GalaxyEngine 會(huì)啟動(dòng)一個(gè)后臺(tái)線(xiàn)程來(lái)異步清理數(shù)據(jù)文件。當(dāng)刪除單個(gè)表空間時(shí)，會(huì)將對(duì)應(yīng)的數(shù)據(jù)文件先重命名為臨時(shí)文件，并使用 DDL LOG 保證 crash safe，然后清除線(xiàn)程將異步、緩慢地清理文件。

使用如下參數(shù)來(lái)配置此功能：

使用如下查詢(xún)查看 Purge 進(jìn)度：

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 語(yǔ)句無(wú)法回滾，開(kāi)發(fā)或運(yùn)維人員如果誤操作（例如 DROP/TRUNCATE TABLE）可能會(huì)導(dǎo)致數(shù)據(jù)丟失。Recycle Bin 功能，臨時(shí)將刪除的表轉(zhuǎn)移到回收站，還可以設(shè)置保留的時(shí)間，方便找回?cái)?shù)據(jù)，同時(shí)提供了工具包（DBMS_RECYCLE）便于快捷使用。

Recycle Bin 機(jī)制介紹

回收機(jī)制：

執(zhí)行 DROP TABLE/DATABASE 語(yǔ)句時(shí)，只保留相關(guān)的表對(duì)象，并移動(dòng)到專(zhuān)門(mén)的 recycle bin 目錄中。其它對(duì)象的刪除策略如下：

如果是與表無(wú)關(guān)的對(duì)象，根據(jù)操作語(yǔ)句決定是否保留，不做回收。
如果是表的附屬對(duì)象，可能會(huì)修改表數(shù)據(jù)的，做刪除處理，例如 Trigger 和 Foreign key。但 Column statistics 不做清理，隨表進(jìn)入回收站。

執(zhí)行TRUNCATE TABLE語(yǔ)句時(shí)，將原始表移動(dòng)到專(zhuān)門(mén)的recycle bin目錄中，并在原位置使用相同的結(jié)構(gòu)創(chuàng)建新表。

清理機(jī)制：

回收站會(huì)啟動(dòng)一個(gè)后臺(tái)線(xiàn)程，來(lái)異步清理超過(guò) recycle_bin_retention 時(shí)間的表對(duì)象。在清理回收站表的時(shí)候，如果遇到大表，會(huì)再啟動(dòng)一個(gè)后臺(tái)線(xiàn)程異步刪除大表。

權(quán)限機(jī)制：

RDS MySQL實(shí)例啟動(dòng)時(shí)，會(huì)初始化一個(gè)名為__recycle_bin__的數(shù)據(jù)庫(kù)，作為回收站使用的專(zhuān)有數(shù)據(jù)庫(kù)。__recycle_bin__ 是系統(tǒng)級(jí)數(shù)據(jù)庫(kù)，您無(wú)法直接進(jìn)行修改和刪除。對(duì)于回收站內(nèi)的表，雖然您無(wú)法直接執(zhí)行drop table語(yǔ)句，但是可以使用call dbms_recycle.purge_table('');進(jìn)行清理。

另外賬號(hào)需要在原表和回收站表都需要具有DROP權(quán)限。

命名機(jī)制：
Recycle Bin會(huì)從不同的數(shù)據(jù)庫(kù)回收到統(tǒng)一的__recycle_bin__數(shù)據(jù)庫(kù)中，所以需要保證目標(biāo)表表名唯一，所以定義了如下命名格式：

"__" + + private id>

Recycle Bin 相關(guān)參數(shù)

Recycle Bin 接口設(shè)計(jì)

--?Purge?Table
dbms_recycle.purge_table('
');

--?Restore?table
dbms_recycle.restore_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 語(yǔ)句返回 Resultset，同時(shí)提供了工具包（DBMS_TRANS）便于您快捷使用。

Returning 語(yǔ)法：
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

為了應(yīng)對(duì)突發(fā)的數(shù)據(jù)庫(kù)請(qǐng)求流量、資源消耗過(guò)高的語(yǔ)句訪問(wèn)以及SQL訪問(wèn)模型的變化，保證實(shí)例持續(xù)穩(wěn)定運(yùn)行，GalaxyEngine 提供基于語(yǔ)句規(guī)則的并發(fā)控制 CCL（Concurrency Control），并提供了工具包（DBMS_CCL）便于您快捷使用。

功能設(shè)計(jì)

CCL規(guī)則定義了如下三個(gè)維度的特征：
SQL command: SQL命令類(lèi)型，例如SELECT、UPDATE、INSERT、DELETE等。
Object: SQL命令操作的對(duì)象，例如TABLE、VIEW等。
keywords: SQL命令的關(guān)鍵字。

規(guī)則持久化存儲(chǔ)在系統(tǒng)表 mysql.concurrency_control.

接口設(shè)計(jì)

--?Add?Rule
dbms_ccl.add_ccl_rule('','','',,'');

--?Delete?Rule
dbms_ccl.del_ccl_rule();

--?Show?Rule
dbms_ccl.show_ccl_rule();

--?Flush?Rule
dbms_ccl.flush_ccl_rule();

4.5 Statement Outline

生產(chǎn)環(huán)境中，SQL語(yǔ)句的執(zhí)行計(jì)劃經(jīng)常會(huì)發(fā)生改變，導(dǎo)致數(shù)據(jù)庫(kù)不穩(wěn)定。GalaxyStore 利用 Optimizer Hint 和Index Hint 讓 MySQL 穩(wěn)定執(zhí)行計(jì)劃，該方法稱(chēng)為 Statement Outline，并提供了工具包（DBMS_OUTLN）便于快捷使用。

功能設(shè)計(jì)

Statement Outline支持官方MySQL 8.0 的所有 hint 類(lèi)型，分為如下兩類(lèi)：
Optimizer Hint 根據(jù)作用域和 hint 對(duì)象，分為 Global level hint、Table/Index level hint、Join order hint等。
Index Hint 根據(jù) Index Hint 的類(lèi)型和范圍進(jìn)行分類(lèi)。

增加的 outline 持久化存儲(chǔ)在 mysql.outline 表中。

接口設(shè)計(jì)

-- Add optimizer Outline
dbms_outln.add_optimizer_outline('','','','','');

-- Add Index Outline
dbms_outln.add_index_outline('','',,'','','','');

-- Delete Outline
dbms_outln.del_outline();

-- 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 是專(zhuān)注于實(shí)例負(fù)載監(jiān)控、關(guān)聯(lián)分析、性能調(diào)優(yōu)的利器，幫助您迅速評(píng)估數(shù)據(jù)庫(kù)負(fù)載，找到性能問(wèn)題的源頭，提升數(shù)據(jù)庫(kù)的穩(wěn)定性。

Performance Insight 介紹

Performance Insight由如下兩部分組成：

Object statisticsObject statistics查詢(xún)表和索引的統(tǒng)計(jì)信息，包括如下兩個(gè)表：
TABLE_STATISTICS：記錄讀取和修改的行。
INDEX_STATISTICS：記錄索引的讀取行。

Performance pointPerformance point 提供實(shí)例的詳細(xì)性能信息，方便您更快更準(zhǔn)確地量化SQL的開(kāi)銷(xiāo)。Performance point包括如下三個(gè)維度：
CPU：包括執(zhí)行任務(wù)的總時(shí)間（Elapsed time）、CPU執(zhí)行任務(wù)的時(shí)間（CPU time）等。
LOCK：包括服務(wù)器MDL鎖時(shí)間、存儲(chǔ)事務(wù)鎖時(shí)間、互斥沖突（僅調(diào)試模式）、讀寫(xiě)鎖沖突等。
IO：數(shù)據(jù)文件讀寫(xiě)時(shí)間、日志文件寫(xiě)入時(shí)間、邏輯讀取、物理讀取、物理異步讀取等。

Object statistics 使用方法

確認(rèn)參數(shù) 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 的相關(guān)參數(shù)
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 數(shù)據(jù)庫(kù)查詢(xún) 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?|
??+--------------------+----------------------------------+-------------------------------------------+--------------+
注：需要同步打開(kāi) performance schema。

GalaxyEngine 后續(xù)還有更多更廣泛的開(kāi)源和文檔支持計(jì)劃，敬請(qǐng)關(guān)注。
GalaxyEngine 開(kāi)源地址: https://github.com/ApsaraDB/galaxyengine

推薦閱讀
阿里云正式開(kāi)源PolarDB-X數(shù)據(jù)庫(kù)，壯大云原生分布式數(shù)據(jù)庫(kù)生態(tài)

點(diǎn)擊“閱讀原文”查看PolarDB-X更多信息
瀏覽 139
點(diǎn)贊
評(píng)論
收藏
分享
手機(jī)掃一掃分享
分享
舉報(bào)
評(píng)論
圖片
表情
視頻
全部評(píng)論
推薦
TmStorage開(kāi)源存儲(chǔ)引擎
TmStorage 是一個(gè)用 .NET 開(kāi)發(fā)的虛擬文件系統(tǒng)，用來(lái)存儲(chǔ)流數(shù)據(jù)。使用扁平結(jié)構(gòu)進(jìn)行數(shù)據(jù)存儲(chǔ)
TmStorage開(kāi)源存儲(chǔ)引擎
TmStorage是一個(gè)用.NET開(kāi)發(fā)的虛擬文件系統(tǒng)，用來(lái)存儲(chǔ)流數(shù)據(jù)。使用扁平結(jié)構(gòu)進(jìn)行數(shù)據(jù)存儲(chǔ)，通過(guò)類(lèi)型為GUID的流id來(lái)引用數(shù)據(jù)。TmStorage使用一個(gè)主文件用來(lái)存儲(chǔ)所有流數(shù)據(jù)。主文件被分成多
 Acala AMA｜解讀「流動(dòng)性引擎」
PolkaWorld
0
盤(pán)口解讀技術(shù)
利用盤(pán)口解讀技術(shù)是透過(guò)看似隨機(jī)的價(jià)格／成交量現(xiàn)象,解讀精明資金與交易大眾的行為差異,并藉以擬訂進(jìn)場(chǎng)與
 盤(pán)口解讀技術(shù)
盤(pán)口解讀技術(shù)
0
盤(pán)口解讀技術(shù)
《盤(pán)口解讀技術(shù)》描述了一位前蘇聯(lián)公民華丁·格列佛(Vadym Graifer)由于故鄉(xiāng)烏克蘭的惡性發(fā)
盤(pán)口解讀技術(shù)
盤(pán)口解讀技術(shù)
0
視覺(jué)SLAM技術(shù)解讀
小白學(xué)視覺(jué)
0
視覺(jué)SLAM技術(shù)解讀
新機(jī)器視覺(jué)
0
解讀云原生技術(shù)
博文視點(diǎn)Broadview
0
點(diǎn)贊
評(píng)論
收藏
分享
手機(jī)掃一掃分享
分享
舉報(bào)
2023?輕識(shí)隱私協(xié)議用戶(hù)協(xié)議關(guān)于我們機(jī)器人浙ICP備19021730號(hào)-8 浙公網(wǎng)安備 33011002017279號(hào)

<kbd id="afajh"><form id="afajh"></form></kbd>

PolarDB 解讀 | PolarDB-X 存儲(chǔ)引擎組件 GalaxyEngine 開(kāi)源技術(shù)解讀