我記得這次面試好像也沒人問我，但是兩年前有人問過我，當時我非常牛逼，就回答了一句：當然是分表啊！然后就沒有然后了，今天我來重新審視一下這個問題。
“假如一個表太大了，怎么辦？”
既然問這個問題了，那么一定是這個表出問題了才會問，如果不出問題誰吃飽撐的研究這個。
一般情況單表誰過於大了，對查詢速度會產生比較大的影響。但是也不代表一定要分表，我覺得首先第一步要做的就是確認一下在這個表上的sql慢查詢是哪個。然后看看有沒有索引，如果沒有就加；如果有，就考慮是不是索引加的不太對。這是一個需要反復探索的過程，需要大量使用explain語句進行分析嘗試。如果說索引已經沒問題，就是因為數據量太大導致的，也並不代表一定要分表，這會兒可以考慮緩存的介入能不能解決問題，如果通過引入緩存可以快速解決壓力，就可以先通過引入緩存來作為過渡方案。
以上是成熟的回答，因為但凡一個項目因為表太大出問題了，首先要考慮的就是最快時間內先解決了這個問題。分表是最后的解決方案，因為需要太多的時間。
那么以上都用上了，考慮過了，就確實不得不考慮分表了。那么分表如何操作？
1、通過程序進行分表。這里需要注意的是，一般分表都是只能通過某一個維度進行分表，這個要具體看你的業務需求。比如用戶粉絲表，有些大v用戶可能會有很多粉絲，假設我們數據表結構是下面這樣的：
| First Header | Second Header | Third Header |
|---|---|---|
| master | slave | createtime |
其中master是大v的uid，slave是他粉絲的uid。這個表可能是已經一億以上數據了，在每次查詢我的粉絲的時候，會比較慢，那么現在根據業務場景需求，我們需要根據uid這個維度進行分表。分表的算法則是多種多樣的，一般情況下都是通過取余的方式進行的。如果我們要分成10個表，那么就通過如下算法確定大v的數據將會落入到哪個表中：table_name = uid % 10。
這種分表需要你提前預估數據量，因為一旦分表確定了，如果再分表，所有的數據就會亂掉，必須提前將數據重新計算好。
這個時候，對程序將會有比較大的改動。首先你要琢磨從這個表讀取數據的場景有哪些，改掉；其次，你要確定往這個表寫入的場景有哪些，改掉；
2、這種辦法非常偷懶，但是可以解放RD的壓力，那就是通過mysql中間件來解決。一般套路是在中間件中配置分表規則，一般也是分表維度和分表數量。這樣，程序要改動的地方只需要把數據庫連接地址修改為中間件的地址就可以了，剩下的邏輯全部靠中間件來完成。
下面我再補充一個問題，就是如果分表后，雖然能滿足你對uid的查詢了，但是破壞了其他維度的查詢。比如上面那個表偏偏有個業務是通過slave來查詢的，此時分表了，怎么辦？因為同一個slave可能會分布散落不不同的數據表中，怎么辦？
一般套路就是雙寫，就是分表的時候，除了維護對master維度的表，同時再維護一個對slave維度的表。
高級點兒的套路就是，建立專門的搜索引擎，可以通過es來實現。這個就比較高端了，一般不推薦。