一次數據庫優化的對話

 

那天夜裏的時候，我去十三哥屋裏找他，他正在敲代碼。平時我找他， 都是談技術，畢竟都是程序員，除了這一點，其它的共同愛好，咱們也沒有。

 

不過這一次，不是談技術。房子要到期了，我是要問他，是繼續合租，仍是各尋它途。 他說要去北方，他女友在北方。這點我理解，我要去東南，我女友在東南。

 

租房的事情談事後，他向我揚揚眉，有個好東西，說要告訴我。 我知道，他在炫耀，他想裝逼，他有準備。 我想用嘲笑，壓制他的炫耀，但我沒有，而是故作平靜的說：說說看。

 

他說他們公司，遇到一個問題，一個 mongodb 的數據庫，查詢時間太長。 我點點頭，表示讓他繼續。他說以前還好，數據量比較少，這段時間業務很好， 數據開始增多，查詢常常超時。我皺下眉，表示一下困惑。他繼續說， 索引也加了，能優化的都優化了，仍然超時。我看着他，沒有表情，等着他繼續。 他停頓了一下，而後問我，你以爲怎麼辦？我說我想一想。

 

我不說話，看着屋頂。他笑着看着我，看着我苦苦的思索，等待着個人答案。 我低下頭，沒有說答案，而是問向他，他們是怎麼解決的。

 

他說那天下午，他們老大找到他，講了相同的事情，問了相同的問題，他也沒有回答。 他的老大笑笑，說能夠"分表"啊。以前的表裏面，放着全部的記錄，數據快到六百萬時， 出現了查詢超時，若是按照業務劃分，能夠分紅十幾個表，每一個業務的數據，只放到本身的表裏， 每一個表的數據，都會下降不少。 他們建了新表，舊錶保持原樣，只在舊錶增長，再也不進行查詢，查詢操做，都轉移到了新表。 新表的字段，也由舊錶的九個，變爲如今的四個，這四個是必須的，多餘的所有去除。 他們分表事後，效果確實很好，每次都不超時。

 

他看着我，表情透着知足，那是學到新知識後的表情。

 

我繼續問他，他們的業務有多少，他說十八個。我說那就是十八個表，他說是的。 我又問他，數據最多的業務，佔總數據的多少，他說大概一半。 我繼續問，若是說，我說若是，大家公司很牛逼，全部業務都增加加倍， 目前最好的業務，之後的數據量，可能和如今的總數據量同樣，那時候該怎麼辦？

 

他皺皺眉，說確實也是個問題。

 

我問他，查詢時的條件，是什麼數據類型，他說三十六位的字符串，相似 MD5。 我說能夠對這個字段作 HASH ，散列到多個表，好比 128 個表，若是 HASH 函數選的比較好， 結果比較隨機，那麼每一個表的數據，也會比較隨機，表裏的數據就會比較平均， 這樣就能讓表裏的數據，下降兩個數量級。並且業務改變了，也不影響表的結構。

 

他說看起來，這樣倒也行。

 

他問我，這方法，是從哪裏看到的，我說本身想到的。他說別吹牛逼，快點告訴我。 我說我也忘了，這是我本身想到的，仍是從哪裏看到的。不過如今，這知識已經和我融爲一體，那就是個人了。

 

十三哥戲謔的看着我，說：你又開始裝逼了......

---

同步發表：http://www.fengbohello.top/blog/p/split-table