一張表的設計優化節省了兩百萬，客戶不斷盛譽，他做對了什麼？

原標題：【沉澱】一張表的設計優化節省了兩百萬，客戶不斷盛譽……，這背後他究竟做對了什麼？——記訪談汪建明

《沉澱》是雲棲社區展示專家風采的人物欄目。它呈現每個專家獨一無二的人生經歷、認識和感悟的同時，也能幫助你沉澱技術，收穫對技術和人生的判斷。我們的想法是：「若你想精進為一個很厲害的人，不妨細細品味這些技術牛人背後的沉澱。」如果你想了解這些雲棲專家更多分享時，請點擊雲棲專家頻道，當然我們也歡迎你往前走一步，成為我們的雲棲專家（https://yq.aliyun.com/expert），與技術大牛一起「煮酒論英雄」。

「客戶第一」是阿里巴巴「六脈神劍」中排名第一的價值觀，它除了要求阿里人服務好客戶之外，也要求阿里的同學時時刻刻去了解客戶的所思所想，不斷地挑戰自己，用不同的視角給客戶創造更多新的價值。

在阿里雲資料庫DBA專家服務組裡，就有一位技術人是「客戶第一」的典範。因為他的存在，有客戶放心地說：「我們才安心地把業務放在雲上。」；也是因為他，客戶非常感激：「如果沒有他的幫助，可能會出現更加嚴重的問題。」

在服務態度上，有客戶稱讚他高效、負責；也有人對他的敬業動容：「感謝汪建明經常利用自己的休息時間來幫助我們查找和解決問題」。在專業上，有人讚賞他有高手風範，接手後不僅迅速找到了問題發生的原因，在半個小時之內還提出了解決方案，並幫他們完成了大部分的調優工作，及時阻止了問題向更加嚴重方向發展……

對於這些稱讚，他沒有一絲一毫地驕傲，反而不斷地總結和反思，提煉出客戶服務三步驟：了解客戶訴求、做到情緒溝通以及坦誠方案風險。面對一時情緒上難以平復，「刁難任性」的客戶，他真正做到：客戶虐我千百遍，我待客戶如初戀，問及樂觀心態的原因，他笑稱：「客戶虐我們，恰恰說明他們愛我們，離不開我們。」

尤為值得一提的是他的技術，在上一家公司，他僅僅對一張核心表的設計優化，就為公司節約了30TB的SAN空間開銷，帶來的直接經濟成本節約是兩百多萬人民幣。為此，公司直接把他調往美國總部。

他，就是阿里雲資料庫專家服務組的汪建明，花名「風移」。第14期《沉澱》人物欄目，用時半個多月的時間，去走近這位在SQL Server資料庫行業鑽研十年的技術專家，將他的沉澱和別具匠心呈現給大家。

技能和職場快、准、狠的背後

汪建明說，數據是公司的生命線，而資料庫是數據的最後一道防線，你對自己的所有操作的後果、風險一定要心中有底。

汪建明，目前在阿里雲RDS負責資料庫管理、運維、產品設計、研發，以及專家服務等。上一段工作經歷，他是在新蛋（Newegg）成都公司做DBA。因為工作出色，幾年後，他就被調到美國新蛋加州總部，負責集團資料庫管理、運維、設計、性能調校，以及大數據平台建設。後者中，包括Hadoop、Hbase、Hive、Prosto和Phoenix等。

回顧這段較為順利的職場經歷，他把原因歸結為四個字：「先知先覺」。他說，自己讀大三時，就已經在企業里實習，摸爬滾打，鍛煉自己。大四，更是幾乎沒在學校待過，一邊自學大四專業課程，一邊公司實習。

他說：「自己雖然累點，但是知識的吸收速度，和對社會、職場的貼近程度更快、准、狠。」在大四所有人都在為找工作東奔西走、忙裡忙外時，汪建明已經在實習單位轉正。

在轉正後的四年里，汪建明做了無數的項目，也開始帶領8個人的團隊。隨後，他轉到美國總部。然而初到美國後，卻讓他有種一夜回到解放前的感覺。

