2、MySQL 邏輯架構

1. MySQL邏輯架構介紹

MySQL 的架構能夠在多種不一樣的場景中發揮良好的做用，主要體如今 MySQL 的存儲引擎架構上插件式的儲存引擎架構將查詢處理和其餘的系統任務以及數據的存儲提取相分離，這種架構能夠根據業務和實際須要選擇合適的儲存引擎。

總結：MySQL 是分層設計；插件式可拔插引擎；數據庫查詢優化時頭腦中要有邏輯架構層；

MySQL 自帶優化器，執行的順序不必定是SQL 語句的書寫順序，索引失效多是優化器的問題。若是不想MySQL 進行優化能夠強制使用書寫好的SQL語句或者將優化器去除（如阿里內部部分場景去除MySQL的優化器）

2.MySQL 邏輯分層

2.1 鏈接層

最上層是客戶端和鏈接服務，包含本地 socket 通訊和大多數基於客戶端/服務端工具實現的相似 TCP/IP 通道，主要完成一些相似於鏈接處理、受權認證以及相關的安全方案。該層上引入了線程池概念，經過認證安全接入的客戶端提供線程。一樣在該層上能夠實現基於 SSL 的安全鏈接，服務器也會爲安全接入的每一個客戶端驗證它所具備的操做權限。

2.2 服務層

第二層架構主要完成大多數的核心服務功能，如 SQL 接口，並完成緩存的查詢，SQL 分析和優化及部份內置函數的執行。全部跨存儲引擎功能也在這一層實現，如過程、函數等。在該層，服務器會解析查詢並建立相應的內部解析樹，並對其完成相應的優化，如肯定查詢表的順序，是否使用索引等，最後生成相應的執行操做。若是是 SELECT 語句，服務器還會查詢內部的緩存。增長緩存空間，在大量讀操做環境中能很好的提升系統性能。

服務層構成	簡介
Management Services & Utilities	系統管理和控制工具
SQL Interface	SQL接口。接受用戶的 SQL 命令，而且返回用戶須要的結果。如 select from 就是調用 SQL Interface。
Parser	解析器。SQL 命令傳遞到解析器的時候會被解析器驗證和解析。
Optimizer	查詢優化器。SQL 語句在查詢錢會使用查詢優化器進行查詢優化，好比有 where 條件時，優化器會決定先投影仍是先過濾。
Cache & Buffer	查詢緩存。若是緩存有命中查詢結果的，查詢語句就能夠直接在查詢緩存中取出數據。這個緩存機制是由一系列小緩存組成的，如：表緩存、記錄緩存、key緩存、權限緩存

2.3 引擎層

存儲引擎層，存儲引擎真正負責了 MySQL 中的存儲和提取，服務器經過 API 與存儲引擎進行通信。不一樣的存儲引擎具備不一樣的功能，咱們能夠根據本身的實際須要進行選擇，目前經常使用的是 MyISAM 和 InnoDB。

查看 MySQL 的存儲引擎

# 查看 MySQL 支持的存儲引擎
mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)
# 查看默認的存儲引擎
mysql> show variables like '%storage_engine%';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
| storage_engine         | InnoDB |
+------------------------+--------+
2 rows in set (0.00 sec)

MyISAM 和 InnoDB 的主要區別

對比項目	MyISAM	InnoDB
外鍵	不支持	支持
事務	不支持	支持
行表鎖	表鎖，即便操做一條記錄也會鎖住整個表，不適合高併發場景	行鎖，操做時只鎖住某一行，不對其餘行有影響，適合高併發操做。
緩存	只緩存索引，不緩存真實數據	不只緩存索引還緩存真實數據，對內存要求較高，並且內存大小對性能有決定性影響。
關注點	讀性能	併發寫、事務、資源
默認安裝	Y	Y
默認使用	N	Y
自帶系統表使用	Y	N

其餘的存儲引擎：

Percona 爲 MySQL數據庫服務器作了改進，在功能和性能上較 MySQL 有顯著提高。該版本提高了高負載狀況下 InnoDB 的性能、爲 DBA 提供了一些好用的診斷工具，另外有更多的參數和命令控制服務器行爲。

該公司新建了一款新的存儲引擎 XtraDB 徹底能夠替代 InnoDB，而且在性能和併發上表現得更好。

阿里巴巴大部分 MySQL 數據庫是對 Percona 的原型加以修改。

阿里開源的存儲引擎： ALisql 中使用的 X-Engine 存儲引擎。

2.4 存儲層

數據存儲層，主要是將數據存儲在物理磁盤的文件系統中，並經過存儲引擎進行交互。

2.5 SQL 查詢的大體流程

① 查詢緩存

MySQL 客戶端經過協議與 MySQL 服務器創建鏈接，併發送查詢語句，MySQL 服務器在接收到查詢語句後首先查詢緩存，若是緩存命中則直接返回結果，不然進行語句解析。在 MySQL 服務器接收到 SQL 語句後，會首先訪問查詢緩存（query cache，緩存中同時存儲 SELECT 語句和相應的結果集），若是某個查詢已經位於緩存中，服務器就再也不對查詢結果進行解析、優化和執行。而是僅僅將緩存中的結果返回給用戶，會大大提高系統性能。

② 語法解析和預處理

MySQL 服務器在接收到 SQL 語句後會根據關鍵字將 SQL 語句進行解析，並生成一棵對應的**「解析樹」**。MySQL 解析器會根據 SQL 語法規則進行語法驗證和解析查詢；預處理器則根據 SQL 規則進一步驗證解析樹是否合法。

③ 查詢優化

當解析樹經過合法性驗證後，優化器會將 SQL 查詢轉化成執行計劃。一條查詢有不少種執行方式，最終返回的結果都是相同的。優化器的做用是找到這些執行方式中最好的做爲執行計劃。

④ 使用索引

MySQL 默認使用 BTREE 索引，而且有一個大體的方向：不管怎樣折騰 SQL，至少在目前看來 MySQL 最多隻使用表中的一個索引。