記錄一下工作上疑難問題解決：
一，方便的頁面監控
前幾天早上，負責的kettle抽取數據表的任務又報錯了，早上看手機有4個未接報警電話，一看是人員表，原來昨天報表系統有個大的查詢一直未查詢完成，導致truncate這個人員表，無法活動meta的鎖，後續執行抽取和計算的都報錯。爲解決以前這個很偶發的大查詢，特意用datart報表做了一個查詢頁面，在手機上直接看是否有大的事務查詢，有的話kill，保證晚上抽取不會報錯，但後面一直天天看，也會放鬆疏忽。
不想被短信電話打擾如何解決？不要特別的點開看這個查詢頁面，又保證能天天看到。
方法一：報表庫購買一個從庫，報表讀和數據寫入計算分離就可解決。 需購買從庫，要費用，估計不會批
方法二：做一個監控工具，如果報表庫有大的查詢報警或者是發送消息! 也會導致讓人煩，入侵性強。不太好
方法三： 在瀏覽器裏把這個長事務頁面設置成首頁，每次打開瀏覽器就可以看到。 很友好，每天都會上網，上網就就會看到，非入侵性
二、缺少的數據庫備機
幾年前，在一家電商公司做DBA，北京倉庫有臺數據庫服務器(線上的數據抽取到本地作業)，但一直沒有備機，幾次和研發領導說這個事情買個備機做實時備份，領導也沒說買，估計到CEO老闆也不會同意買，公司當時也很缺錢，但這個隱患一直存在，假如某天這個數據庫服務器出現故障，無法使用，就很影響到現在的倉庫作業，這時再去弄備機，時間很長。
不給買備機怎麼處理？無法做一個實時備份，等出問題再說。跟領導說了幾次，估計他也沒辦法！
後來有次上海倉庫，突然停電，當初配置了一個從庫，沒什麼問題就係統和數據庫都起來了。我把這個擔憂給領導又說了一遍，擔心如果北京倉庫斷電重啓不起來，那就麻煩了，後來領導說買個高配的臺式機做一下過度，是否可以，想想有個備機總比沒有強，就立刻購買一臺高配的兼容機，弄好配置從庫。這才解決，後面再新加倉庫配置本地數據庫服務器，都是按一主一從庫來購買。
三、表重構高風險
幾年前，公司的線上系統使用的優惠卷表，以前設計存在嚴重問題，要重新設計表，修改程序。優惠卷就2個表，表重構和程序修改比較容易，但上線，研發出現一個問題，因爲代碼分佈在各個系統，以前維護這塊的人都離職了，現在誰都無法瞭解
1，不知道程序改完沒有 2，即使程序改完了，出現問題，對用戶影響很大。 沒辦法保證100%的修改完成。
一句話：修改上線風險大，出問題還要背責任。
和研發，架構還有領導開會討論時，面臨這個問題，怎麼處理。討論下來就是，出一個雙寫方案，就是新表和舊錶同時運行，程序設置開關，可以直接打開雙寫。上線後，架構開發一個功能，對比2個表的數據差異，一直對比，有異常看程序那些還沒改，改得有問題。就這樣整個功能運行近1年，對比確認沒問題後，這才重構完成，並保證切換系統100%沒有問題。
四、大表拆分
幾年前，去新公司的數據庫有個表比較大佔用100G+的空間，核心庫500G+大小，這個表如果有問題，會影響到核心業務庫，最好是遷移出核心庫。當時負責這塊的研發在廣州，我在上海。和負責這塊的研發領導溝通，反饋是工作太忙，沒有時間，要麼排期（排期不知道排到什麼時候）。
而且當時公司研發文化，以結果目的爲導向，只看重結果。這個工作又不是他們的核心業績，即使做了也不一定有好的績效。但如果不推動這個事情，後面表越來越大，風險也越來越大，必須要做下去，慢慢做，總有做完的那天，如果一直沒時間做，就永遠不會做。
只是一個小DBA，沒有權利去要求他們做什麼，怎麼推動這個事情解決？
後來和廣州研發部門的組長和經理溝通，研發的確很忙，和研發組長和經理多次溝通，這拆分還要做，但可以慢慢做，他們最後還把拆分任務分下去，哪個研發人員有空就分配給誰，修改一部分。剛好當時做一個MySQL的審計：
1，用ELK分析每天4億多條騰訊雲MySQL審計日誌(1)--解決過程
每次程序修改了，可以通過ELK去查是否修改完成，是否還有其他遺漏的地方，一開始給他們開了ELK權限，後來又擔心數據安全問題，又給取消了。就這樣，每次上線，修改一部分，自己在釘釘羣裏通告一下是否改完，還有那些沒改，監控出沒改的SQL，發給他們修改，就這樣，整個程序修改都半年多，終於把這個表給拆分出核心庫，一句話說的好：真是世上無難事，只怕有心人。
修改上線後，在例行每次優化報表郵件中，特意寫了一份表揚信（寫這個表揚郵件費點勁），對廣州研發的同事表揚，他們的研發總監還特意點贊回覆。郵件如下：
總結：
這個大表拆分能完成，不是靠一再的施壓力和只看結果，而是真正去了解他們的實際情況，給研發提供方便高效的幫助，大家齊心合力去完成一件事。