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）