Mysql優化總結(一)

時間 2019-11-19

標籤 mysql 優化總結欄目 MySQL 简体版

原文原文鏈接

一，前言

數據庫（Database）是按照數據結構來組織、存儲和管理數據的倉庫。mysql

MySQL 是一個關係型數據庫管理系統，由瑞典 MySQL AB 公司開發，目前屬於 Oracle 公司。MySQL 是一種關聯數據庫管理系統，關聯數據庫將數據保存在不一樣的表中，而不是將全部數據放在一個大倉庫內，這樣就增長了速度並提升了靈活性。程序員

MySQL是開源的，因此不須要支付任何費用。
MySQL使用標準的SQL數據語言形式。
MySQL能夠處理擁有千萬條記錄的大型數據庫。
MySQL支持多種語言，如C，PHP，Java等。

　　本篇博客是總結MySQL存儲機制及SQL優化方面的內容。sql

二，MySQL邏輯架構

分析：數據庫

第一層是大多數基於網絡的客戶端/服務器的工具或者服務都有相似的架構。如鏈接處理，受權認證等。
第二層架構中，大多數的MYSQL的核心服務功能都在這一層，包括查詢解析、分析、優化、緩存以及全部的內置函數（日期時間等），全部跨存儲引擎的功能都在這一層實現：存儲過程、觸發器、視圖等層。
第三層包含了存儲引擎。存儲引擎負責Mysql中的數據的存儲和提取。
Mysql支持各類不一樣的存儲引擎，每一個存儲引擎都有它的優點和劣勢。服務器經過API和存儲引擎進行通訊。這些API接口屏蔽了不一樣存儲引擎之間的差別，使的這些差別對上層的查詢過程透明。存儲引擎不會解析SQL（InnoDB是個例外，它會解析外鍵定義），不一樣的存儲引擎之間也不能互相通訊，而只是簡單的響應上層服務器的請求。

緩存：當客戶端請求到來時，先去查詢緩存中是否存在數據，沒有再去數據庫中查詢。緩存

分析器：對sql語句的分析，好比SELECT username FROM users; ，分析器分析出先執行FROM users，而後再執行SELECT　username。

優化器：上面只是舉了一個簡單的例子，而優化器做用在於選擇那種執行方式，是執行SQL效率最快的。由於分析器對一條SQL語句會分析出多種不一樣的結果，而優化器就會對以上的分析結果選擇它認爲最優的結果來執行。可是，須要注意的是，優化器認爲最優的執行方案，並不必定是咱們認爲的最優執行方案。所以再SQL語句量較大的狀況下，就須要程序員手動對語句進行優化。服務器

下面再來講說MySQL的存儲引擎。網絡

三，存儲引擎

以博主的MySQL做爲案例，執行select version();語句能夠查看數據庫版本。數據結構

接着再來看看MySQL都支持哪些存儲引擎。架構

在倒數第二個，能夠看出MySQL默認的存儲引擎是InnoDB，再細看Transactions中只有InnoDB是支持事務的，其餘存儲引擎都是不支持的。這是在MySQL5.5以後支持的引擎，因此說在5.5以前MySQL是不支持事務的。函數

最長用的兩種存儲引擎爲InnoDB和Myisam，請看二者之間的區別（MySQL5.6）。

特色	InnoDB	myisam
事務	支持事務	不支持
鎖	行鎖	表鎖
B樹索引	支持	支持
全文索引	不支持	支持
外鍵	支持（惟一支持的）	不支持

那麼如何選擇兩種存儲引擎，能夠從如下幾個方面考慮。

事務：

若是應用須要事務支持，那麼InnoDB是較號的選擇。若是不須要事務，而且主要是select和insert操做，則MyISAM是個不錯的選擇，好比日誌型系統。

備份：

備份的需求也會影響存儲引擎的選擇。若是須要在線熱備份，則選擇InnoDB就是基本的要求。

數據恢復：

