**一、什么是MRR **

MMR全称是Multi-Range Read，是MYSQL5.6优化器的一个新特性，在MariaDB5.5也有这个特性。优化的功能在使用二级索引做范围扫描的过程中减少磁盘随机IO和减少主键索引的访问次数。是优化器将随机 IO 转化为顺序 IO 以降低查询过程中 IO 开销的一种手段。（参考： https://blog.csdn.net/caomiao2006/article/details/52205177）

**二、MRR和没有MRR的区别 **

给出一个简单的例子，在innodb表执行下面的查询：

SELECT non_key_column FROM tbl WHERE key_column=x

在没有MRR的情况下，它是这样得到结果的：

1.  select key_column, pk_column from tb where key_column=x order  by key_column —> 假设这个结果集是t

2.  for each row in t ; select non_key_column from tb where pk_column = pk_column_value。(回表)

在有MRR的情况下，它是这样执行的： 1.  select key_column, pk_column from tb where key_column = x  order by key_column —> 假设这个结果集是t 2.  将结果集t放在buffer里面(直到read_rnd_buffer_size这个buffer满了)，然后对结果集t按照 pk_column 排序      —> 假设排序好的结果集是t_sort 3.  select non_key_column from tb where pk_column in (select pk_column from t_sort)

注意: FOR UPDATE 只能用在事务区块(BEGIN/COMMIT)中才有效。

有时候我们会看到一些select语句后面紧跟一句for update，表示手动加锁的意思，这里我们就介绍一下对for update的理解。相对另一种手动加锁方法lock in share mode 的区别见： https://blog.csdn.net/liangzhonglin/article/details/65438777。

for update：IX锁(意向排它锁)，即在符合条件的rows上都加了排它锁，其他session也就无法在这些记录上添加任何的S锁或X锁。如果不存在一致性非锁定读的话，那么其他session是无法读取和修改这些记录的，但是innodb有非锁定读(快照读并不需要加锁)，for update之后并不会阻塞其他session的快照读取操作，除了select …lock in share mode和select … for update这种显示加锁的查询操作。

lock in share mode：是IS锁(意向共享锁)，即在符合条件的rows上都加了共享锁，这样的话，其他session可以读取这些记录，也可以继续添加IS锁，但是无法修改这些记录直到你这个加锁的session执行完成(否则直接锁等待超时)。

