對於以下兩句SQL語句，程序員認為是相同的，數據庫查詢優化器認為是不同的。 所以封裝成復用方法，用標准模板來控制。
select*from dual select*From dual 其實就是大小寫不同，查詢分析器就認為是兩句不同的SQL語句，必須進行兩次解析。生成2個執行計劃2，不要把SQL語句寫得太復雜
我經常看到，從數據庫中捕捉到的一條SQL語句打印出來有2張A4紙這麼長。一般來說這麼復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者，結果他說時間太長，他一時也看不懂了。可想而知，連原作者都有可能看糊塗的SQL語句，數據庫也一樣會看糊塗。 比如 Select語句的結果作為子集 簡化SQL語句的重要方法就是采用臨時表暫存中間結果，但是，臨時表的好處遠遠不止這些，將臨時結果暫存在臨時表，後面的查詢就在tempdb中了，這可以避免程序中多次掃描主表 也大大減少了程序執行中“共享鎖”阻塞“更新鎖”，減少了阻塞，提高了並發性能。3，必須采用綁定變量
select*from orderheader where changetime >‘2010-10-20 00:00:01‘
以上兩句語句，查詢優化器認為是不同的SQL語句，需要解析兩次。如果采用綁定變量
select*from orderheader where changetime >@chgtime4，使用like進行模糊查詢時應注意
有的時候會需要進行一些模糊查詢比如
select*from contact where username like ‘%yue%’ 關鍵詞%yue%，由於yue前面用到了“%”，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%， 5，聯表查詢(1) 連接字段盡量選擇聚集索引所在的字段
(2) 仔細考慮where條件，盡量減小A、B表的結果集 獲取下載地址 springmvc+mybatis+spring 整合 bootstrap html5 6，索引， 看sql 的性能，主要看執行計劃，還有cpu成本，io成本等。這裡就以一個簡單的表為例。 首先，創建一個簡單的表，一般會先建個主鍵，系統自動以主鍵建聚集索引。 判斷是否需要優化sql的一個簡單規則是：看執行計劃中的操作是seek(搜索)還是scan（掃描） 是scan的話就要索引。 使用場景： 當一個系統查詢比較頻繁，而新建，修改等操作比較少時，可以創建覆蓋索引，將查詢字段和where子句裡的字段全部包含在內，這樣查詢的速度會比以前快很多，同時也帶來弊端，就是新建或修改等操作時，比沒有索引或沒有建立覆蓋索引時的要慢。讀寫數據庫分離也能解決問題 經常對Creator_Id字段查詢，就做個索引。 對表Article的Creator_Id字段建索引 CREATE INDEX Ix_article_creatorid ON Article(Creator_Id) set statistics io 和 set statistics，這是性能調優時查看相關cpu占用時間，IO資源數據的兩個比較重要的命令 記得Order by 語句加索引 7，讀寫分離 當主數據庫進行寫操作時，數據要同步到從的數據庫，這樣才能有效保證數據庫完整性 主從分離，對數據庫層面就是數據同步或者是數據復制；從應用層講就是請求的分離：增刪改請求主庫，查詢請求從庫 8，盡量不用select * from ….. ,而要寫字段名 select field1,field2,…這條沒什麼好說的，主要是按需查詢，不要返回不必要的列和行。 9 任何對列的操作都將導致表掃描， 它包括數據庫函數、計算表達式等，查詢時要盡可能將操作移至等號右邊 10 In 、or子句常會使索引失效 顯而易見的，IN,OR擴大的查詢范圍。 11通常情況下，連接比子查詢效率要高 必然的，需要子查詢時，也是用臨時表暫存中間結果
