innodb存储引擎笔记（下）

mysql 5.6 optimizer_trace 查看执行计划选择的过程

 

MVCC

innodb的多版本使用undo&回滚段来构建
innodb是聚集索引组织表，每个行记录有3个额外属性：ROW_ID、TRX_ID、ROLL_PTR
undo记录了更改前的数据镜像，若事务未提交，对隔离级别大于等于read commit的其他事务，它们不应该看到已修改（未提交）的数据，而应一致读取老版本的数据
在修改聚集索引记录时，总是同时存储了ROLL_PTR和TRX_ID，可通过该ROLL_PTR找到对应的undo记录，通过TRX_ID来判断该记录的可见性
当旧版本记录中的TRX_ID指示对当前事务不可见时，则继续向前（更新的TRX_ID）构建，知道找到一个可见的记录。
innodb在表空间中保存行的旧版本信息，这些信息被保存在回滚段中
事务标识符（TRX_ID）指示最后插入或更新这个行的事务标识符，删除标志也被认为是一个更新，因为它在提交前指示在杭商做了一个标记。
回滚指针（DB_ROLL_PTR）指向一个由回滚段写入的undo日志记录。如果一个行被更新了，undo日志记录包含了重建这行更新前的信息的一些必要数据
回滚段中的undo日志分为插入日志（主要是insert操作）和更新日志（包含update和delete）。插入日志仅在事务回滚的时候有用，事务提交之后就可以马上删除掉。更新日志在一致性读的时候需要使用，如果当前没有事务再可能使用回滚段中的记录的时候，这些记录就可以删除掉了。因此，最好以适当频率提交事务，否则innodb不能删除掉过期更新日志，回滚段越来越大。
回滚段中undo日志记录的物理大小要比其对应的插入或者更新的行要小（只记录修改的列，不记录完成的列）
当删除某一行时，改行并不会马上从数据库的物理文件上移除，只有当innodb可以清除更新日志记录的时候，那些行机器对应的索引记录才会真正从物理上删除掉，这个清楚操作成为purge。purge以前需要由主线程来掉地，现在5.6版本已经分离出来了

 

redo

ib_logfile文件个数由innodb_log_files_in_group配置决定（至少>=2）,文件名序号从0开始，从ib_logfile0到ib_logfileN
文件为顺序写入，循环使用，当达到最后一个文件末尾时，会从第一个文件开始顺序复用，redo文件切换时，会执行一次checkpoint（刷redo log，刷dirty page）
实例重启的过程中，实例关闭以后（正常关闭，不是崩溃），redo是可以删掉的，实例开启之后会重新初始化redo，但是undo不能删
redo log用于记录事务操作变化，记录的是数据被修改之后的值（undo记录的是数据被修改之前的值）
不会记录临时表空间上的变化（mysql 5.7起开始有独立的临时表空间）
redo记录的是逻辑操作，类似binglog，不像oracle是块记录。它需要应用到一个正确的page上面，如果该page本身被破坏了，则无法恢复出正确的数据，所以需要用到double write buffer
会先放在log buffer（innodb_log_buffer_size）中，而不是立即写磁盘
LSN:log sequence number，递增的证书，表示redo总字节数
每次写盘后是否flush，由参数innodb_flush_log_at_trx_commit控制
从5.5开始，redo的大小不再影响crash recovery的耗时，只影响checkpoint频率，设置较大值可减少IO消耗

 

redo log buffer刷新条件

master thread每秒进行刷新
redo log buffer使用大于1/2进行刷新
事务提交时进行刷新  
innodb_flush_log_at_trx_commit={0|1|2}
设置innodb_flush_log_at_timeout（默认1秒）
innodb_flush_log_at_trx_commit

0，事务提交时不将redo log buffer写入磁盘
1，事务提交时将redo log buffer写入磁盘
2，事务提交时将redo log buffer些人操作系统缓存
通常建议设置为1，并且设置sync_binlog=1，以保证数据可靠性（双1）
innodb_log_buffer 
通常8-32M就足够了
innodb_log_file_size 
一般设置为512M-4G
innodb_log_files_in_group 
至少两个文件

 

