很多小伙伴使用了GreatSQL，但是對GreatSQL的底層原理還不是很了解，今天就帶大家一起揭開GreatSQL體系架構(gòu)的神秘面紗！

首先來回顧一張經(jīng)典的體系架構(gòu)圖：

圖片

圖1_GreatSQL5.7 版本體系架構(gòu)圖

由此可以發(fā)現(xiàn)，GreatSQL5.7 由以下幾部分組成

• 連接池組件
• 系統(tǒng)管理和控制工具
• SQL接口組件
• 查詢解析器
• 查詢優(yōu)化器
• 緩存組件
• 可插拔存儲引擎
• 系統(tǒng)和日志文件

GreatSQL數(shù)據(jù)庫區(qū)別于其他數(shù)據(jù)庫的一個特點就是其可插拔的表存儲引擎，特別需要注意的是，存儲引擎是基于表的，而不是數(shù)據(jù)庫。

然而，經(jīng)典同時也意味著這幅圖已經(jīng)相當(dāng)陳舊了。在GreatSQL8.0 及更高版本中，查詢緩存這一功能已經(jīng)被移除。

圖片

圖2_GreatSQL8.0 版本體系架構(gòu)圖

總體來說，GreatSQL8.0 可以分為連接層、服務(wù)層、存儲引擎層。

一、連接層（Client Connectors）

連接層又名為客戶端連接器（Client Connectors）作用是提供與GreatSQL服務(wù)器建立的支持。

客戶端通過TCP/IP協(xié)議與GreatSQL服務(wù)器建立連接，每個連接對應(yīng)一個線程。連接管理還包括了連接池技術(shù)，以復(fù)用已經(jīng)建立好的連接，減少重復(fù)建立連接的開銷。

而且?guī)缀踔С炙兄髁鞯姆?wù)端編程技術(shù)，主要完成一些類似于連接處理、授權(quán)認(rèn)證、及相關(guān)的安全方案。

會對從 TCP 傳輸過來的賬號密碼做身份認(rèn)證、權(quán)限獲取

• 用戶名或密碼不對，會收到Access denied for user錯誤，客戶端程序結(jié)束執(zhí)行

例如:

$ mysql -uroot -p
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

• 用戶名密碼認(rèn)證通過，會從權(quán)限表查出賬號擁有的權(quán)限與連接關(guān)聯(lián)，之后的權(quán)限判斷邏輯，都將依賴于此時讀到的權(quán)限

二、服務(wù)層（GreatSQL Server）

服務(wù)層是GreatSQL Server的核心，主要包含連接器、分析器、優(yōu)化器、執(zhí)行器等，涵蓋 GreatSQL 的大多數(shù)核心服務(wù)功能，以及所有的內(nèi)置函數(shù)（如日期、時間、數(shù)學(xué)和加密函數(shù)等），所有跨存儲引擎的功能都在這一層實現(xiàn)，比如存儲過程、觸發(fā)器、視圖等。

Ⅰ.SQL Interface: SQL接口

接收用戶的SQL命令，并且返回用戶需要查詢的結(jié)果。比如SELECT … FROM就是調(diào)用SQL Interface，GreatSQL支持DML、DDL、存儲過程、視圖、觸發(fā)器、自定義函數(shù)等多種SQL語言接口

同時還支持NoSQL，NoSQL泛指非關(guān)系型數(shù)據(jù)庫和數(shù)據(jù)存儲。隨著互聯(lián)網(wǎng)平臺的規(guī)模飛速發(fā)展，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)越來越不能滿足需求。從5.6版本開始，GreatSQL就開始支持簡單的NoSQL存儲功能。GreatSQL8.0 版本對這一功能做了優(yōu)化，以更靈活的方式實現(xiàn)NoSQL功能，不再依賴模式（schema）。

Ⅱ.Parser: 解析器

在解析器中對 SQL 語句進(jìn)行語法分析、語義分析。將 SQL 語句分解成數(shù)據(jù)結(jié)構(gòu)，并將這個結(jié)構(gòu)傳遞到后續(xù)步驟，以后 SQL 語句的傳遞和處理就是基于這個結(jié)構(gòu)的，并且判斷你輸入的這個 SQL 語句是否滿足 GreatSQL 語法。

Ⅲ.Optimizer: 查詢優(yōu)化器

在開始執(zhí)行之前，還要先經(jīng)過優(yōu)化器的處理。

