數據管理型系統，由於用戶的要求或者系統設計要求，會出現大量表進行join，還要進行大量統計性數據查詢展示，甚至數據權限控制等操作。最后會導致sql異常復雜，隨着數據量增加，或者只是應用到生產環境（正式環境）就會出現系統反應慢，體驗差的現象，這個時候不得不對這些，復雜的sql進行優化。沒有經驗的程序員會感覺無從下手，這么復雜的sql語句看一眼就頭疼，該怎么辦呢？
根據個人的工作經驗提供一下優化步驟：
首先要對sql語句進行格式化，使sql條理清晰，甚至分步驟添加注釋，弄清楚每個步驟是為了得到什么；
第二步，用第一部格式化過的sql與最終需求做對比，沒有用的表，就不要進行join了，沒有用的字段也不要進行返回了。
第三步，分模塊檢查子查詢，到底是哪個表查詢速度慢，或者哪個條件導致的查詢速度慢。
第四步，配合sql執行計划，這個由於自己也不擅長看執行計划，只能盡量避免全表掃描，提前限制sql數據篩選范圍。
第五步，檢查是否用了不合適的in查詢，過量的in會導致效率驟然降低很多。
第六步，檢查是否存在過多的or查詢，or會導致全表掃描，能避免盡量避免。
第七步，檢查子查詢是否過於復雜，或者sql處理是否過於復雜，如果可以將復雜處理放到程序中進行。
第八步，可以用exists替代的地方，用exists進行替代。
第九步，可以建視圖，對sql進行簡化，至於視圖是否可以提高查詢效率，我也不知道，還需要學習研究。
以上步驟准確的說，是可以采取的方法，除了前幾條，其他的沒有先后順序。
這些心得是在老大指導進行sql優化時的心得，記錄下來既可以總結自己的收獲，也希望能與大家的觀點碰撞，相互進步！
-----------------------------------------
2018-05-08 更新
自己進行sql速度優化時的感悟心得。
建表時注意：
1，不要用判斷值的方法，代替狀態字段，建表時應該建狀態字段，不能省略；
因為用判斷某個字段的值判斷狀態，可能需要使用轉換函數或者isNull判斷，會影響查詢速度。
2，應該在程序中保持數據的一致性，而不是使用sql，防止查詢時可能需要or判斷，or判斷會影響sql查詢速度；
3，嚴格控制字段的類型，不要使用過大的字段，或者不必要的增大字段長度；