問題體現在口語表達、文化差異、同事相處等方面。為了豐滿自己，適應新環境，汪建明白天上班，晚上上語言社區大學語言課程，結束之後，再回家上在線英文課程。這是猶如孩童一般，從頭開始一點一滴的重新學習：「如何打電話、如何點餐、如何與人溝通，甚至如何寫英文郵件……」汪建明感慨到，文字表達有點蒼白無力，其中滋味五味雜陳，只有自己才能體會。在這樣的狀態下，汪建明堅持一年後，也慢慢適應了新環境和工作節奏。

帶來的I/O壓力減輕和應用內系統的性能提升，很難用數字去表達

回首在新蛋的工作，汪建明稱，因為做的項目太多，有很多都已無法記得特別清楚，唯獨有一個記得十分清晰。

那是他發起並領導的一個項目，工作的內容是對一張核心系統表的設計優化。就是這張表，卻為公司節約了近30TB的SAN空間開銷。這個是直接空間節省，因此帶來的I/O壓力減輕和應用系統性能提升，很難用數字去表達。而這30TB的空間直接的經濟成本是30萬美金左右，也就是200萬左右人民幣。

他指出，這個項目是典型的利用技術手段，為公司節約經濟成本投入的很好佐證。項目的背景是關鍵業務系統大表，表結構的設計有很大問題。具體體現在表欄位類型的設計有問題和表主鍵設計不合理，比如好幾個欄位的數據類型被設計為CHAR（100）， CHAR（800），CHAR（2000）這種數據類型，而表主鍵則是CHAR(25)，這種設計導致的嚴重問題包括：

1. CHAR數據類型存儲了很多無用的空格信息，主鍵長度過寬，導致表聚集索引、非聚集索引空間佔用過大

2. 查詢語句性能會消耗更多I/O資源，I/O利用率下降

3. 索引維護工作超時，更進一步導致了查詢語句性能低下

4. 過大的表空間甚至導致備份超時，影響備份策略

問題的解決之道，也許並不是特別難，但讓汪建明頭疼的是：如何在完全不修改現有系統，不影響現有業務系統，在用戶業務毫無感知的情況下，把這個項目按時按質量順利進行；其次是，該表為大表，僅僅是這一個表記錄數近1億，表空間佔用近700GB，數據源頭同步到近60個數據目的業務子系統中，業務系統錯中複製，盤根錯節，千頭萬緒。

基於以上的同步關係，加之該表為公司關鍵業務系統表，公司里的技術人難以抉擇。「我們不會也不可能直接在表數據同步源頭直接修改表結構。如果這麼操作會導致一個超大的事務，影響到所有業務子系統，對公司業務來說是致命的。」 汪建明道出難以抉擇的原因。

這位在大三就在企業摸爬滾打的技術人，並沒被問題嚇住。他開始著手解決問題，先是理清楚所有業務子系統，該表的數據同步關係；接著，制定好詳細的操作步驟，驗證方法，不斷在測試環境驗證這些步驟和方法的可行性。

而當他不斷探索，驗證方案時，解決思路也就有了：在數據源頭庫新建一張中間表，中間表的表結構是已經優化好了，我們最終希望的表結構（CHAR數據類型修改為VARCHAR），不再存在數據類型的問題→在數據源頭建立到中間表的Replication→確保正式表和中間表數據一致性→中間表上Update截斷CHAR數據類型右邊空格→在中間表基礎上，參照正是表的同步關係，建立一摸一樣的同步鏈→切換所有下游中間表，將中間表和正式表名字對調（這個過程很快，不到1秒即可完成）→最後切換最終源頭表的名字。

當項目成功實施後，統計所有實例上該表空間佔用情況，已然從700GB降低到200GB，空間佔用降低了近70%，總共節約了近30TB的存儲空間。項目總結時，所有人都對他豎起了大拇指。

技術不是僵硬的：「你彷彿看到了客人迎面而來，熱情地緊握著你的手，滿面微笑不斷地說——謝謝。」

在美國待了三年後，汪建明意識到雲計算的發展的巨大潛力和未來，他決定回國，並加入阿里。

