f SQL 是處理整組資料(SET)的語言 ~ 迪貝之家

SQL 是處理整組資料(SET)的語言

這句話基本上是對的,但它講的是sql 處理資料的特性,但很多PG為了方便,喜歡把邏輯都寫在一段sql statement裡頭,造成程式跑起來不穩定,時不時就會出現無法在預定時間內處理完資料。我們來看看的底下我要描述的case ,是在Postgres 上頭發生的狀況,PG把一個子查詢包在where condition,資料上它顯示跑了46分鐘11秒,data還吐不出來,所以PG強行停掉它的運作。因為沒跑完,即使啟動auto explain模組及設上了相關參數,也看不到執行計畫及數據被拋到系統記錄檔,所以這個case在當時非常難debug。
auto explain
既然沒有其它的數據可供除錯,那就只能用最基本的調校原則來建議PG改寫程式--簡化邏輯。我請PG把該段子查詢改寫成一個loop,直接把原本子查詢的result set逐一帶入where condition的右值,不要讓RDBMS做表格資料mapping 的動作。當然PG有提出疑問,說難道不能用with CTE來改寫嗎 ?? 其實你要是稍微了解資料庫的運作,透過CTE的方式,一樣是資料庫系統幫你進行資料比對的動作,當下我是認為不會有改善,但我沒表示甚麼!!PG說他要測試,我說好,那你就測吧~~ 測完他就回覆我,with語法確定沒能解決問題,所以他會嘗試我給的建議。
後來他們試著在問題發生的時段,協調了相關連系統人員,在營運系統測試了兩趟次 一批8萬多筆, 一批將近5萬筆,分別完成時間為4分鐘及一分半鐘,所以我建議的改寫方式是有幫助的,底下是他們改寫後的程式
auto explain
從系統拋出的數據來看,每個迴圈執行的時間是40 ms,但應該不是5萬筆資料就跑5萬個迴圈,再往下看,store_id 的右値被帶入單一値,這就表示不是由RDBMS來比對了。我想提醒PG的是,把程式寫好、寫穩,是你們的責任及義務,當碰到執行速度不穩定時,先想看看,有沒有辦法簡化出現問題的那一段sql 語句,真的不要懶到那個地步,什麼都拋給系統來處理。