什么叫差异 mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：
1 分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法
2 读写分离。尤其是写入，放在新表中，定期进行同步。如果其中记录不断有update，最好将写的数据放在 redis中，定期同步
3 表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库
4 优化架构，或优化SQL查询，避免联表查询，尽量不要用count(*)， in，递归等消耗性能的语句
5 用内存缓存，或在前端读的时候，增加缓存数据库。重复读取时，直接从缓存中读取。
上面是低成本的管理方法，基本几台服务器即可搞定，但是管理起来麻烦一些。
当然，如果整体数据量特别大的话，也不在乎投入费用的话，用集群吧，用TIDB吧
前端工作量大还是后台工作量大？
鄙人作为一个曾经做了四年后端，一年半伪前端的工程师，来说句客观的话。首先，我想说论技术栈复杂度来说，前后端都不浅，那些只懂后端的觉得前端就是一个兼容性的，还有只懂前端，觉得后端就是crud的，都是高估自己，低谷别人的人。一个人精力是有限的，每个技术路线可以深入的内容又非常的多，一个程序员，其实大部分时间解决的，都是如何实现某种业务，如何优化重构古老的工程，特别是大厂里，螺丝钉不要高估自己的作用。
所以当我们讨论谁的工作多的时候，按照大概率的情况，基本没区别。而你非得讨论那些只有少数人，少数情况才需要面临的问题，比如前端的跨端开发方案，如何磨平各端差异，如何克服动画性能各端瓶颈，以及后端面临的高并发，高可用性，数据库分库分表方案，缓存方案，安全策略，通信方案等等。面临这些攻坚问题的人，都是那些少部分人解决的。市场上大部分人，要么是螺丝钉，要么是拿来主义，真的，谁也别瞧不起谁，大家都是打工人，工作内容没太大差别！
数据库水平分库和垂直分库有什么区别？
常见的分库方式有水平性和垂直性。一般来说，就是按照用户属性（地市或者ID的hash）进行分库，或者按照业务功能块进行分库。水平分库方式主要根据用户属性（如地市）拆分物理数据库。一种常见的方式是将全省划分为个大区。垂直分库方式：根据业务维度和数据的访问量等，进行数据的分离，剥离为多个数据库。例如，将一些公用的配置信息存储到一个数据库中进行单独维护。
当数据库扼住系统性能咽喉，直接分库分表能解决吗？
分库分表是比较靠后的优化手段，因为成本比较高。
遇到数据库瓶颈:
- 首先考虑sql优化，这是最简单的方法。对现有系统基本没有影响。
- 其次就是考虑数据库的读写分离，这也是相对简单的方法。在数据库层面进行配置，系统层面只需要调整一下获取数据库连接的逻辑。读数据时即可以获取主库连接，也可以获取从库连接。写数据时只获取主库连接。
- 再考虑增加缓存层。将数据缓存到缓存中，当再次访问时不再从数据库获取。一般缓存层对系统是透明的，基本对系统本身没有影响。但是引入缓存，也引入了相应的需要考虑的问题，比如雪崩，命中率，分布式缓存等
- 还有一种非技术手段，就是改需求。引起性能问题的原因是否是需求不合理？或者需求太复杂？是否可以简化需求？此方法对系统的影响也相对较小。
- 最后才考虑分库分表。优先分库，因为相对分表更简单。将对应的表移动到新库，调整系统获取数据库连接的逻辑。这里需要考虑要移动哪些表，在提高性能的前提下，首先尽量避免分布式事务。
- 最最后，考虑分表。分表的主要原因是单表数据量太大。分表又分纵切和横切。纵切就是按列切，比如用户表，常用信息为基本信息表，其它信息为详情表。横切就是按行切，比如一亿数据量的表切分为十张一千万的表。这里就涉及数据该存放到哪张表，或从哪张表里取。分表后又可以分库，来进一步优化。
- 如果涉及到分布式事务，又要考虑如何保证分布式事务。理论方面2pc，3pc，paxos，cap，base。对应的中间件的使用。
对系统的设计和优化不是人云亦云，需要根据实际的场景来进行处理。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