來到了阿里雲後，汪建明擔任類似於「救火員」的角色，為客戶解憂排難。對於他而言，每天面對的客人從之前的內部用戶變成了外部用戶，每天也都經歷各種稀奇古怪的問題，管理數據實例的規模從幾百到成千上萬……正是這樣異常複雜的環境，卻逐漸讓這位不善言辭的技術同學逐漸得到客戶的認可，以及增強了他們對阿里雲的信心。

正如文章開頭提到，他受到多家客戶表揚，包括復方科技、飛利浦中國、問卷星……等。令汪建明印象最深的是後來遇到的一家A公司。因為CPU持續100％，影響到公司業務無法正常開展，導致A公司的高層非常憤怒，幾個工程師已經到了快要被開除的邊緣。客戶覺得阿里雲RDS SQL不行，內部已經在準備著手應用下雲或切換為MySQL。

而在他介入之後，通過分析「病原」。包括，聞：電話聽取客戶的抱怨、激動、怒吼和傾訴；問：詢問「病狀」表象，進一步確認「病原」；切：有針對性的實地考察，再次肯定「病原」。一系列組合拳後， 很快定位到CPU 100%的根源，開出治病良方。從索引缺失、索引碎片、Non SARG查詢、數據類型隱式轉化等角度，快速幫助用戶解決問題，CPU也從100％降低到15％，查詢語句時快時慢、卡頓和超時現象消失，應用恢復穩定正常。而更重要的是，那幾個技術員不用被老闆開除了，客戶重新建立了對阿里雲RDS SQL Server的信心，對阿里雲充滿感激，並發來熱情洋溢的表揚信。

這次「行醫」也顛覆了汪建明對技術的看法，他原以為技術是僵硬的，是死的，沒有任何情感和情懷。「但從這個Case，我感受到了技術之外的魅力和情感。」他進一步述說，「在我看來『簡單』的技術問題，可能會要了客人的『命』，也有可能要了技術人員的『命』。而我們善用平時總結的技術知識點，運籌帷幄，一整套組合拳下去以後，客人反饋給我們的是有情感、有溫度、有畫面感的具體形象（你彷彿看到了客人迎面而來，熱情的緊握著你的手，滿面微笑的不斷說，謝謝）。」

「這個或許就是技術帶來的魅力，技術帶來的情感，技術帶給我們的成就感。」說完之後，他頭轉過來，從他的眼神中，雲棲社區的編輯也看到了亮光。

如何煉就火眼金睛

如何做性能優化，汪建明表示，性能優化是資料庫綜合能力的體現。它涉及到資料庫方方面面的知識和理論，比如：資料庫設計（包括很多方面的設計）、查詢語句寫法、索引優化等。他覺得舉一個實例比較好理解：「很多用戶對於高CPU使用率問題是束手無策，我們可以從索引缺失、索引碎片、數據類型轉化、non－SARG查詢、統計信息、參數嗅探等角度多管齊下，很快就可以解決CPU高使用率的問題。」

而對於如何像他一樣煉就一雙火眼金睛，他也從以下角度給了兩個誠懇的建議：

1.端正態度，不要操之過急。遇到任何問題，多想，多測試，多問為什麼，要和問題死磕到底，不找到問題的根源死不罷休。多向高手學習，學習他們對資料庫的理解、學習他們對問題的思考方式和解決方法；

2.多總結。按照類型總結，吃透一類問題（比如高CPU使用率的問題），那麼涉及到這類問題的方方面面做到爛熟於心，信手拈來；

對於從事資料庫行業的同學，他也給出一個忠告——和資料庫打交道，一定要打起十二分精神。他說，數據是所有公司的生命線，而資料庫是數據的最後一道防線，你對自己的所有操作的後果、風險一定要心中有底。

「試著問自己，如果這個操作導致了XX嚴重後果，有辦法把數據救回來嗎？數據會丟嗎？丟多少？比如：我們經常遇到的Case是用戶一個Update語句下去，忘記寫WHERE條件，導致所有數據被Update，又或者是刪除測試環境的數據，不小心連接到了產品環境等。」他說，類似的情況比比皆是，所以一定要小心再小心。

客戶服務的三個有效步驟

