MySQL性能管理及架構設計（二）：數據庫結構優化、高可用架構設計、數據庫索引優化

1、數據庫結構優化（很是重要）

1.1 數據庫結構優化目的

一、減小數據冗餘：（數據冗餘是指在數據庫中存在相同的數據，或者某些數據能夠由其餘數據計算獲得），注意，儘可能減小不表明徹底避免數據冗餘；

二、儘可能避免數據維護中出現更新，插入和刪除異常：

總結：要避免異常，須要對數據庫結構進行範式化設計。

三、節約數據存儲空間。

四、提升查詢效率。

1.2 數據庫結構設計步驟

一、需求分析：全面瞭解產品設計的存儲需求、數據處理需求、數據安全性與完整性；

二、邏輯設計（重要）：設計數據的邏輯存儲結構。數據實體之間的邏輯關係，解決數據冗餘和數據維護異常。數據範式能夠幫助咱們設計；

三、物理設計：表結構設計，存儲引擎與列的數據類型；

四、維護優化：索引優化、存儲結構優化。

1.3 數據庫範式設計與反範式化

ref="https://segmentfault.com/a/1190000013695030">傳送門：數據庫邏輯設計之三大範式通俗理解，一看就懂，書上說的太晦澀

1.4 物理設計

f="https://segmentfault.com/a/1190000010012140">相關傳送門：MySQL中字段類型與合理的選擇字段類型；int(11)最大長度是多少？，varchar最大長度是多少

2、高可用架構設計

2.1 讀寫分離

MaxScale：實現MySQL讀寫分離與負載均衡的中間件利器

3、數據庫索引優化（很是重要）

3.1 兩種主要數據結構：B-tree和Hash

3.1.1 B-tree結構

B-tree索引的限制：

3.1.2 Hash結構

Hash索引的限制：

• Hash索引必須進行二次查找
• Hash索引沒法用於排序
• Hash索引不支持部分索引查找也不支持範圍查找
• Hash索引中Hash碼的計算可能存在Hash衝突，不適合重複值很高的列，如性別，身份證比較合適。

3.1.3 MySQL常見索引和各類索引區別

PRIMARY KEY（主鍵索引）  ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) 
UNIQUE(惟一索引)     ALTER TABLE `table_name` ADD UNIQUE (`column`)
INDEX(普通索引)     ALTER TABLE `table_name` ADD INDEX index_name ( `column` ) 
FULLTEXT(全文索引)      ALTER TABLE `table_name` ADD FULLTEXT ( `column` )
組合索引   ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

1. 普通索引：最基本的索引，沒有任何限制
2. 惟一索引：與"普通索引"相似，不一樣的就是：索引列的值必須惟一，但容許有空值。
3. 主鍵索引：它 是一種特殊的惟一索引，不容許有空值。
4. 全文索引：僅可用於 MyISAM 表，針對較大的數據，生成全文索引很耗時好空間。
5. 組合索引：爲了更多的提升mysql效率可創建組合索引，遵循」最左前綴「原則。

3.2 使用索引好處和索引缺陷

3.2.1 爲何要使用索引

一、索引大大減小了存儲引擎須要掃描的數據量；

二、索引能夠幫助咱們進行排序以免使用臨時表；

三、索引能夠把隨機I/O變爲順序I/O。

3.2.2 索引不是越多越好

一、索引會增長寫操做的成本；

二、太多的索引會增長查詢優化器的選擇時間。

索引就比如一本書的目錄，它會讓你更快的找到內容，顯然目錄（索引）並非越多越好，假如這本書1000頁，而有500頁是目錄，它固然效率低，目錄是要佔紙張的,而索引是要佔磁盤空間的。

3.3 索引優化策略

3.3.1 索引列上不能使用表達式和函數

3.3.2 前綴索引和索引列的選擇性

Innodb索引列最大寬度爲 667個字節( utf-8 差很少 255個字符), MyIsam索引類寬度最大爲 1000個字節，因而出現前綴索引，索引的選擇性。

