1.索引分類：
唯一/非唯
一、聚集/非聚集、主鍵索引（是特殊的唯一索引）、聯合索引。
2.聚集/非聚集的區別
①定義：聚集索引，表記錄的物理順序與鍵的索引排列順序一致（我的理解是：索引和記錄按順序排）；非聚集索引，表記錄的物理順序與鍵的索引排列順序不一致（我的理解是：索引和記錄不按順序排）。
②優缺點：聚集索引，查詢速度快，一旦第乙個被找到，後續的索引記錄就被找到了；但修改慢，一旦修改乙個值，就需要維護索引的相應順序，導致效率低下。所以適用場景為範圍查詢、包含小數目的不同值。
非聚集索引，修改速度快，不用維護索引的順序；適用場景為包含大數目的不同值、頻繁更新的列。
1.如果條件中有or，即使其中有條件帶索引也不會使用(這也是為什麼盡量少用or的原因)，要想同時使用or和索引就需要在or條件的每一列加索引。
2.like語句以%開頭的，索引會失效，比如%aaa。以%結尾的不會失效。
3.如果列型別是字串，那一定要在條件中將資料使用引號引用起來,否則不使用索引。
4.如果mysql估計使用全表掃瞄要比使用索引快,則不使用索引。
此外，檢視索引的使用情況：show status like 『handler_read%』;
1.避免全表掃瞄，在where、order by 、group by涉及的列上建索引。
2.可以檢視語句的執行計畫，用來提高優化效率（比如我們建立了乙個聯合索引a,b,c 當我的where語句後面只用了b=』xx』,我們在執行計畫裡可以看出聯合索引沒有用上，我們在where後加上了a=『xx』,b=『xx』時索引就用上了，這樣效率就提高了）。
重要的字段:
id: select 查詢的識別符號. 每個 select 都會自動分配乙個唯一的識別符號.
select_type: select 查詢的型別.
table: 查詢的是哪個表
partitions: 匹配的分割槽
type: join 型別
possible_keys: 此次查詢中可能選用的索引
key: 此次查詢中確切使用到的索引.
ref: 哪個欄位或常數與 key 一起被使用
rows: 顯示此查詢一共掃瞄了多少行. 這個是乙個估計值.
filtered: 表示此查詢條件所過濾的資料的百分比
extra: 額外的資訊
①垂直拆分：主鍵和常用的列放乙個表，不常用的放乙個表。
3.分割槽分庫。
資料庫的訪問量大了怎麼辦？主從複製、讀寫分離、redis快取、資料庫分表分區分表、sql優化。
一、innodb
1.索引檔案就是資料檔案（索引葉節點儲存的data值）
2.輔助索引葉節點儲存的主鍵索引的值，使用輔助索引時要檢索兩邊索引，要先檢索主鍵的值，再檢索相應記錄。
二、myisam
1.資料檔案和索引檔案分離（葉節點儲存資料的位址）。
2.輔助索引幾乎和主鍵索引一樣，只是輔助索引不要求鍵唯一。
三、幾點區別
1.myisam的一般情況下效能較好，innodb支援事務（針對修改操作）。
2.myisam不支援外來鍵，innodb支援外來鍵。
3.前者支援表級鎖，後者支援表級鎖和行級鎖，預設行級鎖。行級鎖提高了併發效能。innodb適合插入和更新操作，myisam適合頻繁查詢情況。
4.前者允許沒有主鍵，後者若密友主鍵會自動生成乙個主鍵（使用者不可見）。
資料庫SQL，索引優化
一 mysql 索引分為兩種結構 1 hash索引 a 缺點 i.只支援等值比較 ii.無序，不支援範圍查詢 iii.組合索引時，無法單獨使用 iv.通過 hash 命中後，資料庫需要再次對比 v.hash 衝突量過大的情況下，效能較差 2 btree索引 a 是否要支援事務，如果要請選擇innod...
12 優化資料庫 優化SQL語句 索引
第 一 優化索引 sql語句 分析慢查詢 第二 設計表的時候嚴格按照資料庫的設計正規化來設計資料庫 第三 我們可以加上redis快取，將經常被訪問到的資料，但是不需要經常變化的資料放入至redis快取伺服器裡面 第四 還可優化硬體，在硬體層面，我們可以使用更好的一些硬碟 固態硬碟 使用一些磁碟陣列技...
資料庫引擎優化顧問優化資料庫
現在一直在做的專案，資料量相對也不小，開始的時候沒有覺得，因為是剛開始，資料量還很小，在程式使用過程中速度還挺快，但是隨著資料量的不停的增長，發現程式越來越慢，甚至出現了超時的問題，因此要對程式和資料庫進行優化，前期專案比較緊，沒有針對大資料量業務進行分析設計，所以索引等相關優化沒有做到位，通過後期...