每次幫客戶解決完問題，汪建明並不是就此結束，而是會反覆揣摩和進一步思考：如何能做的更好，如何能幫客戶進步，讓他們自己能避免一些問題發生。

在如何做的更好上，他提煉出客戶服務三個有效步驟：

1. 清楚客戶需求：了解客戶的訴求、需求點、痛點在哪裡，客人迫切需要解決什麼問題？如果客人是頭痛，你卻醫腳。醫術再高明，也解決不了客人的痛點。

2. 情緒溝通：穩定客人的情緒，緩解客人的抱怨，控制客人的影響，做好輿情防範。在嚴重問題面前，最好能夠當面和客人溝通，其次電話，再次即時聊天工具。

3. 風險管理：坦誠解決方案的風險，讓客人清晰、明了、理解問題解決方案的風險點，給足客人心裡預期。

他還說：「我們不能要求客戶，擁有像阿里雲DBA那麼牛逼的組合拳來面對問題。所以，有的時候，看到客人對我們產品的誤解的時候——RDS SQL不行啊，要下雲啊，又好氣又好笑（這裡笑沒有貶低的意思，是苦笑）。氣的是客人對RDS SQL產品本身研究不夠深入，而武斷下結論，甚至因此開除自己的員工；哭笑的是實際是一個不難的問題，卻把我們的客人逼的焦頭爛額，無從下手。」

為了讓客戶也能進步，汪建明哪怕是在客戶服務結束後，也會對每一個問題都刨根問底，希望找到客戶經常犯的問題的共性。他接受雲棲社區訪談時，給出了自己的思考：

1. 一切資料庫技術問題的「禍根」或者說根源，可以歸結為資料庫的設計問題。比如：資料庫架構的設計、分庫分表的設計、讀寫分離的設計、表結構的設計、表欄位類型的選擇、索引的設計、索引維護策略的設計、統計信息維護等等；

2. 對如何寫出高性能的SQL語句沒有感覺，開發人員往往是功能優先而忽視性能。比如：確保比較運算符兩段的數據類型一致、WHERE字句中使用函數、Non－SARG查詢等；

3. 對SQL Server商業資料庫能力邊界沒有信心。很多客人會問，SQL Server是不是不行了啊，是不是處理不了啊，是不是已經達到處理的邊界了啊，Hold不住了啊等等問題。汪建明認為，這些類似的問題是很可笑的。如果SQL Server資料庫用的好的話，PB級別不在話下。他之前的公司，單台實例的SQL Server數據量達到20TB以上的數據量，照樣穩定高效運行。「現在公有雲用戶沒有誰達到了這個量級吧？」他反問。

至於如何實踐，汪建明說：「除了自己不斷學習，不斷總結，也可以多看看雲棲社區上的技術分享和總結。」他說，站在前人的肩膀上，總會站得更高，看得更遠，少走彎路，更快成熟。為此，他還把自己十多年的沉澱和針對性的總結，做成專題，詳情參見鏈接：https://yq.aliyun.com/topic/98。

他也指出：「當然，作為阿里雲RDS這個角色，如何將我們的經驗、總結，以及我們對資料庫本身的理解，沉澱出產品來，使得用戶入門的門檻更低，運維、設計、管理更為方便，也是我們必須要突破的重點和難點。目前也有一些服務出來，包括專家診斷、專家服務和個性化的培訓服務等，詳情參見專家服務：https://promotion.aliyun.com/ntms/act/clouddba.html。」他也表示，自己實際上不是一個人在「戰鬥」，背後也有一排排同樣專業的技術大牛，這麼多人構成了ApsaraDB專家服務多樣化、個性化、全面和周到的服務體系。

結束語：知行合一

在最後，我們聊到對技術的理解。他說，不論是技術人，還是技術型公司，都需要對技術的執著追求、對任何問題死磕到底的工匠精神，戒驕戒躁；以技術解放生產力問題，用技術提高生產率，優化產品質量。

「這就是我對技術和對技術從業人員需要具備的特質的理解。」說完後，汪建明又補充，這裡還想借王國維人生的三個境界，進一步來闡述他對技術的認知。