redo log和binlog的区别

 

redo是物理逻辑日志，binlog是逻辑日志
redo是发起时间顺序存储，而binlog是按事务提交时间顺序存储
redo log file循环使用，binlog每次新增一个文件
binlog更像oracle里的redo归档

 

undo

用于实现MVCC以及回滚
当我们对记录做了变更操作时就会产生undo记录，记录变更前的旧数据
undo记录中存储的是老版本的数据，当一个旧的事务需要读取老版本数据时，为了能读到老版本的数据，需要顺着undo链找到满足可见性的记录。当版本链很长时，通常可以认为这个是比较耗时的操作。
undo记录默认被记录到系统表空间（ibdata*）中，但是从5.6开始，也可以使用独立的undo表空间
大多数对数据的变更操作包括insert/delete/update
其中insert操作在事务提交前只对当前事务可见，因此产生的undo日志可以在事务提交后直接删除，归类为insert_undo
而对于update/delete则需要维护多版本信息，在innodb里，update和delete操作产生的undo日志被归为一类，即update_undo
MySQL5.7在undo上面的变化 
innodb_undo_logs，rollback seg数量，比如将2G的undo tablespace，切分成多少分rollback seg。默认128个，实例初始化后不可再修改。每个undo log seg可以最多存放1024个事务
innodb_undo_tablespaces，undo log文件数，每个文件默认10MB，数量默认0，最大95个，最小2个，因为在truncate一个undo log文件时，需要保证另外一个是可用的，这样就无需停止业务了
innodb_max_undo_log_size，控制最大undo tablespace文件的大小，超过这个值尝试truncate undo logs，truncate后的undo logs大小默认恢复为10M
innodb_purge_rseg_truncate_frequency，用于控制purge回滚段的频率，默认128，表示purge undo轮询128次后，进行一次undo的truncate
innodb_max_purge_lag = 10000 （如果值不为0，当目前所有未purge的undo，如果超过10000，那么新发生的DML都会被阻塞一小段时间）innodb_max_purge_lag 最好设置为0（即默认值）
innodb_max_purge_lag_delay = 10000（每10秒至少做一次purge）
以上两个参数的案例，可以参考老叶茶馆的文章《是谁，把innodb表上的DML搞慢的？》
MySQL5.7之后 
支持在线truncate不用的undo logs
set global innodb_undo_log_truncate = 1，手工truncate undo log
当undo超过innodb_max_undo_log_size时进行truncate
总结：三种truncate操作：手工，128次，超过max size
show engine innodb status 里的history list length 
已提交事务，但未purge的update undo log，也就是等待purge的undo log的大小

事务在redo log、binlog中的逻辑过程

a）事务写入redo log buffer 
b）将log buffer刷新到redo log，不过会先写TRX prepare标记 
c）写binlog 
d）在redo log写入TRX commit标记 
e）将写binlog成功的标记写入redo log

若binlog写入完成，则主从库都会正常完成事务；binlog没有写入，则主从库都不会完成事务。不会出现主从不一致的问题，除非trx_commit=0/2才有这个风险
slave上master&relay info repository必须是TABLE，且设置relay_log_recovery=1，另外master那边设置双1，才能保证主从数据一致性。

 

innodb后台线程

默认有15个 
 - master thread（1个） 
 - IO thread 
  - read/write thread（8个，读写默认各4个） 
  - insert buffer thread（1个） 
  - log io thread（1个） 
 - lock monitor thread（1个） 
 - error monitor thread（1个） 
 - purge thread（1个） 
 - page cleaner(flushing) thread（1个） 
 - MySQL5.6起，master thread的工作已被大大减轻，purge，page clean等成独立线程了

 

后台线程

