※ 引述《ripple0129 (perry tsai)》之銘言： : 通靈一下 : 問題是不是報表類啊 : 要全表或大量join大量計算的 : 資料少跑一下SQL就好 : 資料大跑到炸掉 : 會去想到資料大時會炸鍋 : 表示有經驗了啊 : 多的是新手沒想過這種問題 : 不過不要緊了 : 等慢到一定程度 : 就會開始跑daily的過去統計 : 到時重構就好 : 先求功能出來且正常 : 未來再處理效能 : 沒有足夠filter條件的SQL : 往往都是要重構的 : 別擔心遇到了處理就好 : 只要確定目前儲存的資料 : 未來有辦法做重構即可 : 如果現在設計的schema不符合未來重構 : 那就要換schema來儲存 以前遇過是客戶要的報表有可預料的效能問題(不要在數據庫對海量數據 進行recursive string concat). 但經理已經答應了客戶. 當時的做法是: 1) 要經理向客戶解釋情況, 最好說股客戶不要會出問題的部份. 不過這被經理否決了 2) 讓經理另外找人做, 別說我故意做差這功能. 結果代我做這報表的同事寫出來的東西, 即使在demo data量下也要跑十多分鐘 才能顯示. 後來我用我的方式重做, 也不過是把時間壓到一分鐘左右. 但留意這是在demo data 的環境下. 實際使用的話一年半載後不把那部份去後誰也別想救. 經理沒辦法下 也只能用我寫的去交差了. 當然, 一年半載後我已經離職了, 也沒看到後續如何. 重點是: 沒實作相應環境證明你說的情況, 上司不見得會聽進去. Clone一個環境, dummy fill一堆數據把量撐大, 讓上司實際看情況比較重要. 而更重要的是過程要loud, 要確定相關人物都知道你已經事先警告過了, 也花時間實業證明了, 這也要繼續的話, 日後出問題就和你沒關係了. -- --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.238.59.15 (香港) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1578398227.A.351.html