189 8069 5689
Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较：
创新互联主营高邮网站建设的网络公司,主营网站建设方案,成都app开发,高邮h5小程序制作搭建,高邮网站营销推广欢迎高邮等地区企业咨询
1、Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。
2、内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。
3、性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。
具体为什么会出现上面的结论，以下为收集到的资料：
1、数据类型支持不同
与Memcached仅支持简单的key-value结构的数据记录不同，Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set。Redis内部使用一个redisObject对象来表示所有的key和value。redisObject最主要的信息如图所示：
type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int，如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:”123″ “456”这样的字符串。只有打开了Redis的虚拟内存功能，vm字段字段才会真正的分配内存，该功能默认是关闭状态的。
1）String
常用命令：set/get/decr/incr/mget等；
应用场景：String是最常用的一种数据类型，普通的key/value存储都可以归为此类；
实现方式：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
2）Hash
常用命令：hget/hset/hgetall等
应用场景：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；
实现方式：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如图所示，Key是用户ID, value是一个Map。这个Map的key是成员的属性名，value是属性值。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。当前HashMap的实现有两种方式：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
请点击输入图片描述
3）List
常用命令：lpush/rpush/lpop/rpop/lrange等；
应用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；
实现方式：Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
4）Set
常用命令：sadd/spop/smembers/sunion等；
应用场景：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的；
实现方式：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
5）Sorted Set
常用命令：zadd/zrange/zrem/zcard等；
应用场景：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
2、内存管理机制不同
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。Redis只会缓存所有的key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个操作，直到子线程完成swap操作后才可以进行修改。当从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
对于像Redis和Memcached这种基于内存的数据库系统来说，内存管理的效率高低是影响系统性能的关键因素。传统C语言中的malloc/free函数是最常用的分配和释放内存的方法，但是这种方法存在着很大的缺陷：首先，对于开发人员来说不匹配的malloc和free容易造成内存泄露；其次频繁调用会造成大量内存碎片无法回收重新利用，降低内存利用率；最后作为系统调用，其系统开销远远大于一般函数调用。所以，为了提高内存的管理效率，高效的内存管理方案都不会直接使用malloc/free调用。Redis和Memcached均使用了自身设计的内存管理机制，但是实现方法存在很大的差异，下面将会对两者的内存管理机制分别进行介绍。
Memcached默认使用Slab Allocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以完全解决内存碎片问题。Slab Allocation机制只为存储外部数据而设计，也就是说所有的key-value数据都存储在Slab Allocation系统里，而Memcached的其它内存请求则通过普通的malloc/free来申请，因为这些请求的数量和频率决定了它们不会对整个系统的性能造成影响Slab Allocation的原理相当简单。 如图所示，它首先从操作系统申请一大块内存，并将其分割成各种尺寸的块Chunk，并把尺寸相同的块分成组Slab Class。其中，Chunk就是用来存储key-value数据的最小单位。每个Slab Class的大小，可以在Memcached启动的时候通过制定Growth Factor来控制。假定图中Growth Factor的取值为1.25，如果第一组Chunk的大小为88个字节，第二组Chunk的大小就为112个字节，依此类推。
请点击输入图片描述
当Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class，然后通过查询Memcached保存着的该Slab Class内空闲Chunk的列表就可以找到一个可用于存储数据的Chunk。当一条数据库过期或者丢弃时，该记录所占用的Chunk就可以回收，重新添加到空闲列表中。从以上过程我们可以看出Memcached的内存管理制效率高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。因为每个Chunk都分配了特定长度的内存空间，所以变长数据无法充分利用这些空间。如图 所示，将100个字节的数据缓存到128个字节的Chunk中，剩余的28个字节就浪费掉了。
请点击输入图片描述
Redis的内存管理主要通过源码中zmalloc.h和zmalloc.c两个文件来实现的。Redis为了方便内存的管理，在分配一块内存之后，会将这块内存的大小存入内存块的头部。如图所示，real_ptr是redis调用malloc后返回的指针。redis将内存块的大小size存入头部，size所占据的内存大小是已知的，为size_t类型的长度，然后返回ret_ptr。当需要释放内存的时候，ret_ptr被传给内存管理程序。通过ret_ptr，程序可以很容易的算出real_ptr的值，然后将real_ptr传给free释放内存。
请点击输入图片描述
Redis通过定义一个数组来记录所有的内存分配情况，这个数组的长度为ZMALLOC_MAX_ALLOC_STAT。数组的每一个元素代表当前程序所分配的内存块的个数，且内存块的大小为该元素的下标。在源码中，这个数组为zmalloc_allocations。zmalloc_allocations[16]代表已经分配的长度为16bytes的内存块的个数。zmalloc.c中有一个静态变量used_memory用来记录当前分配的内存总大小。所以，总的来看，Redis采用的是包装的mallc/free，相较于Memcached的内存管理方法来说，要简单很多。
3、数据持久化支持
Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。而memcached是不支持数据持久化操作的。
1）RDB快照
Redis支持将当前数据的快照存成一个数据文件的持久化机制，即RDB快照。但是一个持续写入的数据库如何生成快照呢？Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。我们可以通过Redis的save指令来配置RDB快照生成的时机，比如配置10分钟就生成快照，也可以配置有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中，你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。
Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的。
2）AOF日志
AOF日志的全称是append only file，它是一个追加写入的日志文件。与一般数据库的binlog不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。只有那些会导致数据发生修改的命令才会追加到AOF文件。每一条修改数据的命令都生成一条日志，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的AOF文件取代老的AOF文件。
AOF是一个写文件操作，其目的是将操作日志写到磁盘上，所以它也同样会遇到我们上面说的写操作的流程。在Redis中对AOF调用write写入后，通过appendfsync选项来控制调用fsync将其写到磁盘上的时间，下面appendfsync的三个设置项，安全强度逐渐变强。
appendfsync no 当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
appendfsync everysec 当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。所以结论就是，在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。
appednfsync always 当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。
对于一般性的业务需求，建议使用RDB的方式进行持久化，原因是RDB的开销并相比AOF日志要低很多，对于那些无法忍数据丢失的应用，建议使用AOF日志。
4、集群管理的不同
Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说，机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小，就需要构建分布式集群来扩展存储能力。
Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。下图给出了Memcached的分布式存储实现架构。当客户端向Memcached集群发送数据之前，首先会通过内置的分布式算法计算出该条数据的目标节点，然后数据会直接发送到该节点上存储。但客户端查询数据时，同样要计算出查询数据所在的节点，然后直接向该节点发送查询请求以获取数据。
请点击输入图片描述
相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。最新版本的Redis已经支持了分布式存储功能。Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本，它没有中心节点，具有线性可伸缩的功能。下图给出Redis Cluster的分布式存储架构，其中节点与节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。在数据的放置策略上，Redis Cluster将整个key的数值域分成4096个哈希槽，每个节点上可以存储一个或多个哈希槽，也就是说当前Redis Cluster支持的最大节点数就是4096。Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER。
请点击输入图片描述
为了保证单点故障下的数据可用性，Redis Cluster引入了Master节点和Slave节点。在Redis Cluster中，每个Master节点都会有对应的两个用于冗余的Slave节点。这样在整个集群中，任意两个节点的宕机都不会导致数据的不可用。当Master节点退出后，集群会自动选择一个Slave节点成为新的Master节点。
请点击输入图片描述
Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较：
1、Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。
2、内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。
3、性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。
具体为什么会出现上面的结论，以下为收集到的资料：
1、数据类型支持不同
与Memcached仅支持简单的key-value结构的数据记录不同，Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set。Redis内部使用一个redisObject对象来表示所有的key和value。redisObject最主要的信息如图所示：
type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int，如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:”123″ “456”这样的字符串。只有打开了Redis的虚拟内存功能，vm字段字段才会真正的分配内存，该功能默认是关闭状态的。
1）String
常用命令：set/get/decr/incr/mget等；
应用场景：String是最常用的一种数据类型，普通的key/value存储都可以归为此类；
实现方式：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
2）Hash
常用命令：hget/hset/hgetall等
应用场景：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；
实现方式：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如图所示，Key是用户ID, value是一个Map。这个Map的key是成员的属性名，value是属性值。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。当前HashMap的实现有两种方式：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
3）List
常用命令：lpush/rpush/lpop/rpop/lrange等；
应用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；
实现方式：Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
4）Set
常用命令：sadd/spop/smembers/sunion等；
应用场景：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的；
实现方式：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
5）Sorted Set
常用命令：zadd/zrange/zrem/zcard等；
应用场景：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
2、内存管理机制不同
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。Redis只会缓存所有的key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个操作，直到子线程完成swap操作后才可以进行修改。当从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
对于像Redis和Memcached这种基于内存的数据库系统来说，内存管理的效率高低是影响系统性能的关键因素。传统C语言中的malloc/free函数是最常用的分配和释放内存的方法，但是这种方法存在着很大的缺陷：首先，对于开发人员来说不匹配的malloc和free容易造成内存泄露；其次频繁调用会造成大量内存碎片无法回收重新利用，降低内存利用率；最后作为系统调用，其系统开销远远大于一般函数调用。所以，为了提高内存的管理效率，高效的内存管理方案都不会直接使用malloc/free调用。Redis和Memcached均使用了自身设计的内存管理机制，但是实现方法存在很大的差异，下面将会对两者的内存管理机制分别进行介绍。
Memcached默认使用Slab Allocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以完全解决内存碎片问题。Slab Allocation机制只为存储外部数据而设计，也就是说所有的key-value数据都存储在Slab Allocation系统里，而Memcached的其它内存请求则通过普通的malloc/free来申请，因为这些请求的数量和频率决定了它们不会对整个系统的性能造成影响Slab Allocation的原理相当简单。 如图所示，它首先从操作系统申请一大块内存，并将其分割成各种尺寸的块Chunk，并把尺寸相同的块分成组Slab Class。其中，Chunk就是用来存储key-value数据的最小单位。每个Slab Class的大小，可以在Memcached启动的时候通过制定Growth Factor来控制。假定图中Growth Factor的取值为1.25，如果第一组Chunk的大小为88个字节，第二组Chunk的大小就为112个字节，依此类推。
当Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class，然后通过查询Memcached保存着的该Slab Class内空闲Chunk的列表就可以找到一个可用于存储数据的Chunk。当一条数据库过期或者丢弃时，该记录所占用的Chunk就可以回收，重新添加到空闲列表中。从以上过程我们可以看出Memcached的内存管理制效率高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。因为每个Chunk都分配了特定长度的内存空间，所以变长数据无法充分利用这些空间。如图 所示，将100个字节的数据缓存到128个字节的Chunk中，剩余的28个字节就浪费掉了。
Redis的内存管理主要通过源码中zmalloc.h和zmalloc.c两个文件来实现的。Redis为了方便内存的管理，在分配一块内存之后，会将这块内存的大小存入内存块的头部。如图所示，real_ptr是redis调用malloc后返回的指针。redis将内存块的大小size存入头部，size所占据的内存大小是已知的，为size_t类型的长度，然后返回ret_ptr。当需要释放内存的时候，ret_ptr被传给内存管理程序。通过ret_ptr，程序可以很容易的算出real_ptr的值，然后将real_ptr传给free释放内存。
Redis通过定义一个数组来记录所有的内存分配情况，这个数组的长度为ZMALLOC_MAX_ALLOC_STAT。数组的每一个元素代表当前程序所分配的内存块的个数，且内存块的大小为该元素的下标。在源码中，这个数组为zmalloc_allocations。zmalloc_allocations[16]代表已经分配的长度为16bytes的内存块的个数。zmalloc.c中有一个静态变量used_memory用来记录当前分配的内存总大小。所以，总的来看，Redis采用的是包装的mallc/free，相较于Memcached的内存管理方法来说，要简单很多。
3、数据持久化支持
Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。而memcached是不支持数据持久化操作的。
1）RDB快照
Redis支持将当前数据的快照存成一个数据文件的持久化机制，即RDB快照。但是一个持续写入的数据库如何生成快照呢？Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。我们可以通过Redis的save指令来配置RDB快照生成的时机，比如配置10分钟就生成快照，也可以配置有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中，你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。
Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的。
2）AOF日志
AOF日志的全称是append only file，它是一个追加写入的日志文件。与一般数据库的binlog不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。只有那些会导致数据发生修改的命令才会追加到AOF文件。每一条修改数据的命令都生成一条日志，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的AOF文件取代老的AOF文件。
AOF是一个写文件操作，其目的是将操作日志写到磁盘上，所以它也同样会遇到我们上面说的写操作的流程。在Redis中对AOF调用write写入后，通过appendfsync选项来控制调用fsync将其写到磁盘上的时间，下面appendfsync的三个设置项，安全强度逐渐变强。
appendfsync no 当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
appendfsync everysec 当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。所以结论就是，在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。
appednfsync always 当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。
对于一般性的业务需求，建议使用RDB的方式进行持久化，原因是RDB的开销并相比AOF日志要低很多，对于那些无法忍数据丢失的应用，建议使用AOF日志。
4、集群管理的不同
Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说，机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小，就需要构建分布式集群来扩展存储能力。
Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。下图给出了Memcached的分布式存储实现架构。当客户端向Memcached集群发送数据之前，首先会通过内置的分布式算法计算出该条数据的目标节点，然后数据会直接发送到该节点上存储。但客户端查询数据时，同样要计算出查询数据所在的节点，然后直接向该节点发送查询请求以获取数据。
相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。最新版本的Redis已经支持了分布式存储功能。Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本，它没有中心节点，具有线性可伸缩的功能。下图给出Redis Cluster的分布式存储架构，其中节点与节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。在数据的放置策略上，Redis Cluster将整个key的数值域分成4096个哈希槽，每个节点上可以存储一个或多个哈希槽，也就是说当前Redis Cluster支持的最大节点数就是4096。Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER。
为了保证单点故障下的数据可用性，Redis Cluster引入了Master节点和Slave节点。在Redis Cluster中，每个Master节点都会有对应的两个用于冗余的Slave节点。这样在整个集群中，任意两个节点的宕机都不会导致数据的不可用。当Master节点退出后，集群会自动选择一个Slave节点成为新的Master节点。
一、Redis集群介绍
Redis真的是一个优秀的技术，它是一种key-value形式的NoSQL内存数据库，由ANSI C编写，遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。 Redis最大的特性是它会将所有数据都放在内存中，所以读写速度性能非常好。Redis是基于内存进行操作的，性能较高，可以很好的在一定程度上解决网站一瞬间的并发量，例如商品抢购秒杀等活动。
网站承受高并发访问压力的同时，还需要从海量数据中查询出满足条件的数据，需要快速响应，前端发送请求、后端和mysql数据库交互，进行sql查询操作，读写比较慢，这时候引入Redis ,把从mysql 的数据缓存到Redis 中，下次读取时候性能就会提高；当然，它也支持将内存中的数据以快照和日志的形式持久化到硬盘，这样即使在断电、机器故障等异常情况发生时数据也不会丢失，Redis能从硬盘中恢复快照数据到内存中。
Redis 发布了稳定版本的 5.0 版本，放弃 Ruby的集群方式，改用 C语言编写的 redis-cli的方式，是集群的构建方式复杂度大大降低。Redis-Cluster集群采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。
为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。
redis-cluster投票:容错，投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉。
集群中至少应该有奇数个节点，所以至少有三个节点，每个节点至少有一个备份节点，所以下面使用6节点（主节点、备份节点由redis-cluster集群确定）。6个节点分布在一台机器上，采用三主三从的模式。实际应用中，最好用多台机器，比如说6个节点分布到3台机器上，redis在建立集群时为自动的将主从节点进行不同机器的分配。
二、单机redis模式
下载源码redis5.0并解压编译
wget
tar xzf redis-5.0.0.tar.gz
cd redis-5.0.0
make
redis前端启动需要改成后台启动.
修改redis.conf文件,将daemonize no - daemonize yes
vim redis.conf
启动redis
/www/server/redis/src/redis-server /www/server/redis/redis.conf
查看redis是否在运行
ps aux|grep redis
现在是单机redis模式完成。
三、redis集群模式：
1.创建6个Redis配置文件
cd /usr/local/
mkdir redis_cluster //创建集群目录
cd redis_cluster
mkdir 7000 7001 7002 7003 7004 7005//分别代表6个节点
其对应端口 7000 7001 7002 70037004 7005
2.复制配置文件到各个目录
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7000/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7001/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7002/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7003/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7004/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7005/
3.分别修改配置文件
vim /usr/local/redis_cluster/7000/redis.conf
vim /usr/local/redis_cluster/7001/redis.conf
vim /usr/local/redis_cluster/7002/redis.conf
vim /usr/local/redis_cluster/7003/redis.conf
vim /usr/local/redis_cluster/7004/redis.conf
vim /usr/local/redis_cluster/7005/redis.conf
如下
port 7000 #端口
cluster-enabled yes #启用集群模式
cluster-config-file nodes_7000.conf ＃集群的配置 配置文件首次启动自动生成
cluster-node-timeout 5000 #超时时间 5秒
appendonly yes ＃aof日志开启 它会每次写操作都记录一条日志
daemonize yes #后台运行
protected-mode no #非保护模式
pidfile /var/run/redis_7000.pid
//下面可以不写
#若设置密码，master和slave需同时配置下面两个参数：
masterauth "jijiji" #连接master的密码
requirepass "jijiji" #自己的密码
cluster-config-file，port，pidfile对应数字
4.启动节点
cd /www/server/redis/src/
./redis-server /usr/local/redis_cluster/7000/redis.conf
./redis-server /usr/local/redis_cluster/7001/redis.conf
./redis-server /usr/local/redis_cluster/7002/redis.conf
./redis-server /usr/local/redis_cluster/7003/redis.conf
./redis-server /usr/local/redis_cluster/7004/redis.conf
./redis-server /usr/local/redis_cluster/7005/redis.conf
查看redis运行
ps aux|grep redis
5.启动集群
/www/server/redis/src/redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
这里使用的命令是create，因为我们要创建一个新的集群。 该选项--cluster-replicas 1意味着我们希望每个创建的主服务器都有一个从服。
输入yes
至此，Reids5 集群搭建完成。
6.检查Reids5集群状态
可以执行redis-cli --cluster check host:port检查集群状态slots详细分配。
redis-cli --cluster info 127.0.0.1:7000
7.停止Reids5集群
（1）.因为Redis可以妥善处理SIGTERM信号，所以直接kill -9也是可以的，可以同时kill多个,然后再依次启动。
kill -9 PID PID PID
（2）.redis5 提供了关闭集群的工具，修改文件： /www/server/redis/utils/create-cluster/create-cluster
端口PROT设置为6999，NODES为6，工具会生成 7000-7005 六个节点 用于操作。
修改后，执行如下命令关闭集群：
/www/server/redis/utils/create-cluster/create-cluster stop
重新启动集群：
/www/server/redis/utils/create-cluster/create-cluster start
8.帮助信息
执行redis-cli --cluster help,查看更多帮助信息
redis-cli --cluster help
吉海波
mysql5.6新特性 icp
一，安全提高
1.提供保存加密认证信息的方法，使用.mylogin.cnf文件。使用mysql_config_editor可以创建此文件。这个文件可以进行连接数据库的访问授权。mysql_config_editor会进行加密而不是明文存储。客户端只会在内存中进行解密。这样密码以非明文方式存储，不会在命令行或者环境变量中暴露。更多信息，访问 Section 4.6.6, “mysql_config_editor — MySQL Configuration Utility”.
2.使用sha256_password，支持更为强大的用户密码加密方式。这个插件是内置的。更多信息访问 Section 6.3.6.2, “The SHA-256 Authentication Plugin
3.mysql.user表现在增加password_expired列，默认值是’N'，使用新的ALTER USER命令可以设置为’Y'。当密码过期后，使用此账号的后续连接都会报错，只到用户使用SET PASSWORD命令创建一个新密码。更多信息访问Section 13.7.1.1, “ALTER USERSyntax”
4.现在提供密码安全策略
使用明文指定密码时，密码会被当前的密码策略检查，如果太弱会被拒绝（返回ER_NOT_VALID_PASSWORD 错误）。会影响 CREATE USER, GRANT, 和 SET PASSWORD命令。密码作为参数被password()，old_password()引用时也会被检查。
密码的强状程度可以被新函数VALIDATE_PASSWORD_STRENGTH() 检查。此函数把密码做为参数，返回0(弱)-100（强）。
以上都是validate_password插件提供，更多信息见 Section 6.1.2.6, “The Password Validation Plugin”.
mysql_upgrade如果发现使用4.1以前的哈希密码会警告。这样的账号必须升级到更安全的哈希密码。见Section 6.1.2.4, “Password Hashing in MySQL”
5.登录记录被更改，所以密码不会再被明文记载在general log，bin log,slow log。见Section 6.1.2.3, “Passwords and Logging”
6.start slave语句被修改，可以指定参数。密码可以存放在master.info 文件。见Section 13.4.2.5, “START SLAVE Syntax”◦
二，默认值更改
7. 从5.6.6开始，默认值与以前不同，动机是提供更好的性能，避免手工更改。见 Section 5.1.2.1, “Changes to Server Defaults”.
三，Innodb加强
8. 可以在Innodb 表上建全文索引，使用 MATCH() … AGAINST语句。这个特性包括一个新的近似搜索符号 @，和几种新的配置项以及INFORMATION_SCHEMA表。见Section 14.2.4.12.3, “FULLTEXT Indexes”◦
9. 几种ALTER TABLE操作不再拷备表，不会阻塞insert,update,delete或者全部写入操作。这就是所谓的online DDL.见Section 14.2.2.6, “Online DDL for InnoDB Tables”
10.单独表空间下，对于.ibd files你有更多的自主性。 file-per-table模式创建表时可以指定MySQL数据目录以外的目录。比如，把压力大的表放到SSD设备上，或者把一个大表放到一个大HDD上。你可以把一个表从一个实例导出，然后导入另一个实例，不会引起因为缓存数据，进行中的事务以及内部因素如 space ID以及LSN引起的数据不一致。见：Section 14.2.5.2.33, “Tablespace Management”
11.你可以设置Innodb的未压缩表的page size 为8KB或者4KB，或者默认的16KB。使用参数innodb_page_size来配置。创建实例的时候指定此参数。同一实例Innodb tablespaces共享此页面大小。更小的页面大小对某种混合压力负载可以避免冗余或者低效的IO，尤其是针对块大小小的SSD 设备。
blackjack, roulette, slots, slots, blackjack,roulette, casino, blackjack, blackjack, blackjack,slots
12.改进的 adaptive flushing 算法使得多种workloads下I/O操作更有效率和一致性。新算法和默认配置期待可以提高多数用户的性能和并发。见Section 14.2.5.2.8, “Improvements to Buffer Pool Flushing”
13.你可以通过NoSQL API开发应用访问InnnoDB表。它使用流行的memcached守护进程来响应对于key-value对的Add,Set和GET请求。这样避免了解析和构建query execution plan的成本。你可以使用NoSQL API或者SQL来访问同一份数据。比如：你可以通过NoSQL API快速访问和查询表数据，使用SQL来进行复杂查询以及兼容已有的应用。更多见Section 14.2.10, “InnoDB Integration with memcached” 。
14.Innodb的优化器统计会以更确定的间隔收集，同时服务器重启后还能保持，使得plan stability更稳定。你还可以控制InnoDB索引的样本数量，使得优化器的统计更准确，以提主查询执行计划。更多见 Section 14.2.5.2.9, “Persistent Optimizer Statistics for InnoDB Tables”
15.优化了只读事务，提高了特定查询和报告生成应用的性能和并发。这个优化是自动的，或者你可以指定START TRANSACTION READ ONLY 参数。更多见 Section 14.2.5.2.2, “Optimizations for Read-Only Transactions”
16.可以把Innodb 的undo log移出system tablespace到一个或者多个独立的tablespaces。undo log的I/O模式使得将这些表空间移到SSD设备成为一个好选择，同时将系统表空间放在普通磁盘上。更多见：Section 14.2.5.2.3, “SeparateTablespaces for InnoDB Undo Logs”
17.Innodb redo log大小从最大4GB提高到512GB，通过参数 innodb_log_file_size 配置。
18.–innodb-read-only 选项可以让MySQL运行在只读模式。你可以通过DVD,CD等只读媒体访问Innodb 表，还可以共享数据目录来创建多个数据仓库。更多见： Section 14.2.6.1, “Support for Read-Only Media”
19.多个关于Innodb的新INFORMATION_SCHEMA表，提供了关于buffer pool，表的元数据，索引，数据字典中的外键，以及更细的性能粒度信息，补充了Performance Schema表的信息。
20.打开多个表时，Innodb限制了保持表信息的内存。
21.Innodb强化了几种内部性能，包括拆分kernel mutex来减少竞争，将刷新操作移出主线程，允许使用多个清理线程，以及减少了大内存系统中的buffer_pool竞争。
22.Innodb使用了一种新的，更快的算法来检测deadlocks. 所有死锁信息都可以被记录到错误日志。
23.为了避免大buffer_pool的实例重启服务时过长的warmup 时间，你可以在重启后立即加载缓存页面。MySQL可以在关闭时导出完全数据文件，检阅此文件找出重启时需要加载的pages。你可以在任何手工导入导出buffer_pool，比如在性能测试时或者在执行复杂的OLAP查询后。
四，分区
24.最大分区数量提高到8192，这包括所有的分区和子分区。
25.使用ALTER TABLE … EXCHANGE PARTITION 可以在未分区表和分区表和子分区表之间交换分区。这可以用来导出导入分区。更多见：Section 17.3.3, “Exchanging Partitions and Subpartitions with Tables”.
26.可以在分区表中显示查询一个或者多个分区，或者更改数据。比如，表t有int 列c，有4个分区p0-03，查询SELECT * FROM t PARTITION (p0, p1) WHERE c 5 只返回po,p1符合条件结果。
以下语句支持显式分区查询
SELECT
DELETE
INSERT
REPLACE
UPDATE
LOAD DATA
LOAD XML
译：更多见：Section 17.5, “Partition Selection”.
27.减少分区锁提高了有很多分区的表的多数DML和DDL操作，减少的是未被语句影响的分区上的锁。这样的语句包括SELECT, SELECT … PARTITION, UPDATE, REPLACE, INSERT, 以及很多其它语句。更多，包括哪些语句性能提高见Section 17.6.4, “Partitioning and Locking”.
五，Performance Schema
28.记录表的输入与输出，操作包括行级访问表和临时表，如insert,upate,delete.
29.表的事件过滤，以库或者表名为基础。
30.线程的事件过滤，更多关于线程的信息被搜集
31.表和索引I/O以及表锁的统计表。
32.记录命令以及命令的阶段。
33.服务启动的的时候配置参数，以前只能运行时设设置。
六，复制和日志
34.支持以全局统一事务ID（GTID)为基础的复制。当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务。
35.使用–gtid-mode and –enforce-gtid-consistency 参数启动复制可以开启GTIDs。更多信息见Section 16.1.4.5, “Global Transaction ID Options and Variables”.
36.如果使用了GTIDs，启动一个新的复制从库或切换到一个新的主库，就不必依赖log文件或者pos位。
37.GTID复制是全部以事务为基础，使得检查主从一致性变得非常简单。如果所有主库上提交的事务也同样提交到从库上，一致性就得到了保证。
38.更多见Section 16.1.3, “Replication with Global Transaction Identifiers”.
39.行复制现在支持行映像控制。可以只记录唯一定位列和变化列（非全部列），这样可以节省磁盘空间，网络流量和内存使用。你可以使用参数binlog_row_image ，设置为minimal(记录必要列)，full(全部列)，noblob（不包括blob或者text的所有列）来控制最小或者最大记录。更多见System variables used with the binary log,
40.binlog的读写现在是崩溃安全的，因为只有完整的事件（或者事务）才会被记录和读取。默认会记录事件的大小以及事件本身，使用大小来验证事件被正确记录。你也可以使用参数binlog_checksum 设置使用crc32记录事件的校验值。使用参数 master_verify_checksum可以让服务读取校验值。–slave-sql-verify-checksum 参数使从库读relay日志的时候读取校验值 。
41.MySQL支持在表中保存主库连接信息了。使用参数–master-info-repository 和 –relay-log-info-repository 来设置。设置 –master-info-repository 为表，会记录连接信息到slave_master_info 表。设置–relay-log-info-repository 为表，会记录relay log信息到slave_relay_log_info表。这几个表都是自动建立在mysql系统库。
重要：为了保证复制安全，lave_master_info 和 slave_relay_log_info表必须使用事务引擘比如innodb，默认是使用myisam引擘,意味着在开始复制前，你必须把这些表改为事务引擘，以保证安全。使用语句ALTER TABLE … ENGINE=… 完成。如果复制运行时，请不要更改
42.mysqlbinlog 现在支持以原始格式备份binlog，使用选项–read-from-remote-server and –raw。mysqlbinlog连接服务器，请求日志文件，以原始格式写入输出文件。参见：Section 4.6.8.3, “Usingmysqlbinlog to Back Up Binary Log Files”.
43.MySQL现在支持延迟复制，默认是0秒。使用CHANGE MASTER TO参数 MASTER_DELAY 来设置延迟。
44.延迟复制用来防护主库的用户误操作（DBA可以回滚一个延迟复制从库到误操作前）或者测试当系统有延迟时系统行为。见Section 16.3.9, “Delayed Replication”.
45.如果复制从库有多个网络接口，可以只使用CHANGE MASTER TO 命令的参数MASTER_BIND 来只使用其中一个。
46.增加系统参数log_bin_basename ，指定完整的路径和文件名，log_bin 只控制是否开启binlog.
同样适用relay_log_basename 。
47.现在支持多线程复制。如果开启，sql线程作为协调者协调多个工作线程，数量取决于slave_parallel_workers 。现在多线程复制以单库为基础，特定库的更新的相对顺序和主库一样。不过，没有必要协调不同库之间的事务。事务可以被分布到每个库，意味着一个复制从库的工作线程可以顺序执行事务而不必等待其它库的更新完成。
48.既然不同库的事务在主从库的上顺序可能不同，简单的最近执行的事务不能保证以前的事务在从库都执行了。这对于多线程复制时日志和恢复有特殊意义。对于如何在多线程复制的时候解释binlog信息，请见Section 13.7.5.35,“SHOW SLAVE STATUS Syntax”
七，优化器提升
49.查询优化器对于以下查询（子查询）更有效率SELECT … FROM single_table … ORDER BYnon_index_column[DESC] LIMIT [M,]N;
此类在大结果集中显示几行的查询在网站中很常见。如：SELECT col1, … FROM t1 … ORDER BY name LIMIT 10; SELECT col1, … FROM t1 … ORDER BY RAND() LIMIT 15;
排序缓存由 sort_buffer_size.指定。如果N行被排序的元素足够小可以被入排序缓存(M+N行如果M被指定)，可以避免使用合并文件，整个查询可以都放入内存中。见Section 8.2.1.3, “Optimizing LIMIT Queries”
50.优化器使用MRR。使用非聚集索引进行索引扫描时，如果表很大没有缓存，会导致大量的随机磁盘访问。使用MRR优化，优化器会先对扫描索引，然后收集每行的主键并对主键排序，此时就可以用主键顺序访问基表。这样就用顺序访问代替了随机磁盘访问。
51.优化器使用ICP，没有ICP，引擘使用索引定位行，并返回给服务层，使用where丢弃不符合条件记录。使用ICP后，如果索引中只有部分能被where条件利用，MySQL将where条件压到引擘层。引擘层使用索引项进行评估，只有满足条件的会被读取。ICP可以减少引擘层对基表的访问，同时减少了服务层对引擘层的访问。更多见：Section 8.13.4, “Index Condition Pushdown Optimization”
52.EXPLAIN命令现在可以用在DELETE, INSERT, REPLACE,UPDATE语句上。以前，只能用在查询语句上。另外，现在支持json格式输出。见Section 13.8.2, “EXPLAIN Syntax”
53.优化器地于from子句的子查询更有效率。查询执行中会物化子查询以提高性能。另外，优化器还可能对派生表创建索引来加速行检索。更多见：Section 8.13.15.3, “Optimizing Subqueries in the FROMClause (Derived Tables)”
54.优化器使用semi-join和物化来优化子查询，见：Section 8.13.15.1, “Optimizing Subqueries with Semi-Join Transformations”, and Section 8.13.15.2, “Optimizing Subqueries with Subquery Materialization”
55.对关联表查询或者使用join buffer的查询，新算法BKA被使用。BKA支持inner join,outer join,semi-join，包手nested outer joins 和 nested semi-joins。好处是提高了表扫描的性能。更多见：Section 8.13.11, “Block Nested-Loop and Batched Key Access Joins”
56.优化器有追踪功能，对于开发者很有用。optimizer_trace_xxx 系统参数和INFORMATION_SCHEMA.OPTIMIZER_TRACE 表提供接口，更多见 MySQL Internals: Tracing the Optimizer.
八，条件处理
57.MySQL现在支持 GET DIAGNOSTICS 命令，可以提供诊断信息，如前一条sql命令为什么有异常，更多见：Section 13.6.7.3, “GET DIAGNOSTICS Syntax”
58.另外，一些低效的条件处理被修正，使得更像标准的SQL
59.可以在某个块范围定义选择哪个handler，以前一个存储程序只能有一个全局的handler.
60.条件顺序被更准确的解决。
61.诊断区清理改变了。错误#55843导致条件处理在handler被激活以前被清理，使得条件信息无效。现在可以使用GET DIAGNOSTICS得到此信息。当handler存在时条件信息会被清理掉，如果它还没有在handler执行时被清理的话。
62.以前当条件触发时handler立即被激活。现在只有当条件执行完成后再激活，这样可以选择更为合适的handler.这对于触发多个条件的语句和以往的处理是不同的，如当某个更高优先级的条件稍后被触发，而在此范围内有handlers可以处理这些条件时。以前，只有第一个触发的会被选择，即使它的优先级低。现在更高优先级的会被选择，即使不是第一个触发的。
更多请见Section 13.6.7.6, “Scope Rules for Handlers”
九，数据类型
63.TIME, DATETIME, 和 TIMESTAMP 支持更小时的时间粒度，精确到微秒（6位）。见Section 11.3.6, “Fractional Seconds in Time Values”
64.以前每个表最多只有一个TIMESTAMP 列可以用当前时间初始化和更新。这个限制没有了。所有TIMESTAMP列都可以设置这2个属性。另外，DATETIME 也支持这些属性了。更多见Section 11.3.5, “Automatic Initialization and Updating for TIMESTAMP and DATETIME”
65.可以用参数explicit_defaults_for_timestamp关闭默认以前的TIMESTAMP 的默认值及自动初始化、更新属性。更多见 Section 5.1.4, “Server System Variables”。
66.YEAR(2)类型被抛弃，现存的表中的year(2)列会和以前一样处理，但新建或者修改表结构时会转化为YEAR(4).更多见：Section 11.3.4, “YEAR(2)Limitations and Migrating to YEAR(4)”
十，主机缓存
67.现在提供更多关于客户端连接失败的信息，并提高了对于主机缓存的访问，主机缓存包括客户端IP和主机名，避免了DNS解析。
68.新的状态值 Connection_errors_xxx 提供了连接失败的信息，不适用于特写客户端IP。
69.主机缓存增加了对特定IP错误的计数，以及一个新的host_cache Performance Schema表。可以明确知道有多少主机被缓存，每个主机连接失败的错误类型，以及错误主机距离max_connect_errors的上限有多远
70.主机缓存大小由参数 host_cache_size 配置。
更多见： Section 8.11.5.2, “DNS Lookup Optimization and the Host Cache”, 和 Section 20.9.9.1, “The host_cache Table”
十一，OpenGIS
71.OpenGIS定义函数可以测试两个地理位置之间的关系。以前是MBR-based函数返回以矩形测量的结果。现在支持更为精准的形状。这些函数加入ST_前辍，比如Contains() 使用矩形，ST_Contains()使用对象形状。更多见Section 12.17.5.4.2, “Functions That Test Spatial Relationships Between Geometries”
十二，移除参数
72.移除参数
以下被参数移除，同时会显示新的参数。
移除–log，换为–general_log 指定是否开启，–general_log_file=file_name 指定文件名。
移除–log-slow-queries和 log_slow_queries，用–slow_query_log 开启慢查询日志，用–slow_query_log_file=file_name 指定文件名。
移除–one-thread ，使用–thread_handling=no-threads 替换。
移除–safe-mode