SQL語句在語法解析之后、查詢之前會使用查詢優(yōu)化器確定 SQL 語句的執(zhí)行路徑，生成一個執(zhí)行計劃，可以使用EXPLAIN命令查看執(zhí)行計劃。

這個執(zhí)行計劃表明應(yīng)該使用哪些索引進(jìn)行查詢（全表檢索還是使用索引檢索），表之間的連接順序如何，最后會按照執(zhí)行計劃中的步驟調(diào)用存儲引擎提供的方法來真正的執(zhí)行查詢，并將查詢結(jié)果返回給用戶。

例如下面的 JOIN 語句：

SELECT * FROM tb1 JOIN tb2 USING(ID) WHERE tb1.a=1 and tb2.a=2;

那就有兩種方法可以選擇：

• 第一種，先取表 tb1 里 a=1 的記錄的ID值，再根據(jù) ID 關(guān)聯(lián)表 tb2 ，然后再判斷 tb2 里面 a 的值是否等于 2
• 第二種，先取表 tb2 里面的 a=2 記錄的 ID 值，在根據(jù) ID 值關(guān)聯(lián) tb1 ，再判斷 tb1 里面 a 的值是否等于 10

執(zhí)行的結(jié)果肯定是一致的，但是效率就大不相同了，所以我們要選擇用小的數(shù)據(jù)集去驅(qū)動大的數(shù)據(jù)集，也就是小表驅(qū)動大表。

Ⅳ.Caches & Buffers：查詢緩存組件

GreatSQL 內(nèi)部維持著一些 Cache 和 Buffer，比如 Query Cache 用來緩存一條 SELECT 語句的執(zhí)行結(jié)果，如果能夠在其中找到對應(yīng)的查詢結(jié)果，那么就不必再進(jìn)行查詢解析、優(yōu)化和執(zhí)行的整個過程了，直接將結(jié)果反饋給客戶端。

但是在 GreatSQL 8.0 版本及以上中刪除了查詢緩存功能,因為查詢緩存必須要兩條SQL語句完全一模一樣，否則是不能觸發(fā)查詢緩存，非常的雞肋~

三、引擎層（Storage Engines）

Ⅰ.存儲引擎層

真正的負(fù)責(zé)了 GreatSQL 中數(shù)據(jù)的存儲和提取，對物理服務(wù)器級別維護(hù)的底層數(shù)據(jù)執(zhí)行操作，服務(wù)器通過API與存儲引擎進(jìn)行通信。

存儲引擎的優(yōu)勢在于，各式各樣的存儲引擎都具備獨(dú)特的特性，從而能夠針對特定的應(yīng)用需求建立不同存儲引擎表。

GreatSQL 支持的存儲引擎如下：

greatsql> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| Engine 引擎名稱 | Support 支持情況 | Comment 引擎的說明                          | Transactions 事務(wù)支持 | XA 分布式事務(wù)支持  | Savepoints 保存點 |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| FEDERATED          | NO      | Federated MySQL storage engine                                             | NULL         | NULL | NULL       |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                                         | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES          | YES  | YES        |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables                  | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                                      | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                                      | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears)             | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                                         | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                                     | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

得益于 GreatSQL 數(shù)據(jù)庫的開源特性，用戶得以依據(jù)存儲引擎接口自行編寫個性化的存儲引擎。當(dāng)對某一種存儲引擎的性能或功能存有疑慮時，可通過優(yōu)化代碼實現(xiàn)所需特性，這正展示了開源所賦予我們的便捷與力量。

Ⅱ.存儲層

所有的數(shù)據(jù)，數(shù)據(jù)庫、表的定義，表的每一行的內(nèi)容，索引，都是存在 文件系統(tǒng)上，以文件的方式存在的，并完成與存儲引擎的交互。當(dāng)然有些存儲引擎比如InnoDB，也支持不使用文件系統(tǒng)直接管理裸設(shè)備，但現(xiàn)代文件系統(tǒng)的實現(xiàn)使得這樣做沒有必要了。在文件系統(tǒng)之下，可以使用本地磁盤，可以使用DAS、NAS、SAN等各種存儲系統(tǒng)。

總結(jié)

所以可以把 GreatSQL 的架構(gòu)圖簡化如下：

圖片

要把架構(gòu)圖牢牢記住，對于以后深入理解 GreatSQL 數(shù)據(jù)庫會有極大幫助!