任何平台的sql開發者都有自身的困惑，似乎他們一直糾纏在do while迴圈裡，這個迴圈讓他們不斷地重複同樣的錯誤。這是因為資料庫的發展依然不夠成熟。當然，**商們也在不斷進步，但是他們還是需要處理更嚴重的問題。併發性，資源管理，空間管理和速度依然制約著sql開發者對開發平台的選擇。
我並不期望sql開發者能成為管理員，但是在寫**的時候，他們必須重視生產問題。如果在開發初期他們就不做這些工作，那麼，dbas將強制他們回過頭來考慮這個問題，以此同時，使戶也會受到影響。
我們之所以說調整資料庫是一件藝術性和科學性結合的事情，是因為在應用上來看有很多必須遵守的規則。你在乙個系統裡解決的問題，在另乙個系統裡依然會出現，反之亦然。在調整資料庫方面沒有萬能的答案，但是你依然不能放棄。
下面我將總結出在sql程式設計中容易被忽略的一些注意要點，哪些是可以做的，哪些是不可以做的。這些要點將幫你更加深入地理解dbas，也可以增強你從面向生產的角度思考程序。
1.不要用update代替case
儘管這個問題經常被忽略，但是卻是乙個很普遍的問題。很多開發者都會忽略這個問題，因為使用update看起來是乙個具有邏輯性的自然流。
在這種情況下，例如：你插入乙個臨時**，在存在另乙個值的時候，讓它顯示某個值。你要從客戶表中按順序列出超過10萬美金的人，以便把他們設定為「首選」。這時，你就要把資料插入**中，執行updatea命令來設定customerrank列，來順序定義那些超過10萬美金的人。問題是，update命令已經被記錄了，這就意味著針對每乙個表寫入你都要進行兩次操作。當然，針對這個過程可以使用sql查詢語言本身的case語句。它將測試每一行是否符合總體條件，並在寫入**前，給它乙個「首選」的標籤。這種效能的提高是驚人的。
2.不要盲目使用**
3.只查詢對你游泳的列
這個問題和第二個問題類似，但是，是針對列來講的。用select * 查詢，而不是分別對每列查詢在**實現方面也簡單地多。但是這時，問題再一次出現，你再次得到了比你需要的資料多得多的資料。我已經無數次地看到這種現象發生了。開發者用select * 語句查詢乙個120列、幾百萬行的表以後最後只得到了3到5行的有用資料。在這一點上，你不是僅僅查詢了比你所需要的資料多的資料，你還從別的程序中搶奪了資源，降低了整體速度。
4.不要做兩次查詢
還有乙個常見的現象是：寫乙個從擁有無數行的表裡取資料的儲存程序。開發者需要查詢到符合這樣以下條件的使用者：住在加利福尼亞州，收入超過$40,000。這時，他把住在加利福尼亞州的客戶查出來放到一張零時表中，然後把收入在$40，000以上的客戶查出來放到另一張零時表中。最後，他合併這兩個表得到最終的查詢結果。然後，通過更小的資料集，來加強後續步驟。
你在開玩笑吧?這個查詢應該是乙個單一的查詢，可是，你卻對乙個如此大型的表進行了兩次查詢。不要再做這樣的傻事了：對大型**說，盡可能地只進行一次查詢。這時，你會發現你的程式執行起來效率更高了。
稍微不同的地方是，當我們需要通過幾個步驟查詢乙個大型表的子集時，它將導致對大型表的多次查詢。一定要通過查詢子集避免這種事情的發生。
5.確定使用臨時表的時機。
這是乙個比較難以處理的問題，但是你可以從這裡得到很多好處。很多情況下，都是可以使用臨時表的，比如：在避免兩次從乙個大型**裡查詢時。在連線兩個**的時候，你也可以使用臨時表來大大降低處理程式所占用的記憶體。如果你必須把乙個表合併到乙個大型**中，你可以通過先從大型表中檢索出你所需要的資料合併到臨時表中，然後用把這些資料合併的方法來優化命令。如果在程序中，你必須對同乙個表進行同樣的合併的時候，臨時表是乙個非常有用的方式。
6.必須預存資料。
一般情況下，你是不能使用這個技巧的。但是，如果你可以，你會發現這將是乙個非常完美的節約伺服器資源的方法。
注意到這樣的問題，一般開發者通過關注查詢本身而避開這樣的合併問題，建立乙個只可見的合併，以致於不能一而再，再而三地定義它們的合併環境。通過預存資料，你只需執行一次合併，同時別人也避免了大型的合併。我非常喜歡用這種方法，大多數情況下，有很多流行表總是執行合併，所以沒有任何理由說不能預存資料。
7，分批地刪除和更新。
還有乙個常被忽略的簡單技巧。如果你的操作錯誤，從乙個大型表裡刪除和更新大量的資料將是乙個噩夢。問題是這兩個命令執行起來就像是乙個命令，如果你需要放棄他們，或者如果你在工作的時候系統發生了什麼事情，系統就必須從頭開始所有命令的執行。這會花費很多時間。這些操作也會妨礙別的命令的執行，甚至會成為整個系統的瓶頸。
解決這個問題的辦法是，小批量地刪除和更新資料。可以通過兩種方式來解決這個問題：一，如果命令的執行因為任何原因被終止，那就必須有一小部分行從頭開始執行，所以資料庫恢復得將會快得多。二，當更少的資料被存在了硬碟上時，別的命令也可以做一些工作，所以併發性就被大大地優化了。
按照這個指示，很多開發者企圖在一天之內把這些刪除和更新操作完成。但是，這並不是總是正確的，特別是當你在存檔的時候。只要你需要，你可以盡可能地擴充套件這些炒作，而且這些小批量的資料也可以幫助你完成這些。如果你可以花費更多的時間來做更多的操作，那麼就花費一些多餘的時間吧，同時不要讓你的系統停下來。
當你寫**來優化你的sql效能的時候，在任何你可以遵守這些事項的時候，就去遵守它們。但是，請分別評價這些解決方法來看看哪種方法是最有效的，可以說沒有乙個萬能的或者是固定的方法來解決這些問題。你將會發現很多竅門都是和ikyi提高併發性，並可以讓整體執行通暢的。同時，你也會注意到這些物理實現會從這個**商傳遞到下乙個**商，這些概念和問題將會存在每乙個sql平台上。
效能優化 SQL優化
1.列型別盡量定義成數值型別，且長度盡可能短，如主鍵和外來鍵，型別字段等等 2.建立單列索引 3.根據需要建立多列聯合索引 當單個列過濾之後還有很多資料，那麼索引的效率將會比較低，即列的區分度較低，那麼如果在多個列上建立索引，那麼多個列的區分度就大多了，將會有顯著的效率提高。4.根據業務場景建立覆蓋...
SQL效能優化
postgre資料表資料比較多的情況下，使用模糊查詢效能很差，但是使用函式反而快了，返回資料一致，有點不解 warning表2688133條資料，warning message表6954788條資料 這個sql執行老半天都沒反映，耗時169904 ms select count 1 from war...
Sql效能優化
操作符優化 in 操作符 用in寫出來的sql的優點是比較容易寫及清晰易懂，這比較適合現代軟體開發的風格。但是用in的sql效能總是比較低的，從oracle執行的步驟來分析用in的sql與不用in的sql有以下區別 oracle試圖將其轉換成多個表的連線，如果轉換不成功則先執行in裡面的子查詢，再查...