master thread（主线程）的线程优先级别最高
其内部几个循环（loop）组成：主循环（loop），后台循环（background loop），刷新循环（flush loop），暂停循环（suspend loop）
会根据数据运行的状态在loop，background loop，flush loop和suspend loop中进行切换
loop成为主循环，因为大多数的操作都在这个循环中
loop循环通过thread sleep来实现，这意味着所谓的每秒一次或10秒一次的操作时不精确的
在负载很大的情况下可能会有延迟

 

master thread

master thread
2个循环 
每秒要做的事
每10秒要做的事
如何查看：

5.6以后select * from performance_schema.threads limit 10;
5.6以前show engine innodb status，从background thread里面查看 

每秒要做的事

刷新dirty page到磁盘
执行insert buffer merge（change buffer）
刷redo log buffer到磁盘
checkpoint
检查dict table cache，判断有无需要删除table cache对象
每10秒要做的事 
刷新dirty page到磁盘
执行insert buffer merge
刷redo log buffer到磁盘
undo purge
checkpoint
实例关闭时 
刷redo log到磁盘
insert buffer merge
刷redo log buffer 到磁盘
执行checkpoint
优化建议 
避免dirty page堆积，适当调整innodb_max_dirty_pages_pct(<=50)
避免undo堆积，调整innodb_max_purge_lag/innodb_max_purge_lag_delay/innodb_purge_batch_size
及时checkpoint，调整innodb_flush_log_at_trx_commit/innodb_adaptive_flushing/innodb_adaptive_flush_lwm/innodb_flush_neighbors/innodb_flush_avg_loops
保持事务持续平稳提交，不要瞬间大事务，或者高频率小事务

 

checkpiont

定期确认redo log落盘，避免数据丢失，并提高crash recovery效率
buffer pool脏数据太多，把脏页刷新到磁盘，释放内存
redo log快用完了，把脏页刷新到磁盘
redo log切换时，需要执行checkpoint

 

---
LOG
---
Log sequence number 693064238
Log flushed up to   693064238
Pages flushed up to 693064238
Last checkpoint at  693064238
Max checkpoint age    651585393
Checkpoint age target 631223350
Modified age          0
Checkpoint age        0
0 pending log writes, 0 pending chkp writes
8 log i/o's done, 0.00 log i/o's/second12345678910111213

 

checkpoint两种方式

sharp checkpoint 
将所有脏页都刷新回磁盘
刷新时系统hang住
比较暴力，只有在需要干净重启是才需要
innodb_fast_shutdown = 0
0，slow，full purge，insert buffer merge（也就是不允许fast shutdown，要求做完整的关闭操作）
1，默认，fast，skip these operation
2，flush logs，cold status，like crashed
fuzzy checkpoint 
持续将脏页刷新回磁盘
对系统影响较小，但可能刷新较慢，会有迟滞
innodb_max_dirty_pages_pct = 75
innodb_max_dirty_pages_pct_lwm = 0

问：什么情况下innodb_fast_shutdown要设为0（保证数据安全） 
答： 
 1. 实例升级版本 
 2. 主从切换 
 3. 实例迁移 
 4. 物理关机

 

page cleaner(flushing)（脏页的刷新）

将脏页刷新落地到硬盘
有两种方式 
LRU Flushing，基于LRU_list（基于最后访问时间的排序）的刷新顺序
Adaptive Flushing，基于Flush_list（严格按照最后修改时间的顺序，LSN）的刷新顺序，innodb_adaptive_flushing = 1
扫描列表，并找到邻居页面（innodb_flush_neighbors = 1,机械盘适用，SSD盘可关闭），一起刷新
刷新过程 
将脏页拷贝到double write buffer
刷新double write buffer到文件
同步double write buffer到磁盘
写数据文件
同步刷数据文件到磁盘，确保落地

 

undo purge

简单说，就是GC（garabge collection）
purge都做啥 
删除辅助索引中不存在的记录
删除已被打了delete-mark标记的记录
删除不需要的undo log
从5.6开始，将purge thread独立出来 
–innodb_purge_threads = 1
–innodb_max_purge_lag = 0
–innodb_purge_batch_size = 300
案例：删除大量旧数据后，统计min（pkid）很慢

 

