mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？:mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文

1

mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：

1 分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法

2 读写分离。尤其是写入，放在新表中，定期进行同步。如果其中记录不断有update，最好将写的数据放在 redis中，定期同步

3 表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库

4 优化架构，或优化SQL查询，避免联表查询，尽量不要用count(*), in，递归等消耗性能的语句

5 用内存缓存，或在前端读的时候，增加缓存数据库。重复读取时，直接从缓存中读取。

上面是低成本的管理方法，基本几台服务器即可搞定，但是管理起来麻烦一些。

当然，如果整体数据量特别大的话，也不在乎投入费用的话，用集群吧，用TIDB吧

2

你不想分，就堆硬件堆带宽呗。

单表数据上亿可以采用以下方法

首先分表是必须的，然后分库。

分表可以采用按时间分，根据实际情况一个月或一个季度的分。

网站前端列表采用只查询最新表

另外是按分类分，如果数据还是大则在分类基础上再时间拆分。

然后配合缓存，再不需要及时更新的页面所有查询都只从缓存中查询。

这时候还慢的话，就再分库

分库最简单的就是读者分离，两台数据库服务器。

如果读者分离还慢，就考虑再加多台读服务器。

程序上不想改动就采用负载均衡分摊压力。

但是这样还有个问题就是，每台服务器都要保存一样的数据，及时同步，数据量大维护挺麻烦。

所以就得再业务层分库了

最简单的就是按地区分库，访问量高的地区都单独使用服务器，只保存当前地区的数据，同时该地区数据也可以再分表，分库。

业务层要做的就是在访问入口判断用户所在地区，然后访问当前地区数据库。像58同城这种带地区分站的网站都是这种策略。

一般大网站都是数据库分布式，缓存分布式，模块单独部署，负载均衡，多节点，多种技术结合在一起的。

不过一亿数据，分表和读者分离，缓存就解决了。

负载均衡

缓存

3

通常来说，Mysql表的数据量达到一两千万之后，操作起来开始有些吃力了，如果数据量达到上亿，估计系统是吃不消的。

那么解决方案有哪些呢？我提几个思路：

就用Mysql，不考虑迁移

• 分库分表其实是比较好的方案，但是已经被题主否了，就不详细说了；
  

• 表设计的优化：在设计表的时候，就要考虑性能问题了。例如字段尽量避免NULL，时间类型尽量使用TIMESTAMP，单表的字段不宜过多等等。

• 索引的优化：索引不是越多越好，也不是所有的字段都适合建立索引，使用多列索引的时候，要注意SQL中的条件顺序等。

• SQL的优化：有的时候查询慢，可能是SQL写的烂。查询尽量用到索引，避免错误的写法导致索引失效，避免使用select *查询出来所有的列，拆分复杂的SQL语句，查询使用分页等等。

• 分区：分区表是独立的逻辑表，底层由多个物理表组成，这些对用户来说是透明的；如果按照分区字段查询数据的话，就会在某一张分区表内查询，速度回比较快；分区字段的选择，需要根据你们实际业务来；比如你们这张表如果可以分100个分区的话，那么每张表实际只有100万的数据；使用分区表尽量避免全表扫描；建议考虑这种优化方式。

抛弃Mysql，迁移数据库

• 如果公司有钱的话，可以直接上商业数据库，Oracle、DB2什么的，一亿的数据还是可以搞的定的，当然会也比较贵。

• 其他开源数据库，有可以支持千万级的产品，不过不建议使用，坑会比较多。

• 云数据库，可以考虑把数据迁移到云上，比如阿里云，花一些钱，少操一些；不过如果是比较敏感的数据，放到云上，多少会不太放心；私有云？这个也贵。

另外，如果不迁移Mysql的话，可以加以非关系型数据库进行辅助，例如一些数据放到Redis里面进行缓存，或者通过跑数的方式，把原始数据加工好放到Mongodb中提供查询，总之就是减少对数据库的访问。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

4

在做垂直拆分或者水平扩展的时候，要大概清楚2亿条数据库是都经常性进行大规模的查询还是更新？这决定了你扩展的思路，如果是范范的进行扩展，有时候会起到适得其反的效果。

1.首先要检查哪些经常查询的SQL是否可以有优化的地方，检查数据库的索引建立的是否合理，索引是否有效，可以尝试建立分区表等，这一步主要是单个数据库的优化。

2.在mysql的扩展上包括垂直拆分，即分库分表的，这种需求需要在代码层实现，需要开发人员在代码层进行一些配置。这个可以起到写的负载均衡。而水平扩展说白一点就是增加服务器的个数，由原来的一台变成几台，再通过mysql的中间件，比如proxysql或者mycat进行一些配置（推荐proxysql），把写请求放在那些性能好的服务器上，把读分散到不同的服务器上，这样就起到了读的负载均衡。

3.如果上面垂直拆分或者水平扩展还是不能解决问题，可以考虑使用nosql，在前端增加一个缓存，memory cache或者redis来增加缓存，应用层在首先会读取redis里的数据，如果没有才会往MySQL里去读，当然你的查询不能是太过复杂的查询。个人推荐redis，毕竟它可以磁盘落地化。

综上所述，应该可以解决问题。当然这里只是提供思路，没有一种方案是完美的，都需要根据需求去定制。

5

软件设计表数据量太大这个是架构设计里，常遇到的问题。

先考虑优化，读写分离、合理索引、缓存数据、高频读取写进redis等产品，也可以买非常多的实例来做负载，不过这些操作撑不了多久。 分库分表几乎是唯一的，也是最好的办法。

当然分库分表大家不愿意操作，主要还是因为要改动业务代码，还有一种傻瓜式操作，不需要你改业务代码，那就是分区，例如你把数据一个月分一个区，数据库 mysql 单表数据量达到千万、亿级，可以通过分表与表分区提升服务性能。

