使用者報說統計查詢慢，在頁面嘗試了下，統計兩個月的資料大約需要5秒，把那段執行的sql，直接通過toad連線到資料庫中嘗試，1秒不到。
初始以為是**問題或者是jdbc驅動等問題，後來嘗試應用連線不同資料庫，結果如下
開發資料庫 資料總數2181377條，首次1100ms，後面平均查詢速度719ms
測試資料庫 資料總數2187115條，首次10422ms，後面平均查詢速度5300ms
生產資料庫 資料總數2637793條，首次14563ms，後面平均查詢速度6500ms
由於被查詢的表的資料量在三個庫中屬於乙個數量級，而且均為oracle11g資料庫，因此我們曾懷疑是網路通訊速度問題，直到網上搜到《troubleshooting oracle performance 》這本書
裡面有寫到這麼幾句：
總的來講，為了提高執查詢優化器生成高效的執行計畫的可能性，最好不要使用繫結變數。繫結變數有時候可能有用。遺憾的是，生成的執行計畫是否高效只能看運氣如何。唯一的例外是，oracle資料庫11g中的新的擴充套件的游標共享會自動識別這個問題。
使用任何特性都需要權衡利弊得失。有些情況下，這是比較容易決定的。例如，在不涉及到where從句（如普通的插入語句）的時候，就沒理由不使用繫結變數。另一方面，在柱狀圖資訊對查詢優化器有很大影響的情況下，最好不要使用繫結變數。否則，可能會在進行繫結變數窺視的時候遇到較大負面風險。不過，還有以下兩個關鍵案例可供參考：
雖然文章中說是oracle資料庫11g能自動識別這個問題，但我們總結下來，應該就是這個問題，我們的資料庫自動生成的執行計畫有問題，因此我們改了我們的查詢**，由原來的游標方式改為直接把變數拼到sql語句中，然後執行測試，果然，測試系統和正式系統的查詢時間大幅下降，甚至正式生產資料庫執行的更快，這可能歸功於正式資料庫伺服器效能更好。
Sybase查詢調優命令
set showplan on 查詢計畫資訊 set statistics io on set statistics time on set noexec on 編譯不執行 set fmtonly on 資料庫在接收到客戶端對資料的請求之後，直接從系統表中獲取資料列資訊，生成空的結果集直接返回客戶端...
spark調優 shuffle調優
基於spark1.6 引數可以通過 new sparkcontext set 來設定，也可以通過命令的引數設定 conf spark.shuffle.file.buffer 預設值 32k 引數說明 該引數用於設定shuffle write task的bufferedoutputstream的buf...
Spark Spark調優 資源調優
spark在乙個executor的記憶體分為三塊，1.一塊是execution記憶體 2.一塊是storge 記憶體 3.一塊是其他記憶體 執行記憶體是執行記憶體，加入，聚合都是在這部分記憶體中執行.shuffle的資料也會先快取在這個記憶體中，滿了再寫入磁碟，能減少io，其實地圖過程也是在這個記憶...