數據量比較大的時候，系統崩潰後如何快速恢復是一個須要考慮的額問題。相對而言，MyISAM崩潰後發生損壞的機率比InnoDB高的多，並且恢復也慢，所以即便不須要事務，一般也應該選擇InnoDB引擎。

對於不一樣存儲引擎的選擇，對數據庫的性能都會帶來較大的影響，除了MySQL默認支持的存儲引擎以外，還有不少第三方存儲引擎。

一般狀況下，致使SQL性能降低還有如下幾方面：

查詢語句編寫不合理
索引失效
關聯查詢數據太多
服務器的參數設置問題

下面總結一些關於SQL優化方面的內容。

四，數據類型優化

4.1，數據類型的選擇原則。

更小的一般更好：

通常狀況選擇能夠正確存儲數據的最小數據類型。由於更小的數據類型一般更快，由於佔用磁盤、內存和CPU緩存會越小。

簡單就好：

簡單數據類型的操做一般須要更少的CPU消耗。

儘可能避免NULL：

通常狀況下最好執行列爲NOT NULL，除非特殊須要。由於若是查詢中包含爲NULL的列，從SQL優化角度考慮，對建立索引，索引的統計等都會帶來較大的困難，且優化起來也是較爲複雜的，所以說盡可能避免NULL值。

4.2，具體類型的選擇

1，整數類型：選擇合適的字節大小做爲數據的類型。

tinyint：8位字節
smallint：16位字節
mediumint：24位字節
int：32位字節
bigint：64位字節
unsigned屬性：添加unsigned屬性表示該字段不容許負數，正數的上限大體能夠提升一倍。
好比tinyint unsigned能夠存儲0-255的範圍。而tinyint是-128~127的範圍。有符號和無符號佔用空間大小相同，具備相同的性能。

int(11)是指定整數類型的寬度，它不會限制值得合法範圍，對於存儲和計算而言，int(1)和int(20)沒什麼區別

2，實數類型

float：32位
double：64位
decimal：decimel須要額外的空間和計算開銷，因此應該儘可能只對小數進行精準計算時才使用decimel，例如存儲金額。

3，字符串類型

varchar：是可變長的字符串，它比定長更節省空間。varchar須要使用1~2個額外字節記錄字符串的長度。varchar節省了存儲空間，因此對性能也有幫助，
可是因爲長度可變，在update時可能使行變得比原來更長，這就致使須要進行額外的工做。至於如何進行空間增加取決於不一樣的存儲引擎。當字符串列的最大長度比平均長度要大不少，而且列的更新不多時比較適合使用varchar。
char：定長字符串，mysql根據定義的字符串長度分配足夠的空間。
char很是適合存儲很短的字符串，或者值得長度都很接近的字段。例如char很是適合存放密碼的md5值，由於這是一個定長的值。對於常常變動的字段，使用char也更爲合適，由於定長的char類型不容易產生碎片。對於很是短的列，存儲空間也更有優點，好比char(1)只會佔用一個字節，而varchar(1)會用到兩個字節，由於還有一個字節用來記錄varchar的長度。
blob和text：二者都是用於存儲很大的數據而設計的字符串數據類型，
分別採用二進制和字符的方式存儲。

varchar(5)和varchar(200)存儲'hello'的空間開銷是同樣的。可是varchar(5)對性能提高有很大的優點。更長的列會消耗更多的內存，由於mysql一般會分配固定大小的內存塊來保存內部值。尤爲是使用內存臨時表進行排序等操做時會特別糟糕。因此最好的策略是隻分配真正須要的空間

4，時間和日期類型

datetime：能保存大範圍的值，從1001年到9999年，精度爲秒。它把日期和時間封裝到YYYYMMDDHHMMSS的整數中，使用8個字節的存儲空間。
timestamp：保存了從1970年1月1日以來的毫秒數，timestamp只使用了4個字節的存儲空間，所以它的範圍比datetime小的多；可是隻能表示從1970年到2038年。另外timestamp也依賴於時區。