剛超過百萬的表真不大，我做過的公司很多表都是幾百萬，個別的到了千萬，對於一般的查詢來說可以不用刻意考慮怎麼儲存的問題，mysql夠扛的。而對於複雜的多連表查詢，尤其是在做資料統計業務時，sql操作會很複雜，會很慢，但是因為這個業務是對資料的實時性要求不高，我們會採用寫定時任務的方式，提前把多張表查詢跑成一張最終的結果儲存起來，我們業務上的sql直接去查這個最終表就行了。

有人說分表，橫著切分。但是我見過的公司通常不會完全這樣做，因為分表之後的弊端也很大，會導致有些業務對該資料的操作需求實現不了或者很麻煩。實際的做法是，分表的同時，仍然保留整體的原表，兩份資料，一份是原表，另一份是對原表進行切分的副本，用這個分開的表來滿足某部分業務的查詢需求即可。至於怎麼分，看業務，比如說我做過一款手機遊戲的app，在統計使用者的月活躍情況時，我會按月份分。

拋開具體的業務不談，在其他方面通常的解決方案還有：

第一：成本最低也是最實用的方式：索引最佳化、sql最佳化。

第二：上快取，查詢也不一定完全就是資料量大影響的，高訪問量請求資料庫密集時，也會影響，用快取擋在mysql前面，進行流量削鋒。

第三：mysql讀寫分離，其實本質也是一種負載均衡的實現方式。

第四：分散式，把同一份資料分到不同伺服器上，這個成本就大了，一般的公司用不到，想滿足不同業務的需求對技術要求很高，較難解決的問題是在資料的一致性上。

等等，不管使用什麼技術，一定要考慮好這個技術可能帶來的後果尤其弊端是什麼。