基於索引的sql語句優化之降龍十八掌
** 塵封往事
引用功能被關閉了。
前言
客 服業務受到sql語句的影響非常大，在規模比較大的局點，往往因為乙個小的sql語句不夠優化，導致資料庫效能急劇下降，小型機idle所剩無幾，應用服 務器斷連、超時，嚴重影響業務的正常執行。因此，稱低效的sql語句為客服業務的『惡龍』並不過分。資料庫的優化方法有很多種，在應用層來說，主要是基於 索引的優化。本次秘笈根據實際的工作經驗，在研發原來已有的方法的基礎上，進行了一些擴充，總結了基於索引的sql語句優化的降龍十八掌，希望有一天你能 用其中一掌來馴服客服業務中橫行的『惡龍』。
總綱 建立必要的索引
這 次傳授的降龍十八掌，總綱只有一句話：建立必要的索引，這就是後面降龍十八掌的內功基礎。這一點看似容易實際卻很難。難就難在如何判斷哪些索引是必要的， 哪些又是不必要的。判斷的最終標準是看這些索引是否對我們的資料庫效能有所幫助。具體到方法上，就必須熟悉資料庫應用程式中的所有sql語句，從中統計出 常用的可能對效能有影響的部分sql，分析、歸納出作為where條件子句的字段及其組合方式；在這一基礎上可以初步判斷出哪些表的哪些字段應該建立索 引。其次，必須熟悉應用程式。必須了解哪些表是資料操作頻繁的表；哪些表經常與其他表進行連線；哪些表中的資料量可能很大；對於資料量大的表，其中各個字 段的資料分布情況如何；等等。對於滿足以上條件的這些表，必須重點關注，因為在這些表上的索引，將對sql語句的效能產生舉足輕重的影響。不過下面還是總 結了一下降龍十八掌內功的入門基礎，建立索引常用的規則如下：
1、表的主鍵、外來鍵必須有索引；
2、資料量超過300的表應該有索引；
3、經常與其他表進行連線的表，在連線欄位上應該建立索引；
4、經常出現在where子句中的字段，特別是大表的字段，應該建立索引；
5、索引應該建在選擇性高的字段上；
6、索引應該建在小字段上，對於大的文字字段甚至超長字段，不要建索引；
7、復合索引的建立需要進行仔細分析；盡量考慮用單字段索引代替：
a、正確選擇復合索引中的主列字段，一般是選擇性較好的字段；
b、復合索引的幾個字段是否經常同時以and方式出現在where子句中？單字段查詢是否極少甚至沒有？如果是，則可以建立復合索引；否則考慮單字段索引；
c、如果復合索引中包含的字段經常單獨出現在where子句中，則分解為多個單字段索引；
d、如果復合索引所包含的字段超過3個，那麼仔細考慮其必要性，考慮減少復合的字段；
e、如果既有單字段索引，又有這幾個欄位上的復合索引，一般可以刪除復合索引；
8、頻繁進行資料操作的表，不要建立太多的索引；
9、刪除無用的索引，避免對執行計畫造成負面影響；
以 上是一些普遍的建立索引時的判斷依據。一言以蔽之，索引的建立必須慎重，對每個索引的必要性都應該經過仔細分析，要有建立的依據。因為太多的索引與不充 分、不正確的索引對效能都毫無益處：在表上建立的每個索引都會增加儲存開銷，索引對於插入、刪除、更新操作也會增加處理上的開銷。 另外，過多的復合索引，在有單字段索引的情況下，一般都是沒有存在價值的；相反，還會降低資料增加刪除時的效能，特別是對頻繁更新的表來說，負面影響更 大。
SQL優化之建立索引二
降龍十八掌 第一掌 避免對列的操作 任何對列的操作都可能導致全表掃瞄，這裡所謂的操作包括資料庫函式 計算表示式等等，查詢時要盡可能將操作移至等式的右邊，甚至去掉函式。例1 下列sql條件語句中的列都建有恰當的索引，但30萬行資料情況下執行速度卻非常慢 select from record where...
SQL優化之建立索引五
第十四掌 使用基於函式的索引 前面談到任何對列的操作都可能導致全表掃瞄，例如 select from emp where substr ename,1,2 sm 但是這種查詢在客服系統又經常使用，我們可以建立乙個帶有substr函式的基於函式的索引，create index emp ename su...
SQL優化之建立索引六
第十八掌 決定使用全表掃瞄還是使用索引 和 所有的秘笈一樣，最後一招都會又回到起點，最後我們來討論一下是否需要建立索引，也許進行全表掃瞄更快。在大多數情況下，全表掃瞄可能會導致更多的物理磁 盤輸入輸出，但是全表掃瞄有時又可能會因為高度並行化的存在而執行的更快。如果查詢的表完全沒有順序，那麼乙個要返回...