『壹』 sql優化及原理詳解，五分鍾讀懂sql優化
在我而言這算是一個復習，然後總結出來給大家當個教材吧。
我也是看視頻總結出來的筆記，所以說的都很簡單和淺薄。有不全面或者偏頗的地方歡迎指出，共同交流進步哈。（因為我當時是看視頻總結的筆記，所以可能說的比較雜亂，我盡量寫的分明一點，在最後會附上筆記，忽略我字丑）
索引是什麼呢？它相當於字典的目錄。
索引：index是幫助mysql高效獲取數據的數據結構，索引是數據結構（樹，默認是B樹），hash等。
索引的弊端: 事物都是兩面的，有利必然有弊。
索引的優勢： 索引有這么多弊端我們還使用的原因是因為優大於劣。
索引的分類：
舉個小例子讓大家更理解復合索引：如果我把一個表中name，age這兩個列做成復合索引（注意順序很重要）。那麼我們形成的目錄一級目錄是name，二級目錄是age。在name相同時才會age再形成目錄。因為它本身的排序不是像目錄一樣一行一行列出來的，所以我們盡量用目錄來想像它比較好理解。下面是圖解：
有幾點注意的事項：
這里說一下，上面說的方法都是原生的sql，比如我現在習慣使用navicat，所以可以直接操作。。爽的不行。
然後刪除查詢也都是直接可視的，方便的不得了。就不多說了。
mysql做例子，還有個引擎是可以優化的。mysql中引擎分兩種：
sql優化等級：
上面說的這些等級在explain中可以看到。
單表優化常用方法：
多表優化常用方法：
因為上面也提到了b樹，所以還是單獨聊聊吧。其實我也不是很理解。只能說一個淺顯的認識而已。這里也就是簡單的說一下。
首先，B樹不僅可以二叉，還可以三叉，多叉。而只要大於二叉的都叫做BTree。
據說三層BTree可以存放上百萬數據。
BTree一般都指B+樹，數據全部存放在葉節點中。（這里簡單的一個三叉樹圖）
好了，就寫到這里吧，希望日後演算法的知識會的更多以後能把B樹這個坑填完~~~然後有不同意見或者自己理解的可以留言或者私聊。
全文手打，如果你覺得對你有幫助麻煩點個贊點個關注啥的~~
『貳』 sql語句性能如何優化
如何加快查詢速度?
1、升級硬體
2、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。
3、擴大伺服器的內存
4、增加伺服器CPU個數
5、對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能
6、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
7、查詢時不要返回不需要的行、列
8、用select top 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行
9、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數
10、一般在GROUP BY 個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：
select的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group By 個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那麼用Distinct更快
11、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
『叄』 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
『肆』 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
『伍』 sql調優的幾種方式
你好，
SQL優化的一些方法
1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描。
3.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描。
5.in 和 not in 也要慎用，否則會導致全表掃描，
6.下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。
8.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
『陸』 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
『柒』 落落老師高級oracle sql優化班 怎麼樣
您好，很高興為您解答。
SQL優化簡介
一般在應用中， 糟糕的SQL語句是造成系統性能低下的最主要原因，例如大小寫的不統一、同樣的SQL語句不同的寫法等。而且，隨著數據量的增加，情況會變得越來越嚴重。（題外話：優秀的Oracle資料庫優化人才，是任何公司都稀缺的）
課程模塊 詳細章節內容
SQL高級優化
1 索引原理
2 基本概念
2.1 列基數與列選擇性(區別列基數與執行計劃的基數)
2.2 直方圖
2.3 集群因子
3 統計信息
3.1 統計信息的最佳采樣率
3.2 穩定系統收集統計信息最佳方法
3.3 如何查看統計信息是否過期
3.4 如何查看錶的采樣率
3.5 定製統計信息收集策略
3.6 快速檢測SQL語句中統計信息過期的表的腳本
4. 執行計劃
4.1 查看執行計劃的方法
4.2 解釋為什麼不要用工具(TOAL/PLSQL DEV/EM)等查看執行計劃
4.3 詳細解釋執行計劃，教你徹底讀懂執行計劃
4.4 游標移動法則閱讀執行計劃
5. 訪問路徑(這部分會結合等待事件詳細解釋)
6. 連接方式
6.1 徹底搞懂嵌套循環，如何判斷錯誤的嵌套循環
6.2 徹底搞懂哈希連接，如何優化哈希連接
6.3 徹底搞懂排序合並連接，什麼情況下必須用排序合並連接
6.4 徹底搞懂笛卡爾連接，如何判斷正確的笛卡爾連接，如何判斷錯誤的笛卡爾連接
6.5 徹底搞懂外連接，掌握外連接的如何影響SQL性能
6.6 徹底搞懂半連接，掌握半連接優化方法以及底層原理
6.7 徹底搞懂反連接，掌握反連接優化方法以及底層原理
6.8 徹底搞懂標量子查詢，掌握標量子查詢優化方法以及底層原理
7. 成本計算
7.1 你優化SQL還在看COST嗎？如果你還在看，說明你沒入門
7.2 為什麼COST很小，SQL卻跑得很慢？
7.3 手把手教你計算全表掃描cost
7.4 手把手教你計算索引掃描cost
7.5 手把手教你嵌套循環cost
8. 查詢轉換
8.1 徹底搞懂 FILTER 底層原理，如何判斷正確的FILTER，如何判斷錯誤的FILTER
8.2 什麼時候該用in/not in,什麼時候該用exists/not exists?
我看到某某書,某某網站，說什麼情況下用in,什麼情況下用exists
拋棄這些錯誤的結論吧，我們來研究它的底層原理
8.4 徹底搞懂subquery unnesting,掌握subquery unnesting優化技巧
8.5 徹底搞懂vier merge,掌握view merge 優化技巧
8.6 徹底搞懂pushing predicate,掌握pushing predicate 優化技巧
9. 優化技巧
9.1 查看執行計劃真實的基數
9.2 union代替or的情況
9.3 分頁語句優化技巧
9.4 利用分析函數優化SQL
9.5 超大表與超小表HASH JOIN優化方法
9.6 <>優化技巧
9.7 函數索引優化技巧
9.8 LIKE '%XXX%' 優化技巧
9.9 如何根據執行計劃建立索引？
9.10 組合索引怎麼選擇引導列？
10. SQL優化實戰(講課中也會出現一些案例)
10.1 收集統計信息，重建索引優化案例，如何發現統計信息過期？如何判斷索引需要重建？
10.2 組合索引優化案例
10.3 利用並行優化案例
10.4 基數估算不準優化案例
10.5 直方圖優化案例(嵌套循環優化案例)
10.6 with as優化經典案例
10.7 subquery unnesting 優化經典案例(多個)
10.8 view merge 優化經典案例
10.9 謂詞推入優化經典案例
10.10 Merge優化update 案例
10.11 亂用bitmap優化案例
10.12 利用11g新特徵擴展統計信息優化案例
10.13 利用分區優化SQL案例
10.14 利用local索引優化SQL案例
10.15 化整為零，各個擊破優化案例
10.16 利用rowid優化案例
10.17 手工分配HASH AREA,SORT AREA 優化案例
10.18 標量子查詢優化案例
10.19 利用ASH監控優化案例
10.20 分頁優化案例
10.21 物化視圖降低SQL性能案例
10.22 利用分析函數優化SQL案例
10.23 SQL優化高手之路---把你腦袋當成CBO
11.贈送一個經典表設計優化案例
如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】
希望我的回答對您有所幫助，望採納！
~ O(∩_∩)O~
『捌』 SQL 語句優化，該怎麼處理
（1）選擇最有效率的表名順序(只在基於規則的優化器中有效)：
ORACLE的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫
在最後的表(基礎表 driving table)將被最先處理，在FROM子句中包含多個表的
情況下,你必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連接查詢
, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其
他表所引用的表.
（2） WHERE子句中的連接順序．：
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必
須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE
子句的末尾.
（3） SELECT子句中避免使用『 * 『：
ORACLE在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過
查詢數據字典完成的, 這意味著將耗費更多的時間
（4）減少訪問資料庫的次數：
ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變
量 , 讀數據塊等；
（5）在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數, 可以增加
每次資料庫訪問的檢索數據量 ,建議值為200
（6）使用DECODE函數來減少處理時間：
使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表.
（7）整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使
它們之間沒有關系)
（8）刪除重復記錄：
最高效的刪除重復記錄方法 ( 因為使用了ROWID)例子：
DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
（9）用TRUNCATE替代DELETE：
當刪除表中的記錄時,在通常情況下, 回滾段(rollback segments ) 用來存
放可以被恢復的信息. 如果你沒有COMMIT事務,ORACLE會將數據恢復到刪除之前
的狀態(准確地說是恢復到執行刪除命令之前的狀況) 而當運用TRUNCATE時, 回
滾段不再存放任何可被恢復的信息.當命令運行後,數據不能被恢復.因此很少的
資源被調用,執行時間也會很短. (譯者按: TRUNCATE只在刪除全表適
用,TRUNCATE是DDL不是DML)
（10）盡量多使用COMMIT：
只要有可能,在程序中盡量多使用COMMIT, 這樣程序的性能得到提高,需求也
會因為COMMIT所釋放的資源而減少:
COMMIT所釋放的資源:
a. 回滾段上用於恢復數據的信息.
b. 被程序語句獲得的鎖
c. redo log buffer 中的空間
d. ORACLE為管理上述3種資源中的內部花費
（11）用Where子句替換HAVING子句：
避免使用HAVING子句, HAVING 只會在檢索出所有記錄之後才對結果集進行
過濾. 這個處理需要排序,總計等操作. 如果能通過WHERE子句限制記錄的數目,
那就能減少這方面的開銷. (非oracle中)on、where、having這三個都可以加條
件的子句中，on是最先執行，where次之，having最後，因為on是先把不符合條
件的記錄過濾後才進行統計，它就可以減少中間運算要處理的數據，按理說應該
速度是最快的，where也應該比having快點的，因為它過濾數據後才進行sum，在
兩個表聯接時才用on的，所以在一個表的時候，就剩下where跟having比較了。
在這單表查詢統計的情況下，如果要過濾的條件沒有涉及到要計算欄位，那它們
的結果是一樣的，只是where可以使用rushmore技術，而having就不能，在速度
上後者要慢如果要涉及到計算的欄位，就表示在沒計算之前，這個欄位的值是不
確定的，根據上篇寫的工作流程，where的作用時間是在計算之前就完成的，而
having就是在計算後才起作用的，所以在這種情況下，兩者的結果會不同。在多
表聯接查詢時，on比where更早起作用。系統首先根據各個表之間的聯接條件，
把多個表合成一個臨時表後，再由where進行過濾，然後再計算，計算完後再由
having進行過濾。由此可見，要想過濾條件起到正確的作用，首先要明白這個條
件應該在什麼時候起作用，然後再決定放在那裡
（12）減少對表的查詢：
在含有子查詢的SQL語句中,要特別注意減少對表的查詢.例子：
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT
TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)
（13）通過內部函數提高SQL效率.：
復雜的SQL往往犧牲了執行效率. 能夠掌握上面的運用函數解決問題的方法
在實際工作中是非常有意義的
（14）使用表的別名(Alias)：
當在SQL語句中連接多個表時, 請使用表的別名並把別名前綴於每個Column
上.這樣一來,就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤.
（15）用EXISTS替代IN、用NOT EXISTS替代NOT IN：
在許多基於基礎表的查詢中,為了滿足一個條件,往往需要對另一個表進行聯
接.在這種情況下, 使用EXISTS(或NOT EXISTS)通常將提高查詢的效率. 在子查
詢中,NOT IN子句將執行一個內部的排序和合並. 無論在哪種情況下,NOT IN都是
最低效的 (因為它對子查詢中的表執行了一個全表遍歷). 為了避免使用NOT IN
,我們可以把它改寫成外連接(Outer Joins)或NOT EXISTS.
例子：
（高效）SELECT * FROM EMP (基礎表) WHERE EMPNO > 0 AND EXISTS (SELECT
『X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = 『MELB')
(低效)SELECT * FROM EMP (基礎表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT
DEPTNO FROM DEPT WHERE LOC = 『MELB')
（16）識別'低效執行'的SQL語句：
雖然目前各種關於SQL優化的圖形化工具層出不窮,但是寫出自己的SQL工具
來解決問題始終是一個最好的方法：
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, ROUND((BUFFER_GETS-
DISK_READS)/BUFFER_GETS,2) Hit_radio, ROUND(DISK_READS/EXECUTIONS,2)
Reads_per_run,
SQL_TEXT FROM V$SQLAREA WHERE EXECUTIONS>0 AND BUFFER_GETS > 0 AND
(BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8 ORDER BY 4 DESC;
（17）用索引提高效率：
索引是表的一個概念部分,用來提高檢索數據的效率，ORACLE使用了一個復
雜的自平衡B-tree結構. 通常,通過索引查詢數據比全表掃描要快. 當ORACLE找
出執行查詢和Update語句的最佳路徑時, ORACLE優化器將使用索引. 同樣在聯結
多個表時使用索引也可以提高效率. 另一個使用索引的好處是,它提供了主鍵
(primary key)的唯一性驗證.。那些LONG或LONG RAW數據類型, 你可以索引幾乎
所有的列. 通常, 在大型表中使用索引特別有效. 當然,你也會發現, 在掃描小
表時,使用索引同樣能提高效率. 雖然使用索引能得到查詢效率的提高,但是我們
也必須注意到它的代價. 索引需要空間來存儲,也需要定期維護, 每當有記錄在
表中增減或索引列被修改時, 索引本身也會被修改. 這意味著每條記錄的INSERT
, DELETE , UPDATE將為此多付出4 , 5 次的磁碟I/O . 因為索引需要額外的存
儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢.。定期的重構索引
是有必要的.：
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
（18）用EXISTS替換DISTINCT：
當提交一個包含一對多表信息(比如部門表和雇員表)的查詢時,避免在
SELECT子句中使用DISTINCT. 一般可以考慮用EXIST替換, EXISTS 使查詢更為迅
速,因為RDBMS核心模塊將在子查詢的條件一旦滿足後,立刻返回結果. 例子：
(低效): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E
WHERE D.DEPT_NO = E.DEPT_NO (高效): SELECT DEPT_NO,DEPT_NAME FROM DEPT
D WHERE EXISTS ( SELECT 『X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);
（19） sql語句用大寫的；因為oracle總是先解析sql語句，把小寫的字母轉換成大寫的再執行
（20）在java代碼中盡量少用連接符「＋」連接字元串！
『玖』 SQL執行與優化
SQL優化
執行計劃,表關聯查詢順序,優化策略與思路
下面再向前走一些，容我根據自己的認識說一下查詢執行的流程是怎樣的：
1.連接
1.1客戶端發起一條Query請求，監聽客戶端的『連接管理模塊』接收請求
1.2將請求轉發到『連接進/線程模塊』
1.3調用『用戶模塊』來進行授權檢查
1.4通過檢查後，『連接進/線程模塊』從『線程連接池』中取出空閑的被緩存的連接線程和客戶端請求對接，如果失敗則創建一個新的連接請求
2.處理
2.1先查詢緩存，檢查Query語句是否完全匹配，接著再檢查是否具有許可權，都成功則直接取數據返回
2.2上一步有失敗則轉交給『命令解析器』，經過詞法分析，語法分析後生成解析樹
2.3接下來是預處理階段，處理解析器無法解決的語義，檢查許可權等，生成新的解析樹
2.4再轉交給對應的模塊處理
2.5如果是SELECT查詢還會經由『查詢優化器』做大量的優化，生成執行計劃
2.6模塊收到請求後，通過『訪問控制模塊』檢查所連接的用戶是否有訪問目標表和目標欄位的許可權
2.7有則調用『表管理模塊』，先是查看table cache中是否存在，有則直接對應的表和獲取鎖，否則重新打開表文件
2.8根據表的meta數據，獲取表的存儲引擎類型等信息，通過介面調用對應的存儲引擎處理
2.9上述過程中產生數據變化的時候，若打開日誌功能，則會記錄到相應二進制日誌文件中
3.結果
3.1Query請求完成後，將結果集返回給『連接進/線程模塊』
3.2返回的也可以是相應的狀態標識，如成功或失敗等
3.3『連接進/線程模塊』進行後續的清理工作，並繼續等待請求或斷開與客戶端的連接
接下來再走一步，讓我們看看一條SQL語句的前世今生。
首先看一下示例語句
示例語句
執行順序
SQL解析
1. FROM
當涉及多個表的時候，左邊表的輸出會作為右邊表的輸入，之後會生成一個虛擬表VT1。
(1-J1)笛卡爾積
計算兩個相關聯表的笛卡爾積(CROSS JOIN) ，生成虛擬表VT1-J1。
兩次全表掃描
哈希索引,查找復雜度都是 O(1) 。
2. WHERE
對VT1過程中生成的臨時表進行過濾，滿足WHERE子句的列被插入到VT2表中。
注意：
此時因為分組，不能使用聚合運算；也不能使用SELECT中創建的別名；
與ON的區別：
如果有外部列，ON針對過濾的是關聯表，主表（保留表）會返回所有的列；
如果沒有添加外部列，兩者的效果是一樣的；
應用：
對主表的過濾應該放在WHERE；
對於關聯表，先條件查詢後連接則用ON，先連接後條件查詢則用WHERE；
hash join 哈希連接 驅動表和被驅動表都只會訪問0次或1次
應用場景:一個大表一個小表/表上沒有索引/返回結果集比較大
3. GROUP BY
這個子句會把VT2中生成的表按照GROUP BY中的列進行分組。生成VT3表。
注意：
其後處理過程的語句，如SELECT,HAVING，所用到的列必須包含在GROUP BY中，對於沒有出現的，得用聚合函數；
原因：
GROUP BY改變了對表的引用，將其轉換為新的引用方式，能夠對其進行下一級邏輯操作的列會減少；
原作者的理解是：
根據分組欄位，將具有相同分組欄位的記錄歸並成一條記錄，因為每一個分組只能返回一條記錄，除非是被過濾掉了，而不在分組欄位裡面的欄位可能會有多個值，多個值是無法放進一條記錄的，所以必須通過聚合函數將這些具有多值的列轉換成單值；
GROUP BY 重新聚合查詢
4. HAVING
這個子句對VT3表中的不同的組進行過濾，只作用於分組後的數據，滿足HAVING條件的子句被加入到VT4表中。
7.LIMIT
LIMIT子句從上一步得到的VT6虛擬表中選出從指定位置開始的指定行數據。
注意：
offset和rows的正負帶來的影響；
當偏移量很大時效率是很低的，可以這么做：
採用子查詢的方式優化，在子查詢里先從索引獲取到最大id，然後倒序排，再取N行結果集
採用INNER JOIN優化，JOIN子句里也優先從索引獲取ID列表，然後直接關聯查詢獲得最終結果
當前未用到索引,
三次full scan , table1 AS a / table2 AS b / GROUP BY
盡量少做重復的工作
控制同一語句的多次執/減少多次的數據轉換/
杜絕不必要的子查詢和連接表，子查詢在執行計劃一般解釋成外連接，多餘的連接表帶來額外的開銷
關於臨時表和表變數的選擇
臨時表產生使用SELECT INTO和CREATE TABLE + INSERT INTO的選擇，一般情況下，SELECT INTO會比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO會鎖定TEMPDB的系統表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用戶並發環境下，容易阻塞其他進程，所以建議，在並發系統中，盡量使用CREATE TABLE + INSERT INTO，而大數據量的單個語句使用中，使用SELECT INTO。
子查詢的用法
相關子查詢可以用IN、NOT IN、EXISTS、NOT EXISTS引入
NOT IN、NOT EXISTS的相關子查詢可以改用LEFT JOIN代替寫法
如果保證子查詢沒有重復 ，IN、EXISTS的相關子查詢可以用INNER JOIN 代替
IN``的相關子查詢用EXISTS代替
不要用 COUNT (*)的子查詢判斷是否存在記錄，最好用 LEFT` `JOIN 或者EXISTS，比如有人寫這樣的語句：
建立索引後，並不是每個查詢都會使用索引，在使用索引的情況下，索引的使用效率也會有很大的差別。只要我們在查詢語句中沒有強制指定索引，
不要對索引欄位進行運算，而要想辦法做變換
不要對索引欄位進行格式轉換
不要對索引欄位使用函數
不要對索引欄位進行多欄位連接
join關聯查詢的計算是很復雜的，特別是數據量比較大的情況下，實際情況還是拆解較快的
Join拆解的核心就是利用In關鍵字
要麼用空間換時間，要麼用時間換空間
多表連接的連接條件對索引的選擇有著重要的意義，所以我們在寫連接條件條件的時候需要特別注意。
A、多表連接的時候，連接條件必須寫全，寧可重復，不要缺漏。
B、連接條件盡量使用聚集索引
C、注意ON、WHERE和HAVING部分條件的區別
ON是最先執行， WHERE次之，HAVING最後，因為ON是先把不符合條件的記錄過濾後才進行統計，它就可以減少中間運算要處理的數據，按理說應該速度是最快的，WHERE也應該比 HAVING快點的，因為它過濾數據後才進行SUM，在兩個表聯接時才用ON的，所以在一個表的時候，就剩下WHERE跟HAVING比較了
考慮聯接優先順序：
(1)INNER JOIN
(2)LEFT JOIN (註：RIGHT JOIN 用 LEFT JOIN 替代)
(3)CROSS JOIN
索引並不適用於所有情況：a.少量數據；b.頻繁進行改動的欄位，不適合做索引；c.很少使用的欄位，不需要加索引
索引會提高數據查詢效率，但是會降低「增、刪、改」的效率。當不使用索引的時候，我們進行數據的增刪改，只需要操作源表即可，但是當我們添加索引後，不僅需要修改源表，也需要再次修改索引，很麻煩。
先執行順序, 是否走索引, 有無類型轉換
18000 字的SQL優化大全
步步深入：MySQL架構總覽->查詢執行流程->SQL解析順序
MySQL索引總結（4）——btree與hash區別
『拾』 Sql sever怎麼優化存儲過程。。大概步驟
1、精減變數，排除重復
2、優化SQL語句，將效率低的語句找出，盡量不用查詢全部、嵌套等SQL
3、將重復語句盡量用動態語句實現
4、盡量少用SQL直接計算，能用函數就用函數
等等
具體還是需要根據業務需求調整