根据加锁的范围，MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类。
全局锁是对整个数据库实例加锁。MySQL 提供的一个加全局锁的命令： Flush tables with read lock (FTWRL)，让整个库处于只读状态。
全局锁的典型使用场景是做全库逻辑备份。
逻辑备份工具 mysqldump 使用参数 -single-transaction 的时候在导数据之前就会启动一个事务，来确保拿到一致性视图。
一致性读的前提是引擎要支持这个隔离级别的事务。
set global readonly=true 也可以让全库进入只读状态。但存在两个风险： readonly 的值可能被用来做其他逻辑，比如判等一个库是主库还是备库；设置 readonly 之后，如果客户端发生异常，则数据库会一直保持 readonly 状态。
在 slave 上，如果用户有超级权限的话，全库只读 readonly=true 是失效的。
FTWRL 执行完后如果客户端异常断开，MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。
用 explain 命令查看执行计划的时候，Extra 列的值含有 “using filesort” 表示需要排序，可能是在内存里排序、也可能是磁盘文件排序。MySQL 给每个线程分配一块内存用于排序，称为 sort_buffer ，可以通过参数 sort_buffer_size 调整这个内存的大小。
如果要排序的数据都能放进 sort_buffer 则直接在内存里排序，否则需要借助磁盘临时文件进行辅助排序。
由于 InnoDB 是索引组织表，聚簇索引就是主键索引，下面的描述就用 rowid 替代主键值。
InnoDB 在创建或重建索引时采用 批量加载而不是一次插入一个索引记录的方式。这种索引创建方法也称为 Sorted Index Build ，该方式不支持空间索引。
索引创建有三个阶段：
第一阶段，扫描聚簇索引，生成索引条目并添加到排序缓存(sort buffer)。当排序缓存满了后，条目被排序、写入临时的中间文件。这个过程也称为 run 。
第二阶段，一个或多个 run 写入临时中间文件，对文件里的所有条目执行合并排序。
在第三阶段，排序后的条目被插入到 B+tree 上。
Sorted Index build 采用自底向上方式来构建索引，采用这种方式，在 B+Tree 的每一层，持有对最右叶子页的引用。位于B+Tree需要的深度的最右叶子页被分配，条目按它们排序后的顺序插入。一旦叶子页满了，一个节点指针追加到父页上，同层叶子页被分配用于接下来的插入。这个过程持续至所有条目插入完成，这可能导致插入一直到顶层。
白话解读：最底层的最右叶子页插入索引记录，如果当前最右叶子页满了，生成一个新的最右叶子页作为接下来的插入位置，在新旧最右叶子页之间建立指针链接，然后把指向旧最右叶子页的指针追加到上一层的最右叶子页，触发上一层的最右叶子页插入，逻辑跟前面是一样的，这是个递归的过程，直至根页。这是一个自底向上、递归构建的过程。
最终生成的索引结构如下图（图片来自MySQL内核解析：Innodb页面存储结构-1）：
可以使用 innodb_fill_factor 配置选项来指定在 B+Tree 页空间保留的空闲百分比，用于后续在这些位置插入索引条目。
这个设置应用于索引树的叶子和非叶子页。不适用于外部页如用于 TEXT/CLOB 条目的。
这个配置是一个提示而非强制约束。
近期公司的运维同事对一些系统尝试利用 K8S 的滚动发布机制不停机发布系统，应用和系统的状况是：POD 里的应用实例是注册在 Consul 上，Consul 的健康检查间隔是 10 秒；它们配置的 K8S 滚动发布机制直接把跑应用的 POD 终止了。
这样出现了：应用实例被终止后到 Consul 下次健康检查之前，Consul 认为应用实例是还存活的，把请求分发给了已经被停止的实例，这些请求当然是失败的。有的系统因为下游不支持重试，之前出现应用重试导致出现异常数据，就把 Ribbon、Feign、Hystrix 等的重试机制禁用了。而没有了重试机制请求就直接失败了，这样用户就会感知到系统发布。
大家开会讨论怎么才能让系统发布不会影响请求响应：
另一个部门的同事说他们就是所有接口都支持重试，所以允许对服务的某个实例请求失败可以重试到另一个实例，这样基本不会影响请求处理。让所有接口支持重试是需要上下游系统协调的，而且需要比较长的时间来实现。还有个问题是，不是所有接口都能重试的，举个行业特定的例子：信贷审批一般都会去查借款人的人行征信报告，多查一次可能导致借款人几个月都没法借款，设想一个报告查询的请求发出去了、在响应还没落地之前，应用实例就被终止了，这肯定是没法接受的。所以应用实例需要在被终止之前得到一个机会—-可以优雅停机的机会，它需要一个停机的通知。对于前面的问题，就是 K8S 要在停机前通知到 POD 里的实例，等通知返回后再终止 POD。
这就带来这个小插曲，我提出 K8S 在停止 POD 之前给 POD 里的应用发个通知的时候，运维同事说 Consul 和 K8S 是不同的系统，没法做到，他们说的非常肯定。。。
对于一个问题，自己解决不了 跟 问题无解 是有区别。
在网上搜索一番后找到了 POD 生命周期钩子
最近看了极客时间上 《MySQL实战45讲》，纠正了一直以来对 InnoDB 二级索引的一个理解不到位，正好把相关内容总结下。PS：本文的所有测试基于 MySQL 8.0.13 。
先把问题抛出来，下面的 SQL 所创建的表，有两个查询语句，哪个索引是非必须的？
CREATE TABLE `geek` (
`a` int(11) NOT NULL,
`b` int(11) NOT NULL,
`c` int(11) NOT NULL,
`d` int(11) NOT NULL,
PRIMARY KEY (`a`,`b`),
KEY `c` (`c`),
KEY `ca` (`c`,`a`),
KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;
select * from geek where c=N order by a limit 1;
select * from geek where c=N order by b limit 1;
作者给的答案是索引 c 和 ca 的数据模型是一样的，因此 ca 是多余的。为啥？？
我们知道，二级索引里存放的不是行的位置，而是主键的值，也知道索引是有序的。
如果 c 与 ca 的数据模型一样，那么就要求二级索引的叶子节点不仅是按索引列排序、而且还按关联的主键值进行排序。
我以前的理解是 二级索引只按索引列进行排序，主键值是不排序的。
问了专栏作者，得到的答复是：索引 c 就是按照 cab 这样排序，（二级索引)）有保证主键算进去、还是有序的。（PS：非原话，前后问了三次得到）。
本着 先问是不是，再问为什么 的思路，进行一番探究。