for update是一个意向排它锁，也就是说对于select … for update 这条语句所在的事务中可以进行任何操作(锁定的是记录，这里指主键id=1的这条记录)，但其它事务中只能读取(对这条id=1的记录），不能进行update更新操作。

一般用在并发场景下，如双11的时候商品数量的更新，如果不添加for update的话，则会出现商品数量被多减的bug。

为了更加方便理解，我们举例说明(事务隔离级别为 RR，这里表tb的id为主键)

事务A:

start transaction;
select * from tb where id=1 for update;
update tb set product_num=product_num-1 where id=1;

此时另一个事务B执行同样的程序语句:

start transaction;
// 下面此时会被阻塞，直到事务A提交或者回滚
select * from tb where id=1 for update;
update tb set product_num=product_num-1 where id=1;

对于其它主键值非1的不存在这种情况，只要两个事务操作的不是同一条记录就可以执行成功。

推荐阅读： https://blog.csdn.net/u011957758/article/details/75212222

建议先阅读这篇文章： http://hidba.org/?p=404

下面我们只对其中提到的做一个验证。

(1).索引字段的附加信息：可以分为变长和定长数据类型讨论，当索引字段为定长数据类型，比如char，int，datetime，需要有是否为空的标记，这个标记需要占用1个字节；对于变长数据类型，比如：varchar，除了是否为空的标记外，还需要有长度信息，需要占用2个字节；

(备注：当字段定义为非空的时候，是否为空的标记将不占用字节)

(2).同时还需要考虑表所使用的字符集，不同的字符集，gbk编码的为一个字符2个字节，utf8编码的一个字符3个字节， utf8mb4 编码则是4个字节;

每种MySQL数据类型的定义参考：

下面我们以定长数据类型准，变长数据类型请自行测试。

一、数据索引类型允许为null的情况：

表结构：

CREATE TABLE `tb` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`sid` smallint(5) DEFAULT NULL,
`gid` smallint(5) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_common` (`sid`,`gid`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

执行分析语句：

mysql> EXPLAIN select * from tb where sid=1 and gid=5;
+----+-------------+-------+------------+------+---------------+------------+---------+-------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key        | key_len | ref         | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------------+---------+-------------+------+----------+-------------+
|  1 | SIMPLE      | tb    | NULL       | ref  | idx_common    | idx_common | 6       | const,const |    1 |   100.00 | Using index |
+----+-------------+-------+------------+------+---------------+------------+---------+-------------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

发现用到了复合索引idx_common,这时复合索引的两个字段全部用到了，而由于 smallint 数据类型占用字节为两个字节, 属于定长类型，且允许为null,所以key_len长度计算公式为 (2 + 1) + (2 + 1) = 6 下面我们将两个字段全部禁止null看一下计算值

https://my.oschina.net/justfairytale/blog/393830

1 单线程模型

Redis客户端对服务端的每次调用都经历了发送命令，执行命令，返回结果三个过程。其中执行命令阶段，由于Redis是单线程来处理命令的，所有每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个队列中，然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行，不会产生并发问题，这就是Redis的单线程基本模型。

2 单线程模型每秒万级别处理能力的原因

（1）纯内存访问。数据存放在内存中，内存的响应时间大约是100纳秒，这是Redis每秒万亿级别访问的重要基础。

（2）非阻塞I/O，Redis采用epoll做为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了时间，不在I/O上浪费过多的时间。

（3）单线程避免了线程切换和竞态产生的消耗。

（4）Redis采用单线程模型，每条命令执行如果占用大量时间，会造成其他线程阻塞，对于Redis这种高性能服务是致命的，所以Redis是面向高速执行的数据库。

redis为什么要设计成单线程： https://hacpai.com/article/1470967571415

单Redis实例锁： http://www.redis.cn/commands/setnx.html

分布式锁： http://redis.cn/topics/distlock.html（提供各种开发语言提供的库）

Index Condition Pushdown(ICP)

Index Condition Pushdown (ICP)是mysql使用索引从表中检索行数据的一种优化方式。

ICP原理

禁用ICP，存储引擎会通过遍历索引定位基表中的行，然后返回给MySQL Server层，再去为这些数据行进行WHERE后的条件的过滤。

开启ICP，如果部分WHERE条件能使用索引中的字段，MySQL Server 会把这部分下推到存储引擎层，存储引擎通过索引过滤，把满足的行从表中读取出。ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数。

ICP的目标是减少从基表中全纪录读取操作的数量，从而降低IO操作

对于InnoDB表，ICP只适用于辅助索引。

ICP标识

当使用ICP优化时，执行计划的Extra列显示Using indexcondition提示

相关参数

optimizer_switch="index_condition_pushdown=on”;

适用场景

#辅助索引INDEX (zipcode, lastname, firstname).

SELECT * FROM peopleWHERE zipcode='95054'AND lastname LIKE '%etrunia%'AND address LIKE '%Main Street%';

People表有个二级索引 INDEX (zipcode, lastname, firstname),用户只知道某用户的zipcode,和大概的 lastname、address,此时想查询相关信息。

**若不使用ICP：**则是通过 二级索引 中 zipcode 的值去基表取出所有 zipcode='95054' 的数据，然后 server 层再对 lastname LIKE '%etrunia%'AND address LIKE '%Main Street%'; 进行过滤

**若使用ICP：**则 lastname LIKE '%etrunia%'AND address LIKE '%Main Street%' 的过滤操作在二级索引中完成，然后再去基表取相关数据

使用限制

l  只支持 select 语句

错误信息

SQLSTATE[HY000] [2054] The server requested authentication method unknown to…

这个错可能是mysql默认使用 caching_sha2_password 作为默认的身份验证插件，而不再是 mysql_native_password，但是客户端暂时不支持这个插件导致的。 官方文档说明

In MySQL 8.0, caching_sha2_password is the default authentication plugin rather than mysql_native_password. For information about the implications of this change for server operation and compatibility of the server with clients and connectors, see caching_sha2_password as the Preferred Authentication Plugin.

在MySQL 8.0中，caching_sha2_password是默认的身份验证插件，而不是mysql_native_password。有关此更改对服务器操作的影响以及服务器与客户端和连接器的兼容性的信息，请参阅caching_sha2_password作为首选身份验证插件。

解决方法一：修改MySQL全局配置文件

编辑 my.cnf 文件，更改默认的身份认证插件。

$ vi /etc/my.cnf

在 [mysqld] 中添加下边的代码

default_authentication_plugin=mysql_native_password

然后重启mysql

$ service mysqld restart

解决方法二：修改密码认证方式

FROM php:7.2.7-cli
RUN apt-get update 
    && apt-get  install -y libmemcached-dev zlib1g-dev
RUN pecl  install redis-4.0.1 
    && pecl  install swoole-4.0.1 
    && pecl  install memcached-3.0.4 
    && pecl  install xdebug-2.6.0 
    && docker-php-ext- enable redis swoole memcached xdebug
COPY .  /usr/src/myapp
WORKDIR  /usr/src/myapp
CMD [ "php", "-m" ]

构建完环境后，使用方法见： https://blog.haohtml.com/archives/17925

这里推荐另一种更简单的方法 https://github.com/mlocati/docker-php-extension-installer，同时支持多个PHP版本，唯一的不足可能是安装时没有办法指定扩展的版本号或者手动修改脚本文件来完成。

推荐文章： Dockerfile 最佳实践

MySQL使用基于 成本的优化器，它尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的一个。在MySQL可以通过查询当前会话的 last_query_cost 的值来得到其计算当前查询的成本。

mysql> select * from t_message limit 10;
...省略结果集

mysql> show status like 'last_query_cost'
+-----------------+-------------+
| Variable_name   | Value      |
+-----------------+-------------+
| Last_query_cost| 6391.799000 |
+-----------------+-------------+

示例中的结果表示优化器认为大概需要做6391个数据页的随机查找才能完成上面的查询。这个结果是根据一些列的统计信息计算得来的，这些统计信息包括： 每张表或者索引的页面个数、 索引的基数、 索引 和 数据行的长度、 索引的分布 情况等等。

有非常多的原因会导致MySQL选择错误的执行计划，比如统计信息不准确、不会考虑不受其控制的操作成本（用户自定义函数、存储过程）、MySQL认为的最优跟我们想的不一样（我们希望执行时间尽可能短，但MySQL值选择它认为成本小的，但成本小并不意味着执行时间短）等等。

这里last_query_cost的值是 io_cost 和 cpu_cost 的开销总和，它通常也是我们评价一个查询的执行效率的一个常用指标。

(1)它是作为比较各个查询之间的开销的一个依据。

(2)它只能检测比较简单的查询开销，对于包含子查询和union的查询是测试不出来的。

(3)当我们执行查询的时候，MySQL会自动生成一个执行计划，也就是query  plan，而且通常有很多种不同的实现方式，它会选择最低的那一个，而这个cost值就是开销最低的那一个。

(4)它对于比较我们的开销是非常有用的，特别是我们有好几种查询方式可选的时候。

容器为swoole+php7

docker-compose.yml

version: '3.6'
services:
  redis:
    image: redis
  web:
    image: cfanbo/swoole4_php7:v1
    depends_on:
      - redis
    links:
      - redis
    volumes:
      - /Users/sxf/sites/msgserve:/usr/src/myapp
    command: "php /usr/src/myapp/src/wx_push_server.php start"

对于 wx_push_server.php文件里redis的主机地址应该写成docker-compose配置文件里的容器服务名(redis)

https://opensource.com/article/18/6/copying-files-go

更多： https://opensource.com/tags/go

https://studygolang.com/articles/4837 https://blog.csdn.net/dengyisheng/article/details/71215234

https://blog.csdn.net/qq_27093465/article/details/70690749

对于三阶段提交请参考：

https://www.cnblogs.com/binyue/p/3678390.html

https://www.cnblogs.com/charlesblc/p/6289348.html

在 计算机网络 以及 数据库 领域内， 二阶段提交（英语：Two-phase Commit）是指，为了使基于 分布式系统 架构下的所有节点在进行 事务 提交时保持一致性而设计的一种 算法(Algorithm)。通常， 二阶段提交 也被称为是一种 协议(Protocol)。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的 ACID 特性，需要引入一个作为 协调者 的组件来统一掌控所有节点(称作 参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

需要注意的是， 二阶段提交(英文缩写： 2PC)不应该与 并发控制 中的 二阶段锁(英文缩写： 2PL)进行混淆。

目录

[隐藏]

• 1前提
• 2基本算法 - 2.1第一阶段(提交请求阶段)
  • 2.2第二阶段(提交执行阶段) - 2.2.1成功
    • 2.2.2失败
  • 2.3算法示意
• 3缺点
• 4二阶段协议的实现
• 5关联条目
• 6参照

前提[ 编辑]

二阶段提交算法的成立基于以下假设：

1. 该分布式系统中，存在一个节点作为 协调者(Coordinator)，其他节点作为 参与者(Cohorts)。且节点之间可以进行网络通信。

2. 所有节点都采用 预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。

3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

基本算法[ 编辑]

以下对 二阶段提交 算法分阶段进行说明。

第一阶段(提交请求阶段)[ 编辑]

1. 协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。

2. 参与者节点执行询问发起为止的所有事务操作，并将 Undo信息 和Redo信息写入日志。

3. 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。

有时候，第一阶段也被称作 投票阶段，即各参与者投票是否要继续接下来的提交操作。

第二阶段(提交执行阶段)[ 编辑]

成功[ 编辑]

当协调者节点从所有参与者节点获得的相应消息都为”同意”时：

1. 协调者节点向所有参与者节点发出”正式提交”的请求。

2. 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。

3. 参与者节点向协调者节点发送”完成”消息。

4. 协调者节点收到所有参与者节点反馈的”完成”消息后，完成事务。

失败[ 编辑]

如果任一参与者节点在第一阶段返回的响应消息为”终止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：

1. 协调者节点向所有参与者节点发出”回滚操作”的请求。

2. 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。

3. 参与者节点向协调者节点发送”回滚完成”消息。