数据库集群 mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：
1 分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法
2 读写分离。尤其是写入，放在新表中，定期进行同步。如果其中记录不断有update，最好将写的数据放在 redis中，定期同步
3 表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库
4 优化架构，或优化SQL查询，避免联表查询，尽量不要用count(*)， in，递归等消耗性能的语句
5 用内存缓存，或在前端读的时候，增加缓存数据库。重复读取时，直接从缓存中读取。
上面是低成本的管理方法，基本几台服务器即可搞定，但是管理起来麻烦一些。
当然，如果整体数据量特别大的话，也不在乎投入费用的话，用集群吧，用TIDB吧
Facebook用户量十分庞大，为什么还使用MySQL数据库？
尽管Facebook使用MySQL，但它们并不是一成不变的使用它。 事实上，他们的团队已经提交了许多MySQL核心和Innodb插件的高性能增强。 他们的主要重点是增加性能计数器到Innodb。 其他更改集中在IO子系统上，包括以下新功能：
1 innodb_io_capacity：设置服务器的IO容量以确定后台IO的速率限制
2 innodb_read_io_threads， innodb_write_io_threads：设置后台IO线程
3 innodb_max_merged_io：设置可能合并到一个大IO请求中的相邻IO请求的最大数量
Facebook使用MySQL作为键值存储，其中数据随机分布在一大组逻辑实例中。 这些逻辑实例分散在物理节点之间，负载均衡在物理节点级完成。 Facebook已经开发了一个分区方案，其中全局ID被分配给所有的用户数据。 他们也有一个自定义的归档方案，它基于每个用户的频繁和最近的数据。 大部分数据是随机分布的。 令人惊讶的是，据传Facebook有1800个MySQL服务器，但只有3个全职DBA
Facebook主要将MySQL用于结构化数据存储，例如墙贴，用户信息等。这些数据在各个数据中心之间复制。 对于blob存储（照片，视频等），Facebook使用一个自定义的解决方案，涉及外部的CDN和内部的NFS
同样重要的是，Facebook大量使用Memcache，这是一种内存缓存系统，通过在RAM中缓存数据和对象来加速动态数据库驱动的网站，以减少阅读时间。 Memcache是Facebook的主要缓存形式，大大减少了数据库的负载。 拥有一个缓存系统可以使Facebook的速度与调用数据一样快。 如果不需要访问数据库，则只需根据用户标识从缓存中获取数据
所以，“Facebook使用什么数据库”似乎是一个简单的问题，你可以看到他们已经添加了各种其他系统，使其真正的具有网络可扩展性。 但是，仍然可以自由地使用这样一个观点：“MySQL和Oracle或者MS SQL Server一样好或者更好，因为就算只有Facebook使用它，它也有5亿用户！”
配置mysql集群需要mysql哪个版本？
集群中，可能存在mysql主从复制。但主从主要是做读写分离的。另外主从出现故障可能性比较大。mysql集群很复杂，当然小集群比较简单，集群主要是实现高可用和高负载，主从只是集群可能用到的一个mysql功能了。比如 主从 读写分离 keepalived自动故障切换但mysql瓶颈在于写，也就是。复杂的集群有的按照索引分开写入，有的多主……
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
