MySQL效能管理及架構設計（二）：資料庫結構優化、高可用架構設計、資料庫索引優化

阿新 • • 發佈：2019-02-09

一、資料庫結構優化（`非常重要`）

1.1 資料庫結構優化目的

1、減少資料冗餘：（資料冗餘是指在資料庫中存在相同的資料，或者某些資料可以由其他資料計算得到），注意，儘量減少不代表完全避免資料冗餘；

2、儘量避免資料維護中出現更新，插入和刪除異常：

總結：要避免異常，需要對資料庫結構進行正規化化設計。

3、節約資料儲存空間。

4、提高查詢效率。

1.2 資料庫結構設計步驟

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

2、邏輯設計（重要）：設計資料的邏輯儲存結構。資料實體之間的邏輯關係，解決資料冗餘和資料維護異常。資料正規化可以幫助我們設計；

3、物理設計：表結構設計，儲存引擎與列的資料型別；

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

1.3 資料庫正規化設計與反正規化化

1.4 物理設計

二、高可用架構設計

2.1 讀寫分離

三、資料庫索引優化（`非常重要`）

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` )

普通索引：最基本的索引，沒有任何限制
唯一索引：與"普通索引"類似，不同的就是：索引列的值必須唯一，但允許有空值。
主鍵索引：它是一種特殊的唯一索引，不允許有空值。
全文索引：僅可用於 MyISAM 表，針對較大的資料，生成全文索引很耗時好空間。
組合索引：為了更多的提高mysql效率可建立組合索引，遵循”最左字首“原則。

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

3.2.1 為什麼要使用索引

1、索引大大減少了儲存引擎需要掃描的資料量；

2、索引可以幫助我們進行排序以避免使用臨時表；

3、索引可以把隨機I/O變為順序I/O。

3.2.2 索引不是越多越好

1、索引會增加寫操作的成本；

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))

3.3.3 聯合索引策略

如何選擇索引列的順序：

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

2、選擇性高的列優先；

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

3.3.4 覆蓋索引策略

跟聯合索引有點類似，如果索引包含所有滿足查詢需要的資料的索引則成為覆蓋索引(Covering Index)，也就是平時所說的不需要回表操作。即索引的葉子節點上面包含了他們索引的資料(hash索引不可以)。

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

優點:

    1、可以優化快取,減少磁碟IO操作；
    2、可以減少隨機IO,變隨機IO操作變為順序IO操作；
    3、可以避免對InnoDB主鍵索引的二次查詢；
    4、可以避免MyISAM表進行系統呼叫；

無法使用覆蓋索引的情況：

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

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

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

3.4 使用索引來優化查詢

3.4.1 利用索引排序

1、group by 實質是先排序後分組，遵照索引的最佳左字首。；

2、索引中所有列的方向(升序、降序)和Order By子句完全一致；

3、當無法使用索引列，增大max_length_for_sort_data引數的設定+增大sort_buffer_size引數的設定；

4、如果最左列使用了範圍，則排序會失效；

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

3.5 索引的維護和優化

3.5.1 刪除重複索引

注：主鍵約束相當於(唯一約束 + 非空約束)

一張表中最多有一個主鍵約束,如果設定多個主鍵,就會出現如下提示：Multiple primary key defined!!!

3.5.2 刪除冗餘索引

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

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

原文地址：https://segmentfault.com/a/1190000013746118