大家好，我是 Snow Hide，作为《MySQL 实战》这个专栏的学员之一，这是我打卡的第 61 天，也是我第 123 次进行这种操作。
今天我温习了该专栏里叫《都说InnoDB好，那还要不要使用Memory引擎？》、《要不要使用分区表？》、《自增主键为什么不是连续的？》、《自增id用完怎么办？》、《答疑文章（三）：说一说这些好问题》、《“order by”是怎么工作的？》的文章。
关键词总结：内存表的数据组织结构（InnoDB 和 Memory 引擎的数据组织方式、两个引擎的不同之处）、hash 索引和 B-Tree 索引（不建议在生产环境使用内存表的两个主要原因）、内存表的锁、数据持久性问题（M-S 架构使用内存表存在的问题、建议把普通内存表都替换成 InnoDB 表的原因、内存临时表可以无视内存表的两个不足，主要的三个原因、使用内存临时表比 InnoDB 临时表效果更好的三个原因）、分区表是什么？（分区表的组织形式）、分区表的引擎层行为（分区表和手工分表）、分区策略（MyIASM 分区策略、InnoDB 本地分区策略、各版本间的变动）、分区表的 server 层行为（分区表在 server 层和引擎层的访问过程）、分区表的应用场景（drop 分区和 delete 行相比）、自增值保存在哪儿？（不同的引擎对于自增值的保存策略不同）、自增值修改机制（当字段 id 被定义为 AUTO_INCREMENT 时插入一行数据时自增值的行为、自增值的变更结果取决于要插入的值和当前自增值的大小关系、新的自增生成算法、当 auto_increment_offset 和 auto_increment_increment 都是 1 时新的自增值生成逻辑）、自增值修改时机（插入重复语句的执行流程、导致自增主键 id 不连续的两种原因、解决两个事务申请到相同的自增 id 导致主键冲突的两种方法）、自增锁的优化（MySQL 5.1.22 新策略新增参数 innodb_autoinc_lock_mode、会话二申请了自增值以后马上就释放自增锁可能出现的情况、原库会话二插入语句生成的 id 不连续导致 statement 格式 binlog 无法串行执行的两种问题解决思路、批量插入数据语句的批量申请自增 id 策略）、InnoDB 系统自增 row_id（row_id 能写到数据表中的值有两个特征）、Xid（理论上 2 的 64 次方减 1 出现时的过程）、Innodb trx_id（只读事务 InnoDB 并不会分配 trx_id、实验时不止加 1 的原因、只读事务不分配 trx_id 的好处）、thread_id、join 的写法（join 执行顺序的两个问题、BNL 算法时语句的执行流程）、Simple Nested Loop Join 的性能问题（BNL 算法的执行逻辑、MySQL 中索引结构和 Buffer Pool 的相关知识点）、distinct 和 group by 的性能（两条语句的执行流程）、备库自增主键问题、全字段排序（语句的执行流程、MySQL 需要 12 个临时文件来做排序的原因）、row_id（指定排序的行数据长度后所采用的另一种算法、由于行数据长度过短导致排序结果少了 city 和 age 后整个执行的流程）、全字段排序 VS rowid 排序（创建 city 和 name 联合索引、city 满足一个值之后name 的值就一定是有序的、创建 city、name 和 age 联合索引、对于 city 字段值相同的行来说 name 字段的值递增也是递增排序）。
所学总结：
内存表的特性与适用场景
内存表的数据组织结构
InnoDB 和 Memory 引擎的数据组织方式
两个引擎的不同之处
hash 索引和 B-Tree 索引
不建议在生产环境使用内存表的两个主要原因
内存表的锁
数据持久性问题
M-S 架构使用内存表存在的问题
建议把普通内存表都替换成 InnoDB 表的原因
内存临时表可以无视内存表的两个不足，主要的三个原因
使用内存临时表比 InnoDB 临时表效果更好的三个原因
分区表
分区表是什么？
分区表的组织形式
分区表的引擎层行为
分区表和手工分表
分区策略
MyIASM 分区策略
InnoDB 本地分区策略
各版本间的变动
分区表的 server 层行为
分区表在 server 层和引擎层的访问过程
分区表的应用场景
drop 分区和 delete 行相比
自增主键
自增值保存在哪儿？
不同的引擎对于自增值的保存策略不同
自增值修改机制
当字段 id 被定义为 AUTO_INCREMENT 时插入一行数据时自增值的行为
自增值的变更结果取决于要插入的值和当前自增值的大小关系
新的自增生成算法
当 auto_increment_offset 和 auto_increment_increment 都是 1 时新的自增值生成逻辑
自增值修改时机
插入重复语句的执行流程
导致自增主键 id 不连续的两种原因
解决两个事务申请到相同的自增 id 导致主键冲突的两种方法
自增锁的优化
MySQL 5.1.22 新策略新增参数 innodb_autoinc_lock_mode
会话二申请了自增值以后马上就释放自增锁可能出现的情况
原库会话二插入语句生成的 id 不连续导致 statement 格式 binlog 无法串行执行的两种问题解决思路
批量插入数据语句的批量申请自增 id 策略
InnoDB 系统自增 row_id
row_id 能写到数据表中的值有两个特征
Xid
理论上 2 的 64 次方减 1 出现时的过程
Innodb trx_id
只读事务 InnoDB 并不会分配 trx_id
实验时不止加 1 的原因
只读事务不分配 trx_id 的好处
thread_id
几个好问题
join 的写法
join 执行顺序的两个问题
BNL 算法时语句的执行流程
Simple Nested Loop Join 的性能问题
BNL 算法的执行逻辑
MySQL 中索引结构和 Buffer Pool 的相关知识点
distinct 和 group by 的性能
两条语句的执行流程
备库自增主键问题
order by 的算法流程
全字段排序
语句的执行流程
MySQL 需要 12 个临时文件来做排序的原因
row_id
指定排序的行数据长度后所采用的另一种算法
由于行数据长度过短导致排序结果少了 city 和 age 后整个执行的流程
全字段排序 VS rowid 排序
创建 city 和 name 联合索引
city 满足一个值之后name 的值就一定是有序的
创建 city、name 和 age 联合索引
对于 city 字段值相同的行来说 name 字段的值递增也是递增排序
末了
重新总结了一下文中提到的内容：在生产上不建议使用普通内存表、可以在建表的审核系统中增加改用 InnoDB 表的规则、内存表支持 hash 索引，所以对复杂查询的加速效果很好、server 层和引擎层对分区表的处理方式、MySQL 还支持 hash 分区 / list 分区等方法、分区并不是越细越好、要及时 drop 掉没有数据的历史分区、跨分区读数据慢的问题一般是数据量或使用方式造成的、自增值的存储、MyISAM 引擎的自增值写在数据文件上、InnoDB 引擎的自增值被记录在内存中、MySQL 8.0 给 InnoDB 表自增值加上了持久化能力、语句执行过程中自增值改变时机、MySQL 在事务回滚时不能回收自增 id 的原因、MySQL 5.1.22 引入的参数 innodb_autoinc_lock_mode 控制了自增值申请时的锁范围、MySQL 不同的自增 id 到达上限以后的行为、每个自增 id 的应用场景、不同自增 id 的上限值取决于声明类型的长度、MySQL 里 order by 语句的几种算法流程、每个语句的排序实现、每个语句的执行对系统资源的消耗。
