?1，統一SQL語句的寫法

對于以下兩句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'?
select*from?orderheader?where?changetime?>'2010-09-22 00:00:01'

?

以上兩句語句，查詢優化器認為是不同的SQL語句，需要解析兩次。如果采用綁定變量

select*from?orderheader?where?changetime?>@chgtime

4，使用like進行模糊查詢時應注意

有的時候會需要進行一些模糊查詢比如

select*from?contact?where?username?like?‘%yue%’ 關鍵詞%yue%，由于yue前面用到了“%”，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%， 5，聯表查詢

(1)??? 連接字段盡量選擇聚集索引所在的字段

(2)??? 仔細考慮where條件，盡量減小A、B表的結果集 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通常情況下，連接比子查詢效率要高 必然的，需要子查詢時，也是用臨時表暫存中間結果

轉載于:https://www.cnblogs.com/zkp2010/p/5510506.html

總結

以上是生活随笔為你收集整理的3，SQL语句及数据库优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。