mysql log and lock

mysql bin log
==> /etc/my.cnf
==> log_bin=/var/log/mysql/mysql-bin.log
==> binlog_do_db=your_db

==> 记录所有mysql存储引擎相关的日志
==> 类型无论是STATEMENT，ROW，MIXED其记录的都是关于一个事务的具体操作内容
==> 它属于逻辑日志且只在事务提交前写入磁盘一次
==> 主要用于主从同步数据

innodb redo log
==> 默认位置为mysql的data目录（/var/lib/mysql）
==> 默认文件为ib_logfile0和ib_logfile1（采用交替写入方式进行写入）

==> 事务在进行过程中就不断有redo log写入到重做日志文件中
==> undo log作为事务的回滚处理一同包含在redo log中
==> 在掉电恢复时未执行的
==> 完整事务重新执行事务操作
==> 不完整事务重新执行事务操作同时执行undo处理
==> 从而保证了事务的原子性和持久性

==> redo log记录的是页的物理操作
==> 基本上是顺序写的，所以速度很快
==> 在数据库运行时不需要对redo log的文件进行读取操作

innodb undo log
==> 默认位置为mysql的data目录（/var/lib/mysql）
==> 默认文件为共享表空间文件ibdata1，undo log存放在其中的rollback segment回滚段中
==> 每个rollback segment可以支持1024个事务并发执行，默认有128个rollback segment回滚段

==> undo log用来保证事务的一致性
==> 在事务异常时用于回滚操作
==> undo log会记录与执行操作相反的操作
==> 同时会记录上个版本的数据信息
==> 从而实现多版本并发（MVCC）的机制

==> undo log是逻辑日志根据每行记录进行记录
==> 需要随机读写
==> 事务提交后并不能马上删除undo log及undo log所在页
==> 这是因为可能其他事务需要通过undo log来得到行记录之前的版本
==> 故事务提交时将undo log放入一个链表
==> 是否可以最终删除undo log及undo log所在页由purge线程来判断

innodb 独立表空间配置
==> /etc/my.cnf
==> innodb_file_per_table=ON
==> table.ibd 独立表空间文件仅存储该表的数据、索引和插入BITMAP等信息，其余信息还是存放在默认表空间ibdata1中

mysql lock
==> 意向共享锁可以理解为表锁，每行数据加锁前都要先加意向锁，意向锁锁定成功后才可以对相应的行加锁
==> 共享锁/排他锁为行锁，只有获取到行锁才可以对行进行相应操作

==> innodb对于行的查询使用的都是next-key lock算法，其由（GAP + Record Lock）组合而成
==> 当查询的列是唯一索引时，next-key lock算法将降级为Record Lock从而提高并发性（若索引为辅助索引则算法依然为next-key lock）