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个全职DBAFacebook主要将MySQL用于结构化数据存储，例如墙贴，用户信息等。
这些数据在各个数据中心之间复制。 对于blob存储（照片，视频等），Facebook使用一个自定义的解决方案，涉及外部的CDN和内部的NFS同样重要的是，Facebook大量使用Memcache，这是一种内存缓存系统，通过在RAM中缓存数据和对象来加速动态数据库驱动的网站，以减少阅读时间。 Memcache是Facebook的主要缓存形式，大大减少了数据库的负载。
拥有一个缓存系统可以使Facebook的速度与调用数据一样快。 如果不需要访问数据库，则只需根据用户标识从缓存中获取数据所以，“Facebook使用什么数据库”似乎是一个简单的问题，你可以看到他们已经添加了各种其他系统，使其真正的具有网络可扩展性。 但是，仍然可以自由地使用这样一个观点：“MySQL和Oracle或者MS SQL Server一样好或者更好，因为就算只有Facebook使用它，它也有5亿用户！”。
mysql表数据量太大，达到了1亿多条数据，除了分库分表之外，还有没有其他的解决方式？
mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：1 分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法2 读写分离。尤其是写入，放在新表中，定期进行同步。
如果其中记录不断有update，最好将写的数据放在 redis中，定期同步3 表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库4 优化架构，或优化SQL查询，避免联表查询，尽量不要用count(*), in，递归等消耗性能的语句5 用内存缓存，或在前端读的时候，增加缓存数据库。