不过你说不想分库分表，那就拿钱抗啊,上商业数据库，Oracle、DB2、PGSQL等,即使上这些数据库，你迟早还是得根据业务分库分表，这个你可以问下头条，淘宝，知乎这些大量数据的工程师，长期下去分库，分表是唯一出入。

你看京东，淘宝你的订单数据就知道了，默认显示三个月， 有可能他们就是定义最近三个月为热数据，当前常用库，之前你的订单在历史数据库里面。这样的好处，显而易见的，你的系统查询速度最大的影响因素，就是数据量。

这就像一个箱子里面装了100人，只能从上面往下面看找人， 如果你有1000人，做成10层的箱子， 要去箱子里面找出5个穿红色衣服的人很慢。 如果分成10个箱子，即使查找10次，也比在一个箱子里面快。

架构里面虽然没有什么唯一的解决办法，遇到大数据，思路基本都是统一的，减少源站数据库访问，分库分表。

6

分库分表是最常规也是最常见的一种解决数据量过大的方式。分表的话也分为垂直分和水平分。下面我列举一下其他的方式

1、读写分离。就是将数据库的读写操作分开，比如让主服务器读，从服务器去做写操作，或者让性能比较好的服务器去做写操作，性能不太好的服务器做读操作；具体如何去读写分离，要看我们如何去分了。

2、静态缓存。分为本地缓存和服务缓存，本地缓存就是将数据加载到本地，服务缓存就是比如使用Redis这样的k-v数据库进行存储热点数据。但是使用服务缓存也有缺点，最常见的问题就是，“击穿”，就是假如缓存都失效了，这时候并发请求都去访问db，此时可能造成服务器挂掉，这个时候为了避免这种情况，一般都是使用互斥量来解决这种问题。

3、系统架构。这个就要看我们整体项目的架构设计，主要是包括SQL操作的设计

7

首先很荣幸回答这个问题，我是会程序的小北。

楼主遇到的问题我想现在很多公司估计都会遇到，这也是最让人头疼的，既然楼主不想分库，又想解决眼前的难题，那么就看下我们公司的项目是怎么做的吧。

项目背景

首先描述下我们项目现在的数据库架构是主从方式，用了10套分库*3架构，每套分库mysql单表已经到达5亿，单表size 180G，对于单库QPS过万的SQL请求，mysql表已经到达一定的性能瓶颈，高峰期时不时的抖动，严重影响用户体验，并且如果开发新业务想对大表新增字段，由于硬盘空间不足，也不能快速支持新业务上线。

经过一番调研我们采用分布式数据库TiDB解决。

为啥要选择tidb？

• 在TiDB 里，你完全不用担心磁盘容量的问题，这一点在MySQL表现尤为突出。
• 在TiDB 里，原生支持 online DDL，你完全不用担心第三方改表工具改表出现各种 Bug 的问题
• 在 TiDB 里，加列，主键扩容字段都是秒级的
• 在 TiDB 里，oltp 和olap都表现的不错

• 在 TiDB 里，从 MySQL 迁移将变得简单，并且完全兼容MySQL

最终效果如何？

（1）只用了14台服务器，扛了之前40台服务器的SQL请求，节省了服务器资源。

（2）性能跟mysql持平，目前搭建的tidb集群平均每天能抗20多亿次SQL请求，QPS最高能到5万/s，并且99%的SQL请求都在60ms以内

（3）TiDB本身就是高可用的，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明，相对于基于vip切换的mysql主从架构，TiDB年可用性能到99.95%，几乎4个9

（4）纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容，吞吐跟存储都可以在线平滑扩容，提升数据库scaling能力1~2个数据量级。

（5）之前是业务维护的分库分表router，现在对于业务来说都是一张表，提升了业务的开发效率，让RD更多的关注在业务上。

（6）丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景，提升了运维效率

以上是我们的项目迁移效果，目前已经在线上平稳运行一年以上，提高了运维效率，降低了开发成本，并且能够应对流量暴增的场景。我是会点程序的小北，有问题一起探讨。

8

数据库的类型目前有这么几种：关系型数据库，nosql和最近出的newSql和时序数据库。

能支撑大数据量又保有大部分的关系数据库的功能，那非newSql数据库莫属了。

2012 年 Google 在 OSDI 上发表了 Spanner 的论文，2013 年在 SIGMOD 发表了 F1 的论文。这两篇论文让业界第一次看到了关系模型和 NoSQL 的扩展性在超庞大集群规模上融合的可能性。

NewSql数据库，国外的有CockroachDB，国内的有TiDB，TiDB有pingCap公司出品，国内的大公司已经在使用，有大公司的背书，所以我们公司也在使用，省去了使用mysql手工分库分表和使用中间件的麻烦。

9

首先，1亿的数据量就很多了？难道关系型数据库不能在5ms内返回数据？单机qps达到1000了，那响应就要5m,如果是这种就应该加缓存解决，而不是加数据库!这是读多写少的情况。当写多，可以加MQ，同步变异步写，随机写变顺序写。之后考虑一主多从架构，或多主多从，只有当单机磁盘容量不足时才考虑分库分表，或分布式数据库。当然如果是数仓应用的话，可能考虑列式存储，es+hbase

10

数据量过大怎么办？大了导致查询慢所以先在现有基础上优化慢的问题 不分库分表的情况下可以 1分区 2 加索引 3考虑应用层使用缓存少查表。 如果还是解决不了 那就使用mycat之类的 分库分表。不过mycat之类的语法上又有变化。那就上newsql数据库 像tidb之类的。底层是分布式存储 使用起来和mysql没啥差异 不用自己考虑分库分表。压力不够了直接加节点