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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　所以就得再业务层分库了

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

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

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

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

　　负载均衡

　　缓存

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

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

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

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

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

　　Linux是操作系统，Apache或Nginx是Web服务器，MySQL是数据库，PHP/Perl/python是服务器解释器。由于这四种软体都是免费或免费(FLOSS)的，所以应用这种方法可以不计成本地建立一个稳定的免费网络系统LAMP或LNMP。

　　mysql数据库本身是非常灵活的，这就导致了性能上的不足，严重依赖开发人员的能力。这就意味着开发人员的技术要高，mysql的性能要高。这也与很多数据库类型有关，所以dba的工资通常较高。

　　为了避免表字段出现空值，空值难以优化，而且占用额外的索引空间，默认值为0，而不是空值。

　　思路一：

　　思路二、修改索引：

　　索引没有更好的选择，要看是否按要求创建索引。如果是，EXPLAIN可以通过讨论中的命令和列中的命令来决定是使用索引还是完全扫描表。

　　以上便是我的一些见解和回答，可能不能如您所愿，但我真心希望能够对您有所帮助！不清楚的地方您还可以关注我的头条号“每日精彩科技”我将竭尽所知帮助您！

　　码字不易，感觉写的还行的话，还请点个赞哦！

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

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

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

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

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

　　作为一名IT行业的从业人员，主要在从事产品研发及项目管理工作，在项目过程中，经常有优化数据库存储、架构方面的方案，所以我来探讨一下这个问题。

　　目前经常使用的关系型数据库如MySQL、SQL Server等，都是以“行”为单位进行存储，为了快速检索，也都采用了B树或其他索引技术。

　　从原理上来讲，表中的数据越多，索引树的范围越大，磁盘读取也越多，性能也就越低。

　　从实践角度来看，一般以百万到千万作为一个表的存储量级，超出该范围之后，性能就会下降，需要采用其他技术手段解决。

　　首先想到的就是能否将读和写分离，主数据库用于写入，读数据库（多个）用于对外提供查询，通过数据复制的方式将主数据库的数据同步到读库。该架构提升了数据库的读写能力，但对于主数据库的写入能力依然没法扩展。

　　其次，垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。如有多种业务类型，每种业务类型建立不同的表，tb1,tb2,tb3。如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月的记录。

　　再次，水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。如按照id分表，末尾是0-9的数据分别插入到10个表里面。

　　这样做的好处就是解决了数据存储容量的问题，但也带来了诸多弊端，不再一一阐述。

　　mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。

　　而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。

　　相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。分区只需要一次本地数据迁移的操作。而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。

　　一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。

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

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

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

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

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

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

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

　　请问你描述的这个问题说的是我么？【哭脸】很不凑巧，由于预计错误本来计算大概有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)

　　3、删除掉大表中前1000万条数据

　　DELETE FROM 大表 LIMIT 10000000

　　我是按照上面的步骤搞得，会大大减少操作表所需的时间

　　不过如果问不想分库分表的话，有一个办法就是加内存，磁盘全部换固态，内存是用来查询数据时防止获取到的数据量过大而导致内存爆掉

　　换固态则会为数据的插入和读出提高速度。

　　除此之外还有什么为了提高搜索速度设置索引一类的，不过几亿的数据设置索引效果也不会太大。

　　最终，建议还是不要叫一张表数据量超过1000万，会导致出现各种问题，如果超了最方便的办法就是分库分表。

　　以上希望能对题主有帮助~~~~~~

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

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

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

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

　　

一亿数据其实也不算太大，分库分表主要是解决以前mysql不支持online ddl，现在的版本很多都支持online了，即使一些少见操作不支持online 也有解决办法，分表之后，应用复杂了。