MySQL内核InnoDB存储引擎(卷1)
目录
概览
基本数据结构和算法
同步机制
- rw-lock/latch
- s-/x-:x-可递归,s-不可?;以spin获得,一段时间后进入wait array(信号量?)
- p38 若sync_primary_wait_array中1000个cell都已分配,则ut_error触发crash
- 当持有latch的线程释放latch后,调用sync_array_signal_object唤醒等待线程
重做日志
- p42 redo log原来保证事务的持久性(D),undo log用于回滚和MVCC
- innodb_flush_log_at_trx_commit=0/1/2
- redo log VS. bin log
- 前者记录的是页的物理逻辑操作日志
- 设计思想:物理日志记录页内的修改(old-new value),逻辑日志记录对表的操作(insert/delete)
- LSN(表示事务写入redo log的字节量?)
- 对‘检查点’,表示刷新到磁盘的位置?——不管怎么说,LSN有一种‘随时间单调变化’的性质
- 检查点:将缓冲池中的页刷新到磁盘
- sharp
- fuzzy*
- redo日志的大小是固定的(3GB)->归档日志
- ib_logfile<N>
- redo日志块(512B-12-8)
- 和磁盘扇区大小一样,保证原子性,不需要double write?
- 重做日志组*
- 组提交:fsync -> log_flush_up_to 会对最后一个日志块进行复制
- 恢复:recovery_from_checkpoint_start
- 表空间第一个页头部的FIL_PAGE_FILE_FLUSH_LSN记录了数据库关闭时最后刷新页的LSN
- recv_parse_or_apply_log_rec_body
- recv_add_to_hash_table
- recv_recover_page
- recv_read_in_area 判断页所在相邻的32个页?
mini-transaction(mtr)
- FIX rules:修改页之前需要持有该页的latch
- WAL
- 每个页需要有一个LSN?LSN溢出怎么办?
- Force-Log-at-Commit
- mtr_t mtr; mtr_start(&mtr); ... mtr_commit(&mtr);
- 提交时若mtr->modified==TRUE,先修改缓冲池中的页*1,然后释放log_sys->mutex(这是一个热点)
- *1 log_reserve_and_write_fast/log_write_slow 快速/慢速2个路径
- 更新多行记录时,MLOG_MULTI_REC_END
- 提交时若mtr->modified==TRUE,先修改缓冲池中的页*1,然后释放log_sys->mutex(这是一个热点)
存储管理
- 页:(space_id, offset) 16KB
- 1 extent = 64 连续的page
- space header
- 段(segment)
- 每张用户表至少2个段:聚集索引(B+树)的叶子节点和非叶子节点段
- 一个段最多可以管理32个独立的页,和若干区
- 表空间
- 数据结构:fil_system/space/node_struct
- 4个异步I/O线程:异步读、异步写、插入缓存、重做日志
记录
- 物理记录
- p102 用户记录的heap no总是从2开始
- 伪记录:Infimum/Supremum(感觉将像是双链表的first/last)
- p103 VARCHAR类型的NULL不占用磁盘空间,而CHAR NULL用0x00填充
- 大记录:BLOB/TEXT(溢出页,extern属性)
- p102 用户记录的heap no总是从2开始
- 逻辑记录
- dtuple_struct,对大记录是big_rec_struct
- B+树索引只定位页,页内记录需要二分扫描
- mtype/prtype
- 行记录版本(MVCC只是列?):通过隐藏的事务ID列
- read_view_struct:
- low/up_limit_id
- trx_ids, n_trx_ids
- creator
- p114 函数read_view_sees_trx_id用来判断当前事务是否可以读记录的当前版本,不是,则row_sel_build_prev_vers_for_mysql
- read_view_struct:
索引页
- Page Header
- 页内记录根据主键是逻辑顺序,不是物理顺序
- Page Directory(定位记录在页内的位置)
- slot?offset的主键逆序记录
- Page Cursor*
锁
- p136 理论上,隔离级别越低,事务请求的锁越少或保持锁的时间越短
- 幻读:谓词锁 --> key-range locking --> next/previous-key locking
- p138 意向锁:意味着事务希望在更细粒度上加锁
- InnoDB是行级锁,不会阻止全表扫描以外的请求
- lock_rec_struct = { space, page_no, n_bits }
- 所有锁对象通过kernel_mutex进行保护(又一个热点!)
- 优化:细粒度拆分?
- 所有锁对象通过kernel_mutex进行保护(又一个热点!)
- p144 LOCK_GAP(代表范围锁不包含端点)
- 显式锁和隐式锁**(略)
- 行锁的维护*(重点,略)
- 插入
- 更新
- PURGE
- 一致性的锁定读
- 页的分裂
- 页的合并
- 自增锁(atomic?)
- 死锁*
B+树索引
- 聚集 / 辅助
- 分裂操作:btr_page_split_and_insert
- 合并:btr_compress
- 查找:btr_cur_search_to_nth_level
- p203 对唯一约束的键值,需要使用模式PAGE_CUR_GE,而不是LE
- latch_mode
- cursor
- DML操作
- 乐观插入:btr_cur_optimistic_insert
- 非主键更新(主要是列的大小会不会发生变化)
- btr_cur_optimistic_update --> btr_cur_pessimistic_update(例略)
- 主键更新
- 删除
- 持久游标 btr_pcur_struct
- 自适应哈希索引*
Insert Buffer
- 将多次插入合并为一次操作(提高了非唯一约束辅助索引的插入性能)
- p237 实现最为困难的在于对死锁的处理
- 页逻辑层次划分:非IB页、IB非bitmap页、bitmap页
- p241 异步I/O线程可能引起死锁问题 --> rw_lock_x_lock_move_ownership
缓冲池
- LRU、Free和Flush链表
- 预读
- p258 随机预读
- 要满足32个页中9个已经访问过且都是活跃的才可能触发
- 线性预读*
- 逻辑预读
- p258 随机预读
- 页的刷新
- 部分写问题(?) --> double write(存在于内存的表空间,大小为2MB,这意味着最多128页/次刷新)
事务处理
- 分类:扁平、带保存点的扁平、链、嵌套、分布式
- 事务系统段*
- doublewrite段*
- undo日志存储
- 一致性的非锁定读
- p282 读取快照不需要加锁
- undo日志实现:回滚段 + undo段
- trx_undo_struct
- 一致性的非锁定读
- undo记录
- purge*
- rollback
- 7B roll_ptr隐藏列 {rseg_id(1), page_no(4), offset(2)}
- 3个回滚类型:TRX_SIG_{TOTAL_ROLLBACK, ROLLBACK_TO_SAVEPT, ERROR_OCCURRED}
- commit