第一層境界：昨夜西風凋碧樹，獨上高樓，望盡天涯路。他解讀，但凡活好，技術牛逼的技術從業人員都有明確目標，執著的追求。「獨上高樓」，登高望遠，講的就是對目標和方向的明確，一旦找准方向，哪怕獨自前行，風雨征程，也絕不退縮，永不放棄；

第二層境界：衣帶漸寬終不悔，為伊消得人憔悴。任何成大器者、大學問者，都不是輕而易舉，唾手可得的。堅定信念，一番辛勤勞動，廢寢忘食，孜孜以求，直至「衣帶漸寬終不悔」。汪建明還描述到：「此刻，我腦海中浮現這樣的畫面：在無數個孤獨的夜晚、夜深人靜、唯有碼農還在挑燈夜戰，陶醉在代碼的世界裡，醉心於詩一般美妙的代碼邏輯中，為著對技術的追求苦戰到底。」他說，所以你會發現現實中的碼農都是骨瘦如柴、滿臉倦意、不修邊幅、睡眼惺忪，邋裡邋遢（汪建明笑稱這裡都是貶義詞褒用啊，哈哈），這是「為伊消得人憔悴」的體現；

第三層境界：眾里尋他千百度，驀然回首，那人卻在燈火闌珊處。最後一個境界，可謂是苦盡甘來，在我們持續專註、沉下心來、潛心研究、下足功夫、融會貫通、有所發現、有所成就，我們自然會達到浮躁漸去，成就、成果自然就會在「燈火闌珊」出。這是我們堅定信念、戒驕戒躁、執著追求的必然結果。

言之至此，筆者想起，訪談中多次在釘釘上找他，他無一例外的都說：「晚上回答你，現在在擼代碼。」用「擼串」中的那個「擼」來形容代碼，從字面就可以感受到那股歡快勁。當然，我們也可以想像出，那個時候或許他正幹勁十足地死磕某個技術問題。

技術之外，筆者也翻出其中有一位客戶寫給汪建明的誇獎郵件：

「今天如果沒有你的幫助我們的RDS可能會出現更加嚴重的問題。風移同學接手後迅速找到了問題發生的原因，在半個小時之內不但提出了解決方案，還幫我們完成了大部分的調優工作，及時阻止了問題向更加嚴重方向發展。調優完成後他還持續觀察了很長一段時間確保問題得到了解決。他又將處理步驟和思路發郵件給我們，並通過電話給我們詳細講解。交流過程中我們的同學也向風移同學諮詢了一些日常工作的疑惑，他也不厭其煩的為我們的同學一一解答。無論從技術的專業程度和工作敬業程度上風移同學都是無可挑剔的。」

從上段表揚信，我們不難看出，他是如何踐行客戶第一——那是真的全身心投入，解決客戶的每一個小問題，急客戶之急，想客戶之想。像他這樣，客戶怎麼會不放心，怎麼會不感動，怎麼會不成為阿里雲的忠實Fans，並用他們自己的行動來為阿里雲站台。

不論是技術，還是服務上，汪建明都無一彰顯著四個字——知行合一。知行合一，是天底下最容易，也是最難的事。而這點，你能做到嗎？（本期接受訪談的雲棲專家/風移；文/我是主題曲哥哥）

• 《沉澱》第十三期：【[沉澱]訪談阿里孫偉光：多行善事莫問前程的他，將計算集群的CPU利用率從30%提升到70%+】做事情不能單單盯著KPI，不是KPI的事情不做。

• 《沉澱》第十二期：【[沉澱]從網路中間件到搜索，從移動開發到分散式計算平台，阿里高級專家李睿博談自己的折騰路】整個過程我覺得還是愛最重要。有愛才有勇氣才有希望。我是真的愛寫代碼。從小學就開始愛，到現在快三十年了也還愛。

• 《沉澱》第十一期：【[沉澱]阿里高級專家應答：各種數據在一個統一計算平台上的融合，才能產生更大的價值】阿里巴巴這種超大數據體量上才會遇到的獨特挑戰，讓應答在技術上有了更清晰的認識，一定要夯實分散式系統的基礎。「只有把基礎夯實了，才能支持上層各種計算場景在大體量上的實現，讓各種新的演算法在『阿里體量』上真正發揮潛力。」

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！