對於列的值較長，好比BLOB、TEXT、VARCHAR，就必須創建前綴索引，即將值的前一部分做爲索引。這樣既能夠節約空間，又能夠提升查詢效率。但沒法使用前綴索引作 ORDER BY 和 GROUP BY，也沒法使用前綴索引作覆蓋掃描。

語法： ALTER TABLE table_name ADD KEY(column_name(prefix_length))

如何選擇索引列的順序：

一、常常會被使用到的列優先（選擇性差的列不適合，如性別，查詢優化器可能會認爲全表掃描性能更好）；

二、選擇性高的列優先；

三、寬度小的列優先（一頁中存儲的索引越多，下降I/O，查找越快）；

3.3.3 組合/聯合索引策略

若是索引了多列，要遵照最左前綴法則。指的是查詢從索引的最左前列開始而且不跳過索引中的列。
"http://www.uml.org.cn/sjjm/201107145.asp#nav-4-2">深刻理解請移步：最左前綴原理與相關優化

3.3.4 覆蓋索引策略

跟組合索引有點相似，若是索引包含全部知足查詢須要的數據的索引則成爲覆蓋索引(Covering Index)，也就是平時所說的不須要回表操做。即索引的葉子節點上面包含了他們索引的數據(hash索引不能夠)。

判斷標準：使用explain，能夠經過輸出的extra列來判斷，對於一個索引覆蓋查詢，顯示爲using index,MySQL查詢優化器在執行查詢前會決定是否有索引覆蓋查詢。

優勢:

一、能夠優化緩存,減小磁盤IO操做；
   二、能夠減小隨機IO,變隨機IO操做變爲順序IO操做；
   三、能夠避免對InnoDB主鍵索引的二次查詢；
   四、能夠避免MyISAM表進行系統調用；

沒法使用覆蓋索引的狀況：

一、存儲引擎不支持覆蓋索引；
   二、查詢中使用了太多的列（如SELECT * ）；
   三、使用了雙%號的like查詢（底層API所限制）；

mysql高效索引之覆蓋索引

3.3.5 SQL索引優化總結口訣（套路重點）

全值匹配我最愛，最左前綴要遵照；
帶頭大哥不能死，中間兄弟不能斷；
索引列上不計算，範圍以後全失效；
LIKE百分寫最右，覆蓋索引不寫 *；
不等空值還有or，索引失效要少用；
字符單引不可丟，SQL高級也不難 ；

MySQL高級-索引優化

3.4 使用索引來優化查詢

3.4.1 利用索引排序

一、group by 實質是先排序後分組，遵守索引的最佳左前綴。；

二、索引中全部列的方向(升序、降序)和Order By子句徹底一致；

三、當沒法使用索引列，增大max_length_for_sort_data參數的設置+增大sort_buffer_size參數的設置；

四、若是最左列使用了範圍，則排序會失效；

五、where 高於having，能寫在where限定的條件就不要去having去限定了

3.5 索引的維護和優化

3.5.1 刪除重複索引

注：主鍵約束至關於(惟一約束 + 非空約束)

一張表中最多有一個主鍵約束,若是設置多個主鍵,就會出現以下提示：Multiple primary key defined!!!

3.5.2 刪除冗餘索引

檢查工具：pt-duplicate-key-checker

ef="http://www.uml.org.cn/sjjm/201107145.asp#nav-4-2">擴展閱讀： MySQL索引背後的數據結構及算法原理

explain 查詢計劃Using where：表示優化器須要經過索引回表查詢數據；
Using index：表示直接訪問索引就足夠獲取到所須要的數據，不須要經過索引回表，如覆蓋索引；

ref="https://zhuanlan.zhihu.com/p/74826503">下一篇：MySQL性能管理及架構設計（三）：SQL查詢優化、分庫分表 - 完結篇

原做者：：唐成勇
原文連接： 人類身份驗證 - SegmentFault
原出處：思否