mysql 高性能日記之索引（持續更新）

本文僅限於本身讀寫的筆記，須要具備必定 mysql（inodb,myisam 引擎）基礎的高端玩家，不感興趣的玩家們就不用在乎了

Inodb 引擎

1，每一個新建索引，都須要考慮清楚看是不是必須的，不少新建的索引不只不會提升 sql 語句的效率，反而會增長維護索引的成本

     對於 Inodb 的 B-Tree，若是是非聚簇索引，每次檢索都須要進行兩次（自己+主鍵，此處不過多解釋），因此當存在索引 (B)，A是主鍵，就沒有必要再創建索引（B, A），除非須要 order by a 才須要用到組合索引。

MyISAM 引擎

1，默認開啓索引前綴壓縮，對於 CPU 密集型業務須要手動關閉該功能，MyISAM 爲了下降 IO 的壓力，將索引塊進行前綴壓縮，好比 "aaaa"-"aaaabbb" 兩個索引塊在內存中爲 "aaaa"-"4.bbb"，解壓時會消耗必定的 CPU 算力。

公共問題

1，擴展索引時，也須要考慮是否會影響到舊索引的性能

     本來存在索引(A，qps 超高)，爲了整合索引，將 B(VCHAR1024) 加入原索引構成新索引（A, B）,因爲加入新的列（新列超長，會極大影響到舊查詢效率）。

2，對於兩個表 A {primary_key: app_id，column:xxx}；B {primary_key: account_id，app_id}，其中 A 表的 app_id 和 B 表的 app_id 是同一個屬性，若是業務給定一個 account_id，須要返回這個用戶下的全部 app 信息，相信很多同窗會這樣寫

      a. select * from A where app_id in (select app_id from B where account_id = %d)

      b. select * from A join (select app_id from B where account_id = %d) as C using (app_id)

      上述兩種寫法應該是大部分開發者都會優先考慮的 sql 語句（正向思惟），但 Mysql 優化器並不會優化上面兩種 sql 語句，而是會按從左到右的順序，現對 A 表進行全表遍歷，而後與 B 表查出的數據進行 using 比較返回有效數據。因此須要你們反向去寫 sql 語句。

      c. select * from B where account_id = %d join (select * from A) as C using (app_id)

      固然，若是在兩個表中都沒有可供 where 使用的有效索引，那就老老實實全表遍歷吧。