剛超過百萬的表真不大，我做過的公司很多表都是幾百萬，個別的到了千萬，對于一般的查詢來說可以不用刻意考慮怎么存儲的問題，mysql夠扛的。而對于復(fù)雜的多連表查詢，尤其是在做數(shù)據(jù)統(tǒng)計業(yè)務(wù)時，sql操作會很復(fù)雜，會很慢，但是因?yàn)檫@個業(yè)務(wù)是對數(shù)據(jù)的實(shí)時性要求不高，我們會采用寫定時任務(wù)的方式，提前把多張表查詢跑成一張最終的結(jié)果存儲起來，我們業(yè)務(wù)上的sql直接去查這個最終表就行了。

有人說分表，橫著切分。但是我見過的公司通常不會完全這樣做，因?yàn)榉直碇蟮谋锥艘埠艽?，會?dǎo)致有些業(yè)務(wù)對該數(shù)據(jù)的操作需求實(shí)現(xiàn)不了或者很麻煩。實(shí)際的做法是，分表的同時，仍然保留整體的原表，兩份數(shù)據(jù)，一份是原表，另一份是對原表進(jìn)行切分的副本，用這個分開的表來滿足某部分業(yè)務(wù)的查詢需求即可。至于怎么分，看業(yè)務(wù)，比如說我做過一款手機(jī)游戲的app，在統(tǒng)計用戶的月活躍情況時，我會按月份分。

拋開具體的業(yè)務(wù)不談，在其他方面通常的解決方案還有：

第一：成本最低也是最實(shí)用的方式：索引優(yōu)化、sql優(yōu)化。

第二：上緩存，查詢也不一定完全就是數(shù)據(jù)量大影響的，高訪問量請求數(shù)據(jù)庫密集時，也會影響，用緩存擋在mysql前面，進(jìn)行流量削鋒。

第三：mysql讀寫分離，其實(shí)本質(zhì)也是一種負(fù)載均衡的實(shí)現(xiàn)方式。

第四：分布式，把同一份數(shù)據(jù)分到不同服務(wù)器上，這個成本就大了，一般的公司用不到，想滿足不同業(yè)務(wù)的需求對技術(shù)要求很高，較難解決的問題是在數(shù)據(jù)的一致性上。

等等，不管使用什么技術(shù)，一定要考慮好這個技術(shù)可能帶來的后果尤其弊端是什么。