1、為什么要對SQL進行優化： 我們開發的項目上線使用的初期，由于業務數據量相對較少，一些SQL的執行效率對程序運行效率的影響不太明顯，而開發和運維人員也無法判斷SQL對程序的運行效率有多大，故很少針對SQL進行專門優化。而隨著時間的積累，業務數據量的增多，SQL的執行效率對程序運行效率的影響逐漸增大，此時對SQL的優化就很有必要。
2、SQL優化的準則： 這個我們可以使用一句話來總結：SQL優化的準則就是盡一切可能提高SQL的執行效率，從而使得我們程序的運行速度很快。
3、SQL優化的一些方法：① 設計數據庫表結構時，要對表做數量級和性能影響預測和評估，表的字段盡量都設置default值，盡量避免default為null，主要防止在執行SQL查詢時直接將查詢條件設置為null或者not null而導致數據庫放棄索引，直接全表掃描；② SQL條件中允許出現庫函數和左模糊查詢，sql條件中庫函數會導致數據庫執行時放棄索引，直接全表掃描，而左模糊也是，直接就全表掃描了；③ 原則上，SQL條件中避免出現<>，in，not in，exists，not exists等操作符；④ 子查詢中的實際查詢結果要設置上限要求，且子查詢必須要有索引支持，否則子查詢也去掃描全表就悲劇了；⑤ 單個事務的SQL語句數量要有上限要求，不能前臺一個提交操作，后臺要去插入幾十張表的數據，那如果是千萬級用戶數，基本上就光去插入數據了；⑥ 同上一條類似，單條SQL語句的數據影響量也要有上限要求，不能一個update操作更新了上千條數據；⑦ 盡量減少多表關聯的SQL，如果必須使用多表關聯，也盡量減少關聯的表數量，且多表關聯時，關聯字段必須包含在查詢索引中。多表關聯SQL中盡量不要使用視圖和代理表；⑧ 充分利用索引，嚴禁出現表掃描。同時，創建表時也注意索引的字段順序。
4、其他的話： 一般情況下，不同的行業數據量水平相對而言是比較固定的，比如電信行業的數據主要以用戶數為基準，按照省級行政單位劃分，數量級在千萬到億級之間。而法院的數據主要以案件數為基準，按照市級行政單位劃分，數量級在百萬到千萬之間。（這里只是簡要描述一下，實際數據量比這個大得多啊~）一般情況下，系統上線前都會針對不同行業不同地區的數據量做一個估算，然后再通過超大數據量對系統進行性能測試。但是如果遇到技術升級更新或者部署方式發生改變（比如數據集中存放到云上或者分布式部署改為大集中部署），那數據量幾乎是十倍百倍的增長，這時候前期SQL執行效率的問題就會暴露出來。
