查詢的識別
查詢的識別
總結：易識別的語句有助於定位性能問題。
儘量給語句添加註釋或使用oracle自帶的函數來標明應用的信息。
保持數據庫連接穩定
總結：數據庫連接和交互好似萬里長城——長度越長，傳遞消息越耗時。
減少數據庫的連接次數，使用數據庫連接池。
戰略優先於戰術
總結：考慮解決方案的細節之前，先站得遠一些，把握大局。
可以從業務的角度思考，想想數據的來源與去處是不是有其他路徑可尋。
先定義問題，再解決問題
總結：先打基礎，再趕時髦：擺弄新工具之前，先把手藝學好。
儘量減少使用新技術，這些往往沒有經過時間的檢驗，雖然有可能解決當前的問題，但是在未來可能存在隱患。
直接操作實際數據
總結：暫時工作表意味着以不太合理的方式存儲更多信息。
減少使用臨時表，儘量直接操作實際表。
用SQL處理集合
總結：幾千個語句，藉助遊標（cursor）不斷循環，很慢。換成幾個語句，處理同樣的數據，
還是較慢。換成一個語句，解決上述問題，最好。
動作豐富的SQL語句
總結：儘可能多地把事情交給數據庫優化器來處理。
避免使用過程邏輯，寫多個sql，業務需求儘量寫成一個sql，這樣數據庫優化器可以進行優化。
充分利用每次數據庫訪問
總結：在合理範圍內，利用每次數據庫訪問完成儘量多的工作。
儘量一次查詢所有的字段。
接近DBMS核心
總結：代碼喜歡SQL內核——離核心越近，它就運行得越快。
儘量使用數據庫自帶函數實現業務邏輯，而不要使用過程塊語句去封裝實現相應邏輯。
只做必須做的
總結：沒必要編程實現那些數據庫隱含實現的功能。
SQL語句反映業務邏輯
總結：檢查數據庫活動，看它是否與當時正進行的業務活動保持合理的一致性。
把邏輯放到查詢中
總結：只要有可能，應儘量把條件邏輯放到SQL語句中，而不是SQL的宿主語言中。
一次完成多個更新
總結：有可能的話，用一個語句處理多個更新；儘量減少對同一個表的重複訪問。
慎用自定義函數
自定義函數的方式阻礙了基於開銷的優化器（cost-based optimizer，CBO）對整個查詢的優化效果。
總結：優化器對自定義函數的代碼無能爲力。
簡潔的SQL
總結：SQL是聲明性語言（declarative language），所以設法使你的代碼超越業務過程的規格說明。
SQL的進攻式編程
總結：以概論爲基礎進行編程。假設最可能的結果；不是的確必要，不要採用異常捕捉的處理方式。
精明地使用異常（Exceptions）
總結：異常處理會迫使我們採用過程式邏輯。應始終使用聲明式SQL，儘量預測可能的異常情況。
SQL的本質
SQL與數據庫
總結：千萬別把SQL查詢的執行過程中真正的關係操作和附加的展現層（presentation layer）功能混爲一談。
SQL與優化器
總結：爲了取得好的優化效果，應將大部分工作安排在關係層。
優化器的有效範圍
總結：如果是若干個小查詢，優化器將個個優化；如果是一個大的查詢，優化器會將它作爲一個整體優化。
掌握SQL藝術的五大要素
獲得結果集所需訪問的數據量
定義結果集所需的查詢條件
結果集的大小
獲得結果集所涉及的表的數量
多少用戶會同時修改這些數據
複雜查詢與複雜視圖
總結：表明簡單的查詢背後，可能隱藏着複雜的視圖。
總結：當視圖返回不必要的元素時，別把視圖內嵌在查詢中，而是應將視圖分解，將其組成部
分加到查詢主體中。
過濾
過濾條件的含義
總結：查詢條件是有差異的，有的好，有的差。
過濾條件的好壞
總結：保證SQL 語句返回正確結果，只是建立最佳SQL語句的第一步。
大數據量查詢
總結：儘早過濾掉不需要的數據。
取出數據在表中的比例
總結：當查詢的結果集很大時，索引未必必要。
無論是單純爲了查詢、還是更新或刪除記錄，過濾數據會遇到的最典型情況有九種：
小結果集，源表較少，查詢條件直接針對源表
小結果集，查詢條件涉及源表之外的表
小結果集，多個寬泛條件，結果取交集
小結果集，一個源表，查詢條件寬泛且涉及多個源表之外的表
大結果集
結果集來自基於一個表的自連接
結果集以聚合函數爲基礎獲得
結果集通過簡單搜索或基於日期的範圍搜索獲得
結果集和別的數據存在與否有關
小結果集，直接條件
查詢的效率與索引的使用
總結：優秀的查詢未必來自優秀的程序。
數據散佈
總結：並非所有明確的條件都適合加索引。特別是，頻繁更新的字段會增加索引維護的成本。
條件的“可索引性”
總結：如果必須進行全表掃描，表上的索引就沒用了。
總結：內嵌查詢可以簡化查詢，但若使用不慎，可能造成重複處理。
小結果集，間接條件
總結：如果要使用子查詢，在選擇關聯子查詢、還是非關聯子查詢的問題上，應仔細考慮。
多個寬泛條件的交集
總結：爲現存的查詢增加搜索條件，可能徹底改變先前的構想：修改過的查詢成了新查詢。
多個間接寬泛條件的交集
總結：記住，你應該詳細說明所有強迫DBMS 做的事。
總結：混亂的查詢會讓優化器困惑。結構清晰的查詢及合理的連接建議，通常足以幫助優化器提升性能。
大結果集
基於一個表的自連接
總結：要理解優化器如何看待你的系統，就必須理解你的數據和數據分佈方式。
通過聚合獲得結果集
總結：聚合操作的數據應儘量少。
後面主要是提供了一些sql編寫技巧。
----摘自《SQL語言藝術》