关于问题mysql 表数据量太大，达到了 1 亿多条数据，除了分库分表之外，还有没有其他的解决方式？一共有 2 位热心网友为你解答:
【1】、来自网友【会点代码的大叔】的最佳回答：
通常来说，Mysql 表的数据量达到一两千万之后，操作起来开始有些吃力了，如果数据量达到上亿，估计系统是吃不消的。
那么解决方案有哪些呢？我提几个思路：
就用 Mysql，不考虑迁移
- 分库分表其实是比较好的方案，但是已经被题主否了，就不详细说了；
-
表设计的优化：在设计表的时候，就要考虑性能问题了。例如字段尽量避免 NULL，时间类型尽量使用 TIMESTAMP，单表的字段不宜过多等等。
-
索引的优化：索引不是越多越好，也不是所有的字段都适合建立索引，使用多列索引的时候，要注意 SQL 中的条件顺序等。
-
SQL 的优化：有的时候查询慢，可能是 SQL 写的烂。查询尽量用到索引，避免错误的写法导致索引失效，避免使用 select *查询出来所有的列，拆分复杂的 SQL 语句，查询使用分页等等。
-
分区：分区表是独立的逻辑表，底层由多个物理表组成，这些对用户来说是透明的；如果按照分区字段查询数据的话，就会在某一张分区表内查询，速度回比较快；分区字段的选择，需要根据你们实际业务来；比如你们这张表如果可以分 100 个分区的话，那么每张表实际只有 100 万的数据；使用分区表尽量避免全表扫描；
建议考虑这种优化方式。
抛弃 Mysql，迁移数据库
-
如果公司有钱的话，可以直接上商业数据库，Oracle、DB2 什么的，一亿的数据还是可以搞的定的，当然会也比较贵。
-
其他开源数据库，有可以支持千万级的产品，不过不建议使用，坑会比较多。
-
云数据库，可以考虑把数据迁移到云上，比如阿里云，花一些钱，少操一些；不过如果是比较敏感的数据，放到云上，多少会不太放心；私有云？这个也贵。
另外，如果不迁移 Mysql 的话，可以加以非关系型数据库进行辅助，例如一些数据放到 Redis 里面进行缓存，或者通过跑数的方式，把原始数据加工好放到 Mongodb 中提供查询，总之就是减少对数据库的访问。
我将持续分享 Java 开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
【2】、来自网友【卖螺丝的程序员】的最佳回答：
你不想分，就堆硬件堆带宽呗。
单表数据上亿可以采用以下方法
首先分表是必须的，然后分库。
分表可以采用按时间分，根据实际情况一个月或一个季度的分。
网站前端列表采用只查询最新表
另外是按分类分，如果数据还是大则在分类基础上再时间拆分。
然后配合缓存，再不需要及时更新的页面所有查询都只从缓存中查询。
这时候还慢的话，就再分库
分库最简单的就是读者分离，两台数据库服务器。
如果读者分离还慢，就考虑再加多台读服务器。
程序上不想改动就采用负载均衡分摊压力。
但是这样还有个问题就是，每台服务器都要保存一样的数据，及时同步，数据量大维护挺麻烦。
所以就得再业务层分库了
最简单的就是按地区分库，访问量高的地区都单独使用服务器，只保存当前地区的数据，同时该地区数据也可以再分表，分库。
业务层要做的就是在访问入口判断用户所在地区，然后访问当前地区数据库。像 58 同城这种带地区分站的网站都是这种策略。
一般大网站都是数据库分布式，缓存分布式，模块单独部署，负载均衡，多节点，多种技术结合在一起的。
不过一亿数据，分表和读者分离，缓存就解决了。
负载均衡
缓存
