mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
≉↕mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
通常来说，Mysql表的数据量达到一两千万之后，操作起来开始有些吃力了，如果数据量达到上亿，估计系统是吃不消的。
那么解决方案有哪些呢？我提几个思路：
就用Mysql，不考虑迁移
分库分表其实是比较好的方案，但是已经被题主否了，就不详细说了；表设计的优化：在设计表的时候，就要考虑性能问题了。例如字段尽量避免NULL，时间类型尽量使用TIMESTAMP，单表的字段不宜过多等等。
索引的优化：索引不是越多越好，也不是所有的字段都适合建立索引，使用多列索引的时候，要注意SQL中的条件顺序等。
SQL的优化：有的时候查询慢，可能是SQL写的烂。查询尽量用到索引，避免错误的写法导致索引失效，避免使用select *查询出来所有的列，拆分复杂的SQL语句，查询使用分页等等。
分区：分区表是独立的逻辑表，底层由多个物理表组成，这些对用户来说是透明的；如果按照分区字段查询数据的话，就会在某一张分区表内查询，速度回比较快；分区字段的选择，需要根据你们实际业务来；比如你们这张表如果可以分100个分区的话，那么每张表实际只有100万的数据；使用分区表尽量避免全表扫描；建议考虑这种优化方式。
抛弃Mysql，迁移数据库
如果公司有钱的话，可以直接上商业数据库，Oracle、DB2什么的，一亿的数据还是可以搞的定的，当然会也比较贵。
其他开源数据库，有可以支持千万级的产品，不过不建议使用，坑会比较多。
云数据库，可以考虑把数据迁移到云上，比如阿里云，花一些钱，少操一些；不过如果是比较敏感的数据，放到云上，多少会不太放心；私有云？这个也贵。
另外，如果不迁移Mysql的话，可以加以非关系型数据库进行辅助，例如一些数据放到Redis里面进行缓存，或者通过跑数的方式，把原始数据加工好放到Mongodb中提供查询，总之就是减少对数据库的访问。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
☯↤mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
很高兴能够看到和回答这个问题,作为一个悟空问答爱好者，我每天都在关注各个方面的消息，每天收获也蛮多的。下面我将根据自己的经验认真回答这个问题。
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是开源软件，这可能会大大降低整体成本。
Linux是操作系统，Apache或Nginx是Web服务器，MySQL是数据库，PHP/Perl/python是服务器解释器。由于这四种软体都是免费或免费(FLOSS)的，所以应用这种方法可以不计成本地建立一个稳定的免费网络系统LAMP或LNMP。
mysql数据库本身是非常灵活的，这就导致了性能上的不足，严重依赖开发人员的能力。这就意味着开发人员的技术要高，mysql的性能要高。这也与很多数据库类型有关，所以dba的工资通常较高。
为了避免表字段出现空值，空值难以优化，而且占用额外的索引空间，默认值为0，而不是空值。
mysql表数据量太大，达到了1亿多条数据，我们该怎么办呢？
思路一：
用INT代替BIGINT，加上UNSIGNED(这样体积会翻倍)，当然可以用TINT、SmalLINT和MEDIUM.inti更好。用列表或整数代替字符串类型使用TIMSTATIME代替DATETIME。表上的字段不要太多，建议20岁以下。保持IP的完整性思路二、修改索引：
索引没有更好的选择，要看是否按要求创建索引。如果是，EXPLAIN可以通过讨论中的命令和列中的命令来决定是使用索引还是完全扫描表。
不能根据子程序中NULL的值来判断，否则可能会导致引擎在完全扫描表时停止使用索引。值分布非常罕见的字段不适合做索引。例如，性别只有两个重要区域。字符字段只包含前缀。字符字段不应该是主键。不要使用通过软件连接的外部键。不要使用UNIQUE使用多行索引将保留搜索和条件序列，不必要的独立索引将被删除。以上便是我的一些见解和回答，可能不能如您所愿，但我真心希望能够对您有所帮助！不清楚的地方您还可以关注我的头条号“每日精彩科技”我将竭尽所知帮助您！
码字不易，感觉写的还行的话，还请点个赞哦！
❧ϟmysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
作为一名IT行业的从业人员，主要在从事产品研发及项目管理工作，在项目过程中，经常有优化数据库存储、架构方面的方案，所以我来探讨一下这个问题。
目前经常使用的关系型数据库如MySQL、SQL Server等，都是以“行”为单位进行存储，为了快速检索，也都采用了B树或其他索引技术。
从原理上来讲，表中的数据越多，索引树的范围越大，磁盘读取也越多，性能也就越低。
从实践角度来看，一般以百万到千万作为一个表的存储量级，超出该范围之后，性能就会下降，需要采用其他技术手段解决。
首先想到的就是能否将读和写分离，主数据库用于写入，读数据库（多个）用于对外提供查询，通过数据复制的方式将主数据库的数据同步到读库。该架构提升了数据库的读写能力，但对于主数据库的写入能力依然没法扩展。
其次，垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。如有多种业务类型，每种业务类型建立不同的表，tb1,tb2,tb3。如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月的记录。
再次，水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。如按照id分表，末尾是0-9的数据分别插入到10个表里面。
这样做的好处就是解决了数据存储容量的问题，但也带来了诸多弊端，不再一一阐述。
mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。
而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。
相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。分区只需要一次本地数据迁移的操作。而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。
一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。
✻♛mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
在做垂直拆分或者水平扩展的时候，要大概清楚2亿条数据库是都经常性进行大规模的查询还是更新？这决定了你扩展的思路，如果是范范的进行扩展，有时候会起到适得其反的效果。
1.首先要检查哪些经常查询的SQL是否可以有优化的地方，检查数据库的索引建立的是否合理，索引是否有效，可以尝试建立分区表等，这一步主要是单个数据库的优化。
2.在mysql的扩展上包括垂直拆分，即分库分表的，这种需求需要在代码层实现，需要开发人员在代码层进行一些配置。这个可以起到写的负载均衡。而水平扩展说白一点就是增加服务器的个数，由原来的一台变成几台，再通过mysql的中间件，比如proxysql或者mycat进行一些配置（推荐proxysql），把写请求放在那些性能好的服务器上，把读分散到不同的服务器上，这样就起到了读的负载均衡。
3.如果上面垂直拆分或者水平扩展还是不能解决问题，可以考虑使用nosql，在前端增加一个缓存，memory cache或者redis来增加缓存，应用层在首先会读取redis里的数据，如果没有才会往MySQL里去读，当然你的查询不能是太过复杂的查询。个人推荐redis，毕竟它可以磁盘落地化。
综上所述，应该可以解决问题。当然这里只是提供思路，没有一种方案是完美的，都需要根据需求去定制。
┃♐mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
软件设计表数据量太大这个是架构设计里，常遇到的问题。
先考虑优化，读写分离、合理索引、缓存数据、高频读取写进redis等产品，也可以买非常多的实例来做负载，不过这些操作撑不了多久。 分库分表几乎是唯一的，也是最好的办法。
当然分库分表大家不愿意操作，主要还是因为要改动业务代码，还有一种傻瓜式操作，不需要你改业务代码，那就是分区，例如你把数据一个月分一个区，数据库 mysql 单表数据量达到千万、亿级，可以通过分表与表分区提升服务性能。
不过你说不想分库分表，那就拿钱抗啊,上商业数据库，Oracle、DB2、PGSQL等,即使上这些数据库，你迟早还是得根据业务分库分表，这个你可以问下头条，淘宝，知乎这些大量数据的工程师，长期下去分库，分表是唯一出入。
你看京东，淘宝你的订单数据就知道了，默认显示三个月， 有可能他们就是定义最近三个月为热数据，当前常用库，之前你的订单在历史数据库里面。这样的好处，显而易见的，你的系统查询速度最大的影响因素，就是数据量。
这就像一个箱子里面装了100人，只能从上面往下面看找人， 如果你有1000人，做成10层的箱子， 要去箱子里面找出5个穿红色衣服的人很慢。 如果分成10个箱子，即使查找10次，也比在一个箱子里面快。
架构里面虽然没有什么唯一的解决办法，遇到大数据，思路基本都是统一的，减少源站数据库访问，分库分表。
------------------
推荐阅读：
下一篇： 练毛笔字的时候竖笔总是写不直，怎么提高？
