mysql表数据量太大，达到了1亿多条数据，除了分库分表之外

　　通常来说，Mysql表的数据量达到一两千万之后，操作起来开始有些吃力了，如果数据量达到上亿，估计系统是吃不消的。
　　那么解决方案有哪些呢？我提几个思路：
　　就用Mysql，不考虑迁移分库分表其实是比较好的方案，但是已经被题主否了，就不详细说了；
　　表设计的优化：在设计表的时候，就要考虑性能问题了。例如字段尽量避免NULL，时间类型尽量使用TIMESTAMP，单表的字段不宜过多等等。
　　索引的优化：索引不是越多越好，也不是所有的字段都适合建立索引，使用多列索引的时候，要注意SQL中的条件顺序等。
　　SQL的优化：有的时候查询慢，可能是SQL写的烂。查询尽量用到索引，避免错误的写法导致索引失效，避免使用select查询出来所有的列，拆分复杂的SQL语句，查询使用分页等等。
　　分区：分区表是独立的逻辑表，底层由多个物理表组成，这些对用户来说是透明的；如果按照分区字段查询数据的话，就会在某一张分区表内查询，速度回比较快；分区字段的选择，需要根据你们实际业务来；比如你们这张表如果可以分100个分区的话，那么每张表实际只有100万的数据；使用分区表尽量避免全表扫描；建议考虑这种优化方式。抛弃Mysql，迁移数据库
　　如果公司有钱的话，可以直接上商业数据库，Oracle、DB2什么的，一亿的数据还是可以搞的定的，当然会也比较贵。
　　其他开源数据库，有可以支持千万级的产品，不过不建议使用，坑会比较多。
　　云数据库，可以考虑把数据迁移到云上，比如阿里云，花一些钱，少操一些；不过如果是比较敏感的数据，放到云上，多少会不太放心；私有云？这个也贵。
　　另外，如果不迁移Mysql的话，可以加以非关系型数据库进行辅助，例如一些数据放到Redis里面进行缓存，或者通过跑数的方式，把原始数据加工好放到Mongodb中提供查询，总之就是减少对数据库的访问。
　　我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
　　你不想分，就堆硬件堆带宽呗。
　　单表数据上亿可以采用以下方法
　　首先分表是必须的，然后分库。
　　分表可以采用按时间分，根据实际情况一个月或一个季度的分。
　　网站前端列表采用只查询最新表
　　另外是按分类分，如果数据还是大则在分类基础上再时间拆分。
　　然后配合缓存，再不需要及时更新的页面所有查询都只从缓存中查询。
　　这时候还慢的话，就再分库
　　分库最简单的就是读者分离，两台数据库服务器。
　　如果读者分离还慢，就考虑再加多台读服务器。
　　程序上不想改动就采用负载均衡分摊压力。
　　但是这样还有个问题就是，每台服务器都要保存一样的数据，及时同步，数据量大维护挺麻烦。
　　所以就得再业务层分库了
　　最简单的就是按地区分库，访问量高的地区都单独使用服务器，只保存当前地区的数据，同时该地区数据也可以再分表，分库。
　　业务层要做的就是在访问入口判断用户所在地区，然后访问当前地区数据库。像58同城这种带地区分站的网站都是这种策略。
　　一般大网站都是数据库分布式，缓存分布式，模块单独部署，负载均衡，多节点，多种技术结合在一起的。
　　不过一亿数据，分表和读者分离，缓存就解决了。
　　负载均衡
　　缓存
　　很高兴能够看到和回答这个问题，作为一个悟空问答爱好者，我每天都在关注各个方面的消息，每天收获也蛮多的。下面我将根据自己的经验认真回答这个问题。mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
　　MySQL是世界上最受欢迎的开源数据库。凭借其经过验证的性能，可靠性和易用性，MySQL已成为基于Web的应用程序的领先数据库选择，被包括Facebook，Twitter，YouTube，Yahool等在内的知名Web财产所使用。
　　Oracle推动MySQL创新，提供了支持下一代Web，云服务，移动和嵌入式应用程序的新功能。MysQL是数据库的相对控制系统。它将数据存储在不同的表中，而不是存储空间较广，从而提高了速度和灵活性。
　　MySQL是最常用的访问数据库的语言。根据双因素认证政策，MySQL软件开发分为社区版和商业版。功率大、速度快、规模小、成本低，特别是使用开源数据库，因为整个网站都是选用MySQL。
　　例如，MysQL为中小企业提供了比Oracle、DB2、SQLServer、SQLServer等个人用户更多的机会。由于MySQL是开源软件，这可能会大大降低整体成本。
　　Linux是操作系统，Apache或Nginx是Web服务器，MySQL是数据库，PHPPerlpython是服务器解释器。由于这四种软体都是免费或免费（FLOSS）的，所以应用这种方法可以不计成本地建立一个稳定的免费网络系统LAMP或LNMP。
　　mysql数据库本身是非常灵活的，这就导致了性能上的不足，严重依赖开发人员的能力。这就意味着开发人员的技术要高，mysql的性能要高。这也与很多数据库类型有关，所以dba的工资通常较高。
　　为了避免表字段出现空值，空值难以优化，而且占用额外的索引空间，默认值为0，而不是空值。mysql表数据量太大，达到了1亿多条数据，我们该怎么办呢？
　　思路一：用INT代替BIGINT，加上UNSIGNED（这样体积会翻倍），当然可以用TINT、SmalLINT和MEDIUM。inti更好。用列表或整数代替字符串类型使用TIMSTATIME代替DATETIME。表上的字段不要太多，建议20岁以下。保持IP的完整性
　　思路二、修改索引：
　　索引没有更好的选择，要看是否按要求创建索引。如果是，EXPLAIN可以通过讨论中的命令和列中的命令来决定是使用索引还是完全扫描表。不能根据子程序中NULL的值来判断，否则可能会导致引擎在完全扫描表时停止使用索引。值分布非常罕见的字段不适合做索引。例如，性别只有两个重要区域。字符字段只包含前缀。字符字段不应该是主键。不要使用通过软件连接的外部键。不要使用UNIQUE使用多行索引将保留搜索和条件序列，不必要的独立索引将被删除。
　　以上便是我的一些见解和回答，可能不能如您所愿，但我真心希望能够对您有所帮助！不清楚的地方您还可以关注我的头条号每日精彩科技我将竭尽所知帮助您！
　　码字不易，感觉写的还行的话，还请点个赞哦！
　　软件设计表数据量太大这个是架构设计里，常遇到的问题。
　　先考虑优化，读写分离、合理索引、缓存数据、高频读取写进redis等产品，也可以买非常多的实例来做负载，不过这些操作撑不了多久。分库分表几乎是唯一的，也是最好的办法。
　　当然分库分表大家不愿意操作，主要还是因为要改动业务代码，还有一种傻瓜式操作，不需要你改业务代码，那就是分区，例如你把数据一个月分一个区，数据库mysql单表数据量达到千万、亿级，可以通过分表与表分区提升服务性能。
　　不过你说不想分库分表，那就拿钱抗啊，上商业数据库，Oracle、DB2、PGSQL等，即使上这些数据库，你迟早还是得根据业务分库分表，这个你可以问下头条，淘宝，知乎这些大量数据的工程师，长期下去分库，分表是唯一出入。
　　你看京东，淘宝你的订单数据就知道了，默认显示三个月，有可能他们就是定义最近三个月为热数据，当前常用库，之前你的订单在历史数据库里面。这样的好处，显而易见的，你的系统查询速度最大的影响因素，就是数据量。
　　这就像一个箱子里面装了100人，只能从上面往下面看找人，如果你有1000人，做成10层的箱子，要去箱子里面找出5个穿红色衣服的人很慢。如果分成10个箱子，即使查找10次，也比在一个箱子里面快。
　　架构里面虽然没有什么唯一的解决办法，遇到大数据，思路基本都是统一的，减少源站数据库访问，分库分表。
　　在做垂直拆分或者水平扩展的时候，要大概清楚2亿条数据库是都经常性进行大规模的查询还是更新？这决定了你扩展的思路，如果是范范的进行扩展，有时候会起到适得其反的效果。
　　1。首先要检查哪些经常查询的SQL是否可以有优化的地方，检查数据库的索引建立的是否合理，索引是否有效，可以尝试建立分区表等，这一步主要是单个数据库的优化。
　　2。在mysql的扩展上包括垂直拆分，即分库分表的，这种需求需要在代码层实现，需要开发人员在代码层进行一些配置。这个可以起到写的负载均衡。而水平扩展说白一点就是增加服务器的个数，由原来的一台变成几台，再通过mysql的中间件，比如proxysql或者mycat进行一些配置（推荐proxysql），把写请求放在那些性能好的服务器上，把读分散到不同的服务器上，这样就起到了读的负载均衡。
　　3。如果上面垂直拆分或者水平扩展还是不能解决问题，可以考虑使用nosql，在前端增加一个缓存，memorycache或者redis来增加缓存，应用层在首先会读取redis里的数据，如果没有才会往MySQL里去读，当然你的查询不能是太过复杂的查询。个人推荐redis，毕竟它可以磁盘落地化。
　　综上所述，应该可以解决问题。当然这里只是提供思路，没有一种方案是完美的，都需要根据需求去定制。
　　请问你描述的这个问题说的是我么？【哭脸】很不凑巧，由于预计错误本来计算大概有800多万的数据，最终处理完共计4亿9千多万【后面的零头我甚至不想说了】，一张表4亿多的数据，用的自增id幸亏id没有爆，不幸中的万幸透露着另一个不幸就是，因为这台装有mysql的服务器上数据量很大，在我往里插入数据的时候在插到4亿多的时候磁盘满了，一点空间都没有了，惊不惊喜意不意外【哭笑脸】，因为这个数据属于一次性的数据，用于进行深度学习所需的训练数据，但是读的压力也很大，随便一个select7分钟起步
　　难难难啊！最后我的解决办法就是删除了当前服务器上的一部分日志，让mysql可以动起来，然后将数据按1000万一个的导成小表，然后把大表数据删除，步骤大概是
　　1、新建一个表结构一致的表后缀按照xxx0，xxx1等方式命名
　　2、将大表中的1000万数据导入创建的表中命令为
　　INSERTINTO小表01（xxx）（SELECTxxxxFROM大表LIMIT0，10000000）
　　3、删除掉大表中前1000万条数据
　　DELETEFROM大表LIMIT10000000
　　我是按照上面的步骤搞得，会大大减少操作表所需的时间
　　不过如果问不想分库分表的话，有一个办法就是加内存，磁盘全部换固态，内存是用来查询数据时防止获取到的数据量过大而导致内存爆掉
　　换固态则会为数据的插入和读出提高速度。
　　除此之外还有什么为了提高搜索速度设置索引一类的，不过几亿的数据设置索引效果也不会太大。
　　最终，建议还是不要叫一张表数据量超过1000万，会导致出现各种问题，如果超了最方便的办法就是分库分表。
　　以上希望能对题主有帮助
　　作为一名IT行业的从业人员，主要在从事产品研发及项目管理工作，在项目过程中，经常有优化数据库存储、架构方面的方案，所以我来探讨一下这个问题。
　　目前经常使用的关系型数据库如MySQL、SQLServer等，都是以行为单位进行存储，为了快速检索，也都采用了B树或其他索引技术。
　　从原理上来讲，表中的数据越多，索引树的范围越大，磁盘读取也越多，性能也就越低。
　　从实践角度来看，一般以百万到千万作为一个表的存储量级，超出该范围之后，性能就会下降，需要采用其他技术手段解决。
　　首先想到的就是能否将读和写分离，主数据库用于写入，读数据库（多个）用于对外提供查询，通过数据复制的方式将主数据库的数据同步到读库。该架构提升了数据库的读写能力，但对于主数据库的写入能力依然没法扩展。
　　其次，垂直分表就是把一个数据量很大的表，可以按某个字段的属性或使用频繁程度分类，拆分为多个表。如有多种业务类型，每种业务类型建立不同的表，tb1，tb2，tb3。如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月的记录。
　　再次，水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。如按照id分表，末尾是09的数据分别插入到10个表里面。
　　这样做的好处就是解决了数据存储容量的问题，但也带来了诸多弊端，不再一一阐述。
　　mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。
　　而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。
　　相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。分区只需要一次本地数据迁移的操作。而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。
　　一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。
　　分库分表是最常规也是最常见的一种解决数据量过大的方式。分表的话也分为垂直分和水平分。下面我列举一下其他的方式
　　1、读写分离。就是将数据库的读写操作分开，比如让主服务器读，从服务器去做写操作，或者让性能比较好的服务器去做写操作，性能不太好的服务器做读操作；具体如何去读写分离，要看我们如何去分了。
　　2、静态缓存。分为本地缓存和服务缓存，本地缓存就是将数据加载到本地，服务缓存就是比如使用Redis这样的kv数据库进行存储热点数据。但是使用服务缓存也有缺点，最常见的问题就是，击穿，就是假如缓存都失效了，这时候并发请求都去访问db，此时可能造成服务器挂掉，这个时候为了避免这种情况，一般都是使用互斥量来解决这种问题。
　　3、系统架构。这个就要看我们整体项目的架构设计，主要是包括SQL操作的设计
　　一亿数据其实也不算太大，分库分表主要是解决以前mysql不支持onlineddl，现在的版本很多都支持online了，即使一些少见操作不支持online也有解决办法，分表之后，应用复杂了。
　　下面，我将用2分钟的时间，与您深入探讨，mysql表数据量达1亿多条时，应该采取什么措施，如果您有不同的见解，可以在评论区与我交流。（文末有免费福利）如果你不嫌麻烦，或不计成本，请看以下几个方法
　　方法一：换机器，加硬盘，加内存。
　　方法二：聘请一个数据顾问。
　　方法三：看数据增量，每行数据的大小，一亿数据，如果操作简单的话，也不是没法处理。
　　方法四：一亿多都是需要的记录么？对于不需要的记录，可以定时归档。
　　方法挺多，但都要根据情况细分，有点儿麻烦。如果你想走捷径，拿来即用，那么请看这里
　　用云表内嵌的MySQL数据库，其研发团队一直在升级维护MySQL，性能得以优化，存储一亿数据量，不是问题。
　　因为专业且强大，所以MySQL是90的企业都会选择的数据库。
　　如果你觉得不合适，那么你也可以根据云表的帮助文档，设置成sqlserver，Oracle数据库。
　　我们都知道数据库的作用巨大，正是因为有了数据库，我们可以直接查找数据。
　　例如你每天使用余额宝查看自己的账户收益，就是从数据库读取数据后给你的。
　　你的银行卡账号，密码里面的RMB等等都是查询的数据库。
　　之所以建议你使用云表内嵌的MySQL数据库，是因为，通过云表，还可以与企业微信、钉钉、用友金蝶、浪潮等第三方系统进行对接。
　　而MySQL数据库作用范围下的，erp，oa，wms，商业智能（BI），进销存等各类业务应用，通过它也是可以开发出来的。
　　并且开发出来的业务应用，秉承了MySQL语句增删改查的特性。
　　没错，用云表开发出来的业务应用，功能是随时可以增删查改的。
　　事实上，云表就是一个办公软件开发工具。
　　由于云表内嵌了MySQL数据库的原因，所以通过它可以进行复杂的数据运算，如数据透视，数据分析等，亿级数据，秒级响应。
　　还可以对它设置精确到行列的权限管控，进行工作流，流程审批，多人协同等工作。
　　当然啦，其他大大小小的业务，也是可以解决的。
　　比如说制作报表看板，H5页面生成，扫码出入库，与API接口进行对接，封装PDA，闹钟提醒，群发信息，生成移动端app。。。。。。
　　像许继电气，中冶，中铁，香港建滔集团，南方物流，燕山大学等，都在使用它。可以免费使用
　　目前，云表是有提供永久免费版本的。内嵌的MySQL数据库，数据安全不丢失
　　它的数据存储方式有：本地部署，云端部署，混合部署等多种部署方式。
　　也就是说，云表不仅内嵌了MySQL数据库，而且还保证了数据的安全。
　　篇幅所限，就说到这里。
　　高山流水，终须一别。免费的软件获取方式在此奉上。
　　1。点赞评论转发
　　2。关注我，点击我的头像，私信给我发送：cc
　　如果不是特别必要，我建议还是不要瞎折腾，不然数据库没搞好，还会添一堆麻烦事儿！
　　首先，1亿的数据量就很多了？难道关系型数据库不能在5ms内返回数据？单机qps达到1000了，那响应就要5m，如果是这种就应该加缓存解决，而不是加数据库！这是读多写少的情况。当写多，可以加MQ，同步变异步写，随机写变顺序写。之后考虑一主多从架构，或多主多从，只有当单机磁盘容量不足时才考虑分库分表，或分布式数据库。当然如果是数仓应用的话，可能考虑列式存储，eshbase