注:這個是我的思考路徑結合了上述文章的觀點，用自問自答的方式解答。
q1:什麼時候使用索引？
a:查詢資料量特別大的表，資料量小的全表掃瞄效率更高。
q2:如何去優化？
a：如果不考慮硬體和資料庫的部署調參等。那麼作為一般的使用人員，能優化的只有你的sql語句。那麼單錶查詢肯定要篩選資料，使得表盡可能的小。多表連線時就讓連線的每張表盡可能的先where篩選。還需要去走索引。
q3:如何建立索引？(查詢+排序兩個方面)
a:建立的索引應該區分度高（重複度非常低），或者自增列。常常用來查詢或者排序的列也要考慮是否建立索引。
q4：建立怎樣的索引?
a:1)b-tree索引
b-tree可以對常見的大小比較符，between，in，以及不以%開頭的like使用索引。
b-tree通常意味著所有的值都是順序遍歷儲存的，並且每乙個葉子頁到根的距離相同很適合查詢
範圍資料
2）聚簇索引(cluster index)
特點：乙個表只能有乙個
innodb對主鍵建立聚簇索引
如果沒有指定主鍵，innodb會用乙個具有唯一且非空值的索引來代替
如果不存在這樣的索引，innodb會定義乙個隱藏的主鍵，然後對其建立聚簇索引（最好設定乙個自增列，然後對其使用**主鍵的方法建立聚簇索引）
3）hash索引
特點：雜湊索引基於雜湊表實現，只有精確索引所有列的查詢才有效。
對於每乙個資料，儲存引擎都會對所有的索引列計算乙個雜湊碼。雜湊索引將所有的雜湊碼存在索引中，並在雜湊表中儲存每個資料的指標。
速度很快，但是讀取資料需要通過指標調取，這會影響效能，另外就是hash衝突的問題。
4）空間索引
5）全文（full-text）索引
q5:如何確定sql語句的優化空間？
q6：索引的型別？
a：大致分為單列索引和組合索引。
1）普通索引
最基本的索引，他應該是最經常出現在where條件中或者排序中的資料列。（允許出現重複列）
2）唯一索引
特殊的普通索引，唯一的區別就是唯一索引列的值不重複（唯一），允許為空。若是組合索引，則列值的組合必須唯一
3）主鍵索引
特殊的唯一索引，不允許空值，乙個表也只能出現乙個主鍵。
4）組合索引
由多個列組成的索引。需要注意最左字首匹配（將區分度高的放在最左，往右逐次降低）
q7：使用索引的時機？
a：一般來說，出現在where和join中的列是需要建立索引的。如果是範圍查詢或模糊匹配，可以考慮b-tree索引。
q8：如何設計索引？
a： 1）索引字段盡量使用數字型（能不用字串型就不用，字串比較需要逐字元比較，而數字僅需要比較一次，另外會有更大的儲存開銷）
2）盡量不要讓字段的預設值為null。（空值的列很難查詢優化，這會讓索引，索引的統計資訊以及比較運算更加複雜）
3）字首索引和索引選擇性。（對於字串列的索引，可以指定乙個字首長度。這樣使得索引更小更快。但是也無法使用字首索引進行order by 和group by，和覆蓋掃瞄的操作）。在這裡，選擇合適長度的作為字首既可以滿足低的空間開銷，也能滿足絕大大大多數的查詢區分需求。
4）使用唯一索引。如果該列的值型別足夠多，那麼效果越好，如生日或者乾脆id，但是如果是相比的m或者f，那麼只會得到大約一半的行。
5）使用組合索引代替多個列的索引。
6）注意重複/冗餘的索引和不使用的索引。（對於這些索引，如果你確定基本上不怎麼用，就可以直接刪除，因為這些索引會影響占用物理空間和影響更新表的效能）
q8：如何使用索引？
a：1）如果對較大的文字進行搜尋，使用全文索引而不要使用like "%....%"
2）like語句不要使用 % 開頭
3）不要在列上進行運算，索引不能是表示式的一部分或者函式的引數
4）盡量不使用not in，!=,<>操作。
5）or條件。盡量避免使用or（用in來代替or）
6）區分度高的條件放最左。=，範圍，模糊查詢的順序來。
7）不要用select *，最好是具體的字段。
8）order by使用索引最左前列
9）對於連續的值，用between代替in
10）where的=左邊條件不用表示式或者函式，把這些放=右邊吧
q9：如何確定效能？
a：索引效能測試和索引優化
首先要表的記錄足夠多。如果表太小，瞬間出了結果，那麼沒有明顯的效率感受，最好表要足夠的大。
1）explain 可以分析
2）handler_read_key分析
效能優化 SQL優化
1.列型別盡量定義成數值型別，且長度盡可能短，如主鍵和外來鍵，型別字段等等 2.建立單列索引 3.根據需要建立多列聯合索引 當單個列過濾之後還有很多資料，那麼索引的效率將會比較低，即列的區分度較低，那麼如果在多個列上建立索引，那麼多個列的區分度就大多了，將會有顯著的效率提高。4.根據業務場景建立覆蓋...
SQL效能優化
postgre資料表資料比較多的情況下，使用模糊查詢效能很差，但是使用函式反而快了，返回資料一致，有點不解 warning表2688133條資料，warning message表6954788條資料 這個sql執行老半天都沒反映，耗時169904 ms select count 1 from war...
sql效能優化
任何平台的sql開發者都有自身的困惑，似乎他們一直糾纏在do while迴圈裡，這個迴圈讓他們不斷地重複同樣的錯誤。這是因為資料庫的發展依然不夠成熟。當然，商們也在不斷進步，但是他們還是需要處理更嚴重的問題。併發性，資源管理，空間管理和速度依然制約著sql開發者對開發平台的選擇。我並不期望sql開發...