insert buffer/change buffer

将非唯一辅助索引上的IUD操作从随机变成顺序IO，提高IO效率
官方测试号称约提高15倍
工作机制 
先判断插入的非聚集索引页是否在缓冲池中，若在，则直接插入
若不在，则先放入到一个change buffer对象中
change buffer也是棵树，B+树
每次最多缓存2k的记录
当读取辅助索引页到缓冲池，将insert buffer中该页的记录合并到辅助索引项
–innodb_change_buffer_max_size（这个是百分比，默认25%，表示最多有25%的buffer pool用来做change buffer）
–innodb_change-buffering（默认all，即包括insert update delete，none就是什么都不做，此外还有insert，update，delete）

1.fast shutdown不进行insert buffer合并
2.insert buffer进行合并插入时，tps会受影响
3.insert buffer占用一部分buffer pool，如果辅助索引不多，可以考虑关闭或调低insert buffer
show engine innodb status查看insert buffer相关内容

 

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 1289, seg size 1291, 316623 merges
merged operations:
 insert 249806, delete mark 1123127, delete 85482
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 2365399, node heap has 3863 buffer(s)
Hash table size 2365399, node heap has 2606 buffer(s)
Hash table size 2365399, node heap has 3849 buffer(s)
Hash table size 2365399, node heap has 2100 buffer(s)
Hash table size 2365399, node heap has 2409 buffer(s)
Hash table size 2365399, node heap has 6709 buffer(s)
Hash table size 2365399, node heap has 1118 buffer(s)
Hash table size 2365399, node heap has 3659 buffer(s)
37515.35 hash searches/s, 4553.64 non-hash searches/s1234567891011121314151617

注释： 
size 1 =>正在使用的page 
free list len => 空闲的page 
seg size =>总的insert buffer page数量size + free list len + 1 
insert buffer的效果 = merges / (insert + delete mark + delete)

 

double write，双写

目的/作用：保证数据写入的可靠性（防止数据页损坏，又无从修复）
因为innodb有partial write问题 
16k的页只写入了部分数据时发生crash
redo里记录的是逻辑操作，不是物理块，无法通过redo恢复
怎么解决partial write问题

双写，double write
2个1M的空间，共2M（既有磁盘文件，也有内存空间）
页在刷新时首先顺序的写入到double write buffer
然后再刷新回磁盘
在可以保证原子写的硬件设备或文件系统下，可以被关闭
slave上也可以关闭
double write写入是顺序的，性能损失很小（SSD设备上损失则比较大）
MySQL5.7起，采用PCIe SSD设备是会自动判断，是否要关闭double write buffer
先写double buffer，再写磁盘，如果double write写失败了，那么肯定没写入磁盘 

double write的状态统计（mysqladmin ext | grep -i dbl）

innodb_dblwr_pages_written（发起多少次写的请求）
innodb_dblwl_writes（实际写了多少次）
理想比例是64:1，因为1M包含64个page，但是很难达到这高比例
性能损失 
–innodb_double = 0关闭，1打开
status
innodb_dblwr_pages_written
innodb_dblwr_writes

 

预热

buffer pool dump& restor 启动预热 
innodb_buffer_pool_filename
innodb_buffer_pool_dump_now
innodb_buffer_pool_dump_at_shutdown
innodb_buffer_pool_load_now
innodb_buffer_pool_load_at_startup
手工预热 
select count(*) from t force index(primary)
select count(*) from t
select * from t
可以防止数据库刚开起来因为承受不了瞬间到来的物理读请求而秒崩，强烈建议开启（5.6以后才有的功能，且可以在线动态开启）。

 

adaptive hash index

