各位老铁们好，相信很多人对Facebook用户量十分庞大，为什么还使用MySQL数据库都不是特别的了解，因此呢，今天就来为大家分享下关于Facebook用户量十分庞大，为什么还使用MySQL数据库以及为什么不建议使用mysql的缓存的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！
本文目录
Redis缓存是针对于业务数据缓存还是对数据库数据缓存
不应该问Redis缓存的是业务数据还是数据库数据，可以问Redis是属于业务层还是数据层，这样问比较合理。
我觉得Redis属于数据层；首先我们先看一个概念。
DAOdataaccessobject：数据访问对象
主要用来封装对数据的访问，注意，是对数据的访问，不是对数据库的访问。
其实你的数据可以在数据库，在文件中，还是在Redis中，都可以通过DAO层访问。
所以我把Redis看成和数据库是同一个级别的。
Mybatis的二级缓存我们使用Redis的时候，很多时候都是通过代码操作Redis，比如使用用Jedis，其实还有一个简单的办法，就是使用Redis做Mybatis的二级缓存，只需要做简单的配置和极少量的代码即可。
我们之前做的一个项目，会有大量的数据需要频繁被查询，很少（几乎没有）做新增修改删除的操作，这种数据很适合使用Redis进行缓存，所以新的版本想把Redis引入进来。
引入所需要的jar包：
增加配置文件
实现org.apache.ibatis.cache.Cache接口
mybatis-config.xml开启二级缓存：<settingname="cacheEnabled"value="true"/>
mybatis的Mapper配置文件中增加配置：
<cachetype="com.xxx.xxx.cache.RedisCache"/>
其中useCache="false"表示，这个查询SQL不进行缓存；useCache="true"，这个查询SQL的结果进行缓存。
其余的insert、update、delete操作，可以进行如下配置：flushCache="true/false"，当设置成true的时候，执行sql会把redis中的缓存删除（调用Cache实现类的clear()方法），设置成false，则不做操作。
所以到这里也可以清楚的理解何时进行缓存、何时进行删除缓存了：程序刚启动的时候，Redis中是空的。每次执行select的时候，首先会去redis读取，读取不到的话，再去db中查询，查询结束后，将结果存入redis中（key里面包含了SQL语句），注意，如果sql查询无结果，也会放入redis中。执行insert、update、delete语句的时候，清除对应的redis中的值。
整理的功能实现还是很简单的，大家有兴趣可以尝试一下。
如果大家需要demo的源码，后续我整理一下发出来，有需要的朋友可以关注下我。
Mysql某个表有近千万数据，CRUD比较慢，该如何优化呢
我是【会点代码的大叔】，每天为你分享程序员干货，关注并私信我数字“1”，送你一份程序员大礼包。
MySQL数据库某张表近千万的数据，CRUD比较慢，如何优化？
说实话，这个数据量级，MySQL单库单表支撑起来完全没有问题的，所以首先还是考虑数据库本身的优化。
从上图可以看到，数据库优化通常可以通过以上几点来实现：
硬件升级：也就是花更多的钱，升级我们数据库硬件配置，包括CPU、内存、磁盘、网络等等，但是这个方案成本高，而且不一定能起到非常好的效果。数据库配置：修改数据库的配置，有可能让我们的CRUD操作变得更快，不过我也不建议大家把经历放在这一点上面；首先，数据库的配置通常由专业的DBA来负责；第二，大部分时候，默认的数据库配置在大多数情况下已经是最优配置了。对于开发人员来说，我们需要把注意力放在后面三点：
数据结构的优化，也就是表结构的优化数据类型的选择：选用合适的数据结构。什么叫做"合适的数据结构"，比如性别字段，M表示男F表示女，那么一个char(1)就足够了，如果存储人的年龄，那么就没有必要使用INT这么大范围的字段了；适当的拆分：千万不要试图把所有的字段放在一张表中，因为这会非常影响性能，通常一张表的字段最好不要超过30个；适当的冗余：如果一些常用的字段，可能会用在不同的维度，那么我们可以把这些字段设计在多张表中，因为这样可能会减少表关联；字段尽量设置成notNull，尽量带有默认值。SQL语句的优化优化SQL语句执行速度的方法有很多，比如：
尽量使用索引，尽量避免全表扫描，提高查询速度；当然你不能无限制地建立索引；维护索引也会影响性能，会降低DML操作的速度；注意SQL语句的书写，有一些错误的写法可能会导致索引失效；尽量避免在where子句中对字段进行Null值判断（当然我们在表设计中，直接建议不要有Null）；条件值多的情况下，尽量不要使用in和notin；select的时候，使用具体的字段代替*号避免返回大量数据，增加分页；减少数据库的访问我们可以通过增加本地缓存或分布式缓存的方式，将热点数据存储到缓存中，以减少数据库的访问；终极大招，如果是一个不合理的需求，我们可以拒绝做这个需求，这样也算是"减少了数据库访问"。说完了MySQL本身的优化，如果数据量进一步增大的话，我们还有什么优化的方案呢？
读写分离主库用于写，从库用于读，将读写分散在不同的数据库上，利用多台机器的资源，来提高数据库的可用性和性能。
分库分表如果数据持续增多，超过了单台MySQL的支撑上限，那么只能用【分库分表】这一招了；我们可以采用一定的路由规则，将数据保存到不同的数据库中。
当然，如果不是“迫不得已”，我是不太建议分库分表的，因为这样极大地增加了系统的复杂程度，并且会带来更多的问题需要开发人员解决。
以上就是常用的MySQL优化方案，如果是千万级数据量，优化MySQL本身即可。
会点代码的大叔|原创一个写代码的架构师，专注程序员的学习和成长，关注并私信我数字“1”，送你一份程序员大礼包。学习MySQL的前景怎么样
首先就像以上大家说的那样没有单学MySQL这个说法，我这里理解为你是想从事数据库相关的工作，也就是DBA。通常情况下DBA的知识体系分为:关系型数据库（MySQL，SqlServer，Oracle），非关系型数据库（MongoDB），各类数据库缓存（redis，memcached）。这几种是目前比较常见的，所以基本上都得会，某些还得精通。另外还有个问题，就是国内通常是把DBA和运维绑定的，也就是说一般是由运维配合开发人员来做数据库的日常维护，所以Linux系统以及各类网络协议都得会点。前景的话一句话概括就是工资客观，平时没啥事，有事了都是大半夜接电话紧急修bug的。。。并且因为比较偏向底层所以技术迭代周期会比较长，不用担心失业之类啥的。
Facebook用户量十分庞大，为什么还使用MySQL数据库
尽管Facebook使用MySQL，但它们并不是一成不变的使用它。事实上，他们的团队已经提交了许多MySQL核心和Innodb插件的高性能增强。他们的主要重点是增加性能计数器到Innodb。其他更改集中在IO子系统上，包括以下新功能：
1innodb_io_capacity：设置服务器的IO容量以确定后台IO的速率限制
2innodb_read_io_threads,innodb_write_io_threads：设置后台IO线程
3innodb_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或者MSSQLServer一样好或者更好，因为就算只有Facebook使用它，它也有5亿用户！”
关于Facebook用户量十分庞大，为什么还使用MySQL数据库的内容到此结束，希望对大家有所帮助。
