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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

很高兴能够看到和这个问题,作为一个问答爱好者，我每天都在关注各个方面的消息，每天收获也蛮多的。下面我将根据自己的经验认真这个问题。

mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？

MySQL是世界上最受欢迎的开源数据库。凭借其经过验证的性能，可靠性和易用性，MySQL已成为基于Web的应用程序的领先数据库选择，被包括Facebook，Twitter，You Tube，Yahool等在内的知名Web财产所使用。

Oracle推动MySQL创新，提供了支持下一代Web，云服务，移动和嵌入式应用程序的新功能。MysQL是数据库的相对控制系统。它将数据存储在不同的表中，而不是存储空间较广，从而提高了速度和灵活性。

MySQL是最常用的访问数据库的语言。根据双因素认证政策，MySQL软件开发分为社区版和商业版。功率大、速度快、规模小、成本低，特别是使用开源数据库，因为整个网站都是选用MySQL。

例如，MysQL为中小企业提供了比Oracle、DB2、SQL Server、SQL Server等个人用户更多的机会。由于MySQL是开源软件，这可能会大大降低整体成本。

请问你描述的这个问题说的是我么？【哭脸】很不凑巧，由于预计错误本来计算大概有800多万的数据，最终处理完共计4亿9千多万【后面的零头我甚至不想说了】,一张表4亿多的数据，用的自增id幸亏id没有爆，不幸中的万幸透露着另一个不幸就是，因为这台装有mysql的服务器上数据量很大，在我往里插入数据的时候在插到4亿多的时候磁盘满了，一点空间都没有了，惊不惊喜意不意外【哭笑脸】,因为这个数据属于一次性的数据，用于进行深度学习所需的训练数据，但是读的压力也很大，随便一个select7分钟起步~~~~

难难难啊！最后我的解决办法就是删除了当前服务器上的一部分日志，让mysql可以动起来，然后将数据按1000万一个的导成小表，然后把大表数据删除，步骤大概是

1、新建一个表结构一致的表后缀按照xxx_0,xxx_1 等方式命名

2、将大表中的1000万数据导入创建的表中命令为

INSERT INTO `小表_01` (`xxx`) (SELECT `xxxx` FROM `大表` LIMIT 0, 10000000)

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

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

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

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

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

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

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

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

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