Mysql Innodb技术内幕(1)

Mysql Innodb技术内幕(1)

同步机制
InnoDB存储引擎并没有使用操作吸引自带的mutex和rw-lock，而是自己进行了封装。并通过Spin(自旋) 以及 wait arry(等待队列）的设计来提高性能

• Innodb存储引擎的mutex对象采用test-and-set命令。当test-and-set返回1时，先进行自旋操作，**当自旋一段时间后仍然不能获得mutex的话，则将mutex放入wait array的槽中，等待被唤醒

---

重做日志 <物理逻辑日志>
重做日志（redo log）用来实现事务的持久性。

redo log 由两部分组成：一是内存中的重做日志缓冲buffer，二是重做日志文件log

InnoDB是事务的存储引擎，其通过force log at commit机制实现事务的持久性。即当事务commit（提交）时，必须先将该事务的所有日志写入到重做日志文件进行持久化。

redo log用来保证事务的持久性，undo log用于事务回滚和MVCC功能
为了确保每次日志都写入到redo log中，在每次将重做日志缓冲写入到重做日志文件后，InnoDB存储引擎都需要调用一次fsync操作。因为重做日志文件打开并没有使用O_DIRECT选项，所有重做日志先写入到文件系统缓存。

参数innodb_flush_log_at_trx_commit 用来控制重做日志刷新到磁盘的策略。

• 1表示事务提交时必须将该事务的所有日志写入到磁盘中
• 0表示事务提交时并不强制一定要写入到重做日志，这个操作仅在master thread中进行完成。而master thread中每1秒会进行一次重做日志文件的fsync操作
• 2表示事务提交时将重做日志写入到重做日志文件，但仅写入到文件系统的缓存中，不进行fsync操作

---

检查点
如果说重做日志的作用是为了在数据库宕机时完成对数据的恢复，那么检查点的作用则是缩短当数据库发生宕机时数据库恢复所需要的时间，因为检查点中保存的都是物理日志刷新到磁盘中的数据记录长度 LSN。

事务日志在提交时会确定写入到外存，但是缓冲池（buffer pool)中的页并没有刷新到磁盘中。页的刷新是异步操作，当前数据库通常使用检查点技术

---

结论：上述需要搞清楚的是 ：**物理日志（这个日志里面应该存的就是数据）**和物理逻辑日志各有优势，取长补短

Mini-Transaction

mini-transaction模块，其用来实现InnoDB存储引擎物理逻辑日志的写入，通过mini-transaction来保证并发事务操作下以及数据库异常时页中数据一致性

	mini_transaction(){
		lock the page in exclusive mode  //对该页使用独占模式
		transform the page
		generate undo and redo log record  //生成undo\redo log
		unlock the page //release the lock
	}

在InnoDB存储引擎中，每个页有一个buf_lock_t对象

	struct buf_block_struct{
		....
		rw_lock_t lock;      //这个锁保证了每个块的安全性，且是读写锁
		ulint buf_fix_count;

物理日志的逻辑实现
InnoDB存储引擎上每个log_block都有一定的说明信息

每个重做日志开头都会有标识信息：type / space / offset / body

type: 通过设置MLOG_SINGLE_REC_FLAG标识来标识该mini-transaction是否仅涉及一个页的操作
**在进行mini-transaction模块时，需要持有log_sys_mutex互斥量。因此该互斥量时一个集中热点。另外，从重做日志缓存写入到重做文件是缓存写的方式，在对重做日志做fsync操作时，就可以释放log_sys_mutex。通过该优化，提高了事务执行的效率