后端再進階一步，MySQL 優化學習第1天

任何一個后端工程師，都離不開數據庫操作，而數據庫中 MySQL 又是使用頻率最高的一款，所以本系列專欄，將以3天一篇的頻率，一起學習 MySQL 優化。

單表優化

從字段上，盡量使用 tinyint ， smallint ， mediumint 作為整數類型，而不是用 int ，如果存儲的值非負的話，再使用 UNSIGNED 。

tinyint：占用1字節的存儲空間，即8位（bit），取值范圍 -127~127，在建表的時候要注意 tinyint(3) 可以，但是 tinyint(100) 還是 3 位，無符號范圍是 0 到 255；

smallint：占用2字節，無符號范圍 -32,768 到 32,767 ，無符號的范圍是 0 到 65,535；

mediumint：占用3字節，無符號的范圍是 0 到 16,777,215 ，帶符號的范圍是 -8,388,608 到 8,388,607；

int：最常用的，占用4字節，無符號的范圍是 0 到 4,294,967,295，帶符號的范圍是從 -2,147,483,648到 2,147,483,647；

bigint：占用 8 個字節，范圍很大！

這些數字只需要記住大概范圍即可。

MySQL邏輯架構

MySQL邏輯架構可按照三層區分：

客戶端層：建立鏈接部分，例如 Navicat 軟件建立鏈接；

核心服務層：查詢解析、分析、優化、緩存等都在這一層，存儲過程，觸發器，視圖也在這一層；

存儲引擎層：負責MySQL中的數據存儲和提取。

在這里翻閱資料的時候，碰到了一個新的概念，通信協議中的半雙工機制，與之對應的有 單工通信，半雙工，全雙工。

每個概念都可以進行簡單的理解，例如：

全雙工機制：雙向同時進行，例如上傳數據的同時還能下載數據；

單工通信：只能一方向另一方通信；

半雙工機制：同一時刻只能一方向另一方通訊，MySQL客戶端/服務端通信協議是半雙工的，也就是在一瞬間，不是服務器向客戶端發數據，就是客戶端向服務器發數據，在發送的時候中間沒有辦法切斷

基于這種機制，會出現如下場景，如果從客戶端發送的數據包太大了，可能導致請求超時，反之服務器發送的數據過大，傳輸時間也會變長，所以我們要控制服務器（MySQL）給我們返回的數據，盡量避免使用 select * ，盡量加上 limit 限制返回條數。

這種操作的核心邏輯是降低通信數據包的大小和數量。

存儲引擎層

今天咱們一起學習的最后一部分是MySQL存儲引擎層。

目前接觸最多的是 MyISAM 和 InnoDB 兩種引擎，可以針對單表進行設置。

MyISAM

MyISAM 引擎是 MySQL 5.1 及之前版本的默認引擎，有如下內容：

不支持事務，不支持外鍵，是表鎖，支持全文索引；

不支持安全恢復；

在表有讀取查詢的同時，支持往表中插入新紀錄；

存儲引擎表由MYD，MYI組成，MYD用來存放數據，MYI存索引；

支持壓縮表（該表不會被修改，例如枚舉表），大幅度減少磁盤空間占用，可以 myisampack 工具。

InnoDB

InnoDB 在 MySQL 5.5 后成為默認引擎，它的特點是：

支持事務，外鍵，支持行鎖，支持高并發；

支持安全恢復；

MySQL 5.6 已支持全文索引。

其它差別

InnoDB 不保存表的具體行數，執行 select count(*) from table 時需要全表掃描，當然如果加了 where 語句 ，二者差異不大。

MyISAM 用一個變量保存了整個表的行數，所以上述語句的執行速度很快；

InnoDB 最小的鎖粒度是行鎖，MyISAM 最小的鎖粒度是表鎖。正是因為這個原因，一個更新語句會鎖住整張表，導致其他查詢和更新都會被阻塞，因此并發訪問受限。

基于上述內容，如果執行大量的SELECT，選擇 MyISAM，如文章表；如果執行大量的 INSERT或UPDATE ，優先選擇 InnoDB 表，如訂單表。

然后在翻閱資料的時候，又發現一句總結：沒啥特殊的話請使用 InnoDB ，瞬間簡潔了~~

MySQL

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。