調需式優化的簡單實踐

    作為DBA總是會有現場的救火工作，而如果儘可能早一些介入需求，設計，開發階段，可能就會杜絕很多潛在的效能問題。很多問題都是如此，都是逐步積累，最終在某一個階段會集中爆發出來。今天看老蓋的感慨，前十年跟全表掃描鬥爭，後十年跟隱式轉換鬥爭，幾代DBA大約都會面臨這樣的事情，想想真是蠻有意思。
    而且前些天和領導在聊天的時候，我說現在優化沒啥動力，一方面業務的使用量是有富餘的，一個SQL從10秒優化到5秒，好像也沒什麼特別的成就感，說句俏皮的話，可能是你比較喜歡折騰。另一方面絕大多數的業務使用資料庫的都是很基礎的功能，就是把資料庫當做一個黑盒的儲存，先不說這種觀點對與不對，越是如此，越會引入更多的問題。到了後期，就好像問題到了晚期，大量的表連線，複雜的連線關係和臃腫的表資料甚至過度設計，分析起來都是可以改進的地方，但是落地的時候很可能是DBA得向業務和開發妥協，或者相反，哪種情況都會無形引入很多的時間和資源成本。最近這種感觸尤其深刻。
    開發的同學前幾天問我一個問題，是關於JOB的許可權設定，其實JOB本身沒有其它的許可權，需要考慮引用的物件的許可權，設定的觸發時間，頻率等，鑑於線上環境的複雜性，可能開發同學介入分配會有一些難度，在討論之後我只好做了妥協，就是我來處理這些許可權的問題。開發在最後提交的時候，也和我簡單做了確認，這個時候我大體明白了他們的需求。而開發的同事也順便問了下我，說有一個操作想讓我也評估一下效能，大體的思路就是開發通過線上業務會得到一些迴流的客戶資料，這些是增量資料。平均每天就是幾千條資料，目前他們的設想就是在每天的零點開始批量處理，把表裡的一個欄位統一修改，語句類似下面的形式：
update test_customer set enabled=‘Y’;
commit;
    如果按照資料量來看似乎也沒什麼，目前來看效能上是完全可以接受的，但是經過確認，這個表不是中繼表，臨時表。裡面的資料是逐步積累的，也就意味著表裡的資料量會越來越大，那麼就會在某一個階段成為瓶頸，如果表裡的資料成百萬，上千萬，這樣的操作是很有問題的。和這位同學的交流，他們也感覺這種方式可能有問題，其實他的本意是想找我確認下，資料量多大的情況下可能會導致問題，是幾千條，幾萬條還是幾百萬條這樣的。當然我馬上矯正了他的觀點，這個沒有一個完全的基準，可能有的同學說，加上一個時間欄位過濾，取得增量資料，每天增量幾千條資料的DML還是完全可以接受的，但是和開發的交流發現，因為業務在初期設計的時候就沒有考慮到這樣的限制，所以現在新增起來會有一些難度，而且程式碼已經到了最後的稽核和提交階段。所以目前來看這個問題就有兩種走向，開發同學無法改動，堅持上線，後期發現問題，繼續救火。還有一種就是按照增量的方式來改進，只修改增量的資料，這樣始終是保持在一個較小的資料範圍，可選用的方式就多了，比如新增時間欄位的索引，比如設計分割槽表，按照分割槽來更新等。開發的同學有一些猶豫，但是還得進一步確認一下。
    大概在下午的時候，他們給我反饋，經過討論，決定取消那個JOB,其實可以完全通過其他的方式來達到這種效果，他們重新設計了邏輯，把定時的批量變更改為了實時的變更，做了這些改進之後和調整之後，還是可以按照原計劃上線了，看到這種結果，著實讓人欣慰。一方面我們沒有因為這件事情扯皮，這種事情在任何情況下都可以有多種妥協的情況，於情於理怎麼解釋都似乎說得通，另外他們是認真去考慮這件事情的，瞭解了隱患而及時處理，沒有帶著敷衍的態度，這點確實值得我們學習。
    所以調需重於一切，把潛在的問題及時扼殺在搖籃之中，會極大的減少錯誤放大效應的影響。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2124000/，如需轉載，請註明出處，否則將追究法律責任。