《高性能Mysql 第三版》笔记

p46, 1.3.3 事务日志: 预写式日志（Write-ahead logging)

p46, Mysql默认采用自动提交

p49, InnoDB的MVCC实现：

我注：按SnailMann-----【MySQL笔记】正确的理解MySQL的MVCC及实现原理 等资料，总结如下：

1. MVCC依赖每行的两个隐藏列：DB_TRX_ID，创建这条记录/最后一次修改该记录的事务 ID；
   DB_ROLL_PTR，回滚指针，指向这条记录的上一个版本（存储于undo log）。
   所以，对同一记录的修改，会导致该记录的undo log成为一条记录版本的链表。
2. Read View 就是事务进行快照读时的读视图，主要是用来判断当前事务能够看到哪个版本的数据。遍历当前记录+链表，直到找到满足特定条件的 DB_TRX_ID , 那么此记录就是当前事务能看见的最新老版本。
3. 第2点中的特定条件的判断逻辑：
   trx_list，用于维护 Read View 生成时刻系统 正活跃的事务 ID 列表；
   低水位，是 trx_list 列表中最小的 ID；
   高水位，ReadView 生成时刻系统尚未分配的下一个事务 ID （即目前已出现过的事务 ID 的最大值 + 1）。
   首先比较 DB_TRX_ID < 低水位 , 如果小于，则返回true；
   接下来判断 DB_TRX_ID >= 高水位 , 如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View 生成后才出现，返回false;
   判断 DB_TRX_ID 是否在活跃事务trx_list之中，如果在，则代表Read View 生成时，这个事务还在活跃，还没有 Commit，返回false；如果不在，返回true
4. 读已提交隔离级别下，每个快照读都会生成并获取最新的 Read View；而在 可重复读隔离级别下，则是同一个事务中的第一个快照读才会创建 Read View, 之后的快照读获取的都是同一个 Read View

上述总结来源的其它参考资料: 官方文档：Read View
官方文档：consistent read

相关问题：MySQL 可重复读隔离级别，完全解决幻读了吗？
针对快照读（普通 select 语句），是通过 MVCC 方式很大程度上避免了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。
针对当前读（select … for update 等语句），是通过 next-key lock（间隙锁）方式解决了幻读，因为当执行 select … for update 语句的时候，会加上 next-key lock，如果有其他事务在 next-key lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好了避免幻读问题。
这两个解决方案是很大程度上解决了幻读现象，但是还是有个别的情况造成的幻读现象是无法解决的。

p54, MyISAM对整张表，而不是行加锁

p161 为标识列选择合适的数据类型：

p166
范式的优点：

范式的缺点：

反范式：

p176, alter table:

p192, 前缀索引：

p194, 索引合并(index merge)：

p195 索引的选择性：

from p198 5.3.5 聚簇索引：

• 聚簇索引:
  
• InnoDB的主键是聚簇索引:
  
  使用二级索引（非聚簇索引）访问需要回表：
  
• MyISAM使用非聚簇索引:
  
• 聚簇 vs 非聚簇：
  
• 在InnoDB表中按主键顺序插入行：
  

p207 覆盖索引：

p248 查询优化处理中的覆盖索引扫描：

p218 Explain结果中的Extra列的Using where:

select … for update: 加排他锁

p220:

p228 按顺序访问范围数据快，因为顺序I/O不需要多次磁盘寻道：

p238 切分查询：

p277 优化limit分页，及其中一种办法：
p298 超大表不推荐用索引

p321 绑定变量：

p363 获取配置文件路径： /usr/sbin/mysqld --verbose --help | grep -A 1 'Default options'
p412

p420

p412 预写日志(WAL)：

p502

p520

p567 保持活跃数据独立：

p570 比较常见的读写分离方法：

p594 《故障转移和故障恢复》之《虚拟IP地址或IP接管》：

p653 快照是写时复制的