对buffer pool中热点索引页数据再次进行索引
目的：缓存索引中的热点数据，提高检索效率，O(1) VS O(N)（从对B+树的搜索变为对hash的搜索）
对热点buffer pool建立AHI，非持久化
只支持等值查询 
idx_a_b(a,b)
where a = xx
where a = xx and b = xx
AHI很可能是部分长度索引，并非所有查询都能有效果
设置innodb_adaptive_hash_index = 0 关闭
设置innodb_adaptive_hash_index_parts 使用AHI分区/分片降低竞争提高并发
个别场景下，开了AHI后，可能导致spin_wait lock 比较大，可以关闭掉
评估自适应hash索引的作用（show engine innodb status）

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 1289, seg size 1291, 316623 merges
merged operations:
 insert 249806, delete mark 1123127, delete 85482
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 2365399, node heap has 3863 buffer(s)
Hash table size 2365399, node heap has 2606 buffer(s)
Hash table size 2365399, node heap has 3849 buffer(s)
Hash table size 2365399, node heap has 2100 buffer(s)
Hash table size 2365399, node heap has 2409 buffer(s)
Hash table size 2365399, node heap has 6709 buffer(s)
Hash table size 2365399, node heap has 1118 buffer(s)
Hash table size 2365399, node heap has 3659 buffer(s)
37515.35 hash searches/s, 4553.64 non-hash searches/s1234567891011121314151617

注：AHI的作用 hash searches / (hash searches + non-hash searches)

 

crash recovery

redo，redo前滚结束后，server开始对外提供服务，后面的过程放在后台线程继续工作
当实例从崩溃中恢复，需要将活跃的事务从undo中提取出来，对于ACTIVE状态的事务直接回滚，对于prepare状态的事务，如果该事物对应的binlog已经记录，则提交，否则回滚事务
change buffer merge
purge
xa recover

 

加快crash recovery速度

升级到5.5以后的版本
提高IO设备性能
适当调低innodb_max_dirty_pages_pct，50以下
设置innodb_flush_log_at_trx_commit = 1，让每个事务尽快提交，避免有其他事务等待，产生大量的undo，增加purge工作量
5.7又进一步改进，crash recovery时无需扫描所有数据文件并创建内存对象（数据文件巨多时会产生严重性能问题），而只检查checkpoint+那些标记为被修改过的文件，从一个checkpoint点开始，可以找到所有崩溃恢复需要打开的文件，从而避免扫描数据目录

 

innodb引擎重点参数

innodb_buffer_pool_size 
最大的内存块，建议为物理内存的50-80%
innodb_max_dirty_pages_pct 
buffer pool中dirty page最大占比，建议不超过50%
innodb_old_blocks_pct 
buffer pool中old block sublist最大占比，默认3/8
innodb_change_buffering 
change buffer 类型，ALL或其他
innodb_log_buffer_size 
redo log buffer，能缓存5秒左右产生的redo就够，32MB基本管够
innodb_sort_buffer_size？？？（后续研究） 
innodb往表中批量加载数据更新索引。以及Online DDL时，将当前发生的DML记录到临时log中？？？。（不要只看字面意思）
innodb_data_file_path 
共享表空间初始大小，建议至少1G以上
innodb_log_file_size 
redo log大小，加大有助于减小checkpoint频率，提高tps
innodb_flush_log_at_trx_commit 
redo log刷新机制，1最安全，0性能最好，2折中
innodb_io_capacity 
innodb 后台线程最大iops上限
innodb_flush_methon 
刷新innodb data file和log file使用方式，推荐O_DIRECT
innodb_stats_on metadat = 0 
执行show table status / show index时是否更新统计信息
innodb_autoinc_lock_mod = 1 
auto-inc锁模式，推荐1
innodb_file_per_table =1 
是否启用独立表空间，推荐1。5.5开始可动态修改
innodb_fast_shutdown = 0/1 
是否快速关闭，推荐1。需要版本升级或机器重启是，要改为0。
innodb_force_recovery = 0 
innodb恢复级别，可选0-6，从最小开始尝试启动。默认一定要设置为0。