日志管理篇
一、錯誤日志功能，如何配置錯誤日志，如何查看？
log_error=yes/no
查看錯誤日志里的[error]字段
二、如何配置二進制日志
server_id
log_bin
binlog_format
sync_binlog
gtid_mode
enforce_gtid_consistency
log_slave_updates
expire_logs_days
三、二進制日志如何查看事件？
show binary logs; 查看所有的binlog文件
show master status 查看當前正在使用的binlog文件
show binlog events in 'binlog號'；查看指定binlog事件、
info:具體操作
Pos：事件開始位置
End_log_pos:事件結(jié)束位置
四、二進制日志有哪些格式？有什么區(qū)別？你們公司用什么格式？？
1.statement(5.6模式) SBR(statement based replication) ：語句模式原封不動的記錄當前DML。
2. ROW(5.7 默認值) RBR(ROW based replication) ：記錄數(shù)據(jù)行的變化(用戶看不懂，需要工具分析)
3. mixed（混合）MBR(mixed based replication)模式 ：以上兩種模式的混合
STATEMENT：可讀性較高，日志量少，但是不夠嚴謹
ROW ：可讀性很低，日志量大，足夠嚴謹
我們使用的是Row模式
五、什么是雙一標準?
redo : innodb_flush_log_at_trx_commit
1: 每次事務(wù)提交都會把內(nèi)存里的數(shù)據(jù)寫入log 文件中，并且立即刷寫到磁盤。默認安全等級高模式，不容許有數(shù)據(jù)丟失，但性能會降低
0: 安全等級低，可以容忍至少1秒的數(shù)據(jù)丟失，性能高
binlog : sync_binlog
1: 每次trx提交binlog都會flush到磁盤
0: trx提交后，不控制刷寫磁盤，由文件系統(tǒng)控制刷新
六、什么是2PC？
兩階段提交協(xié)議，是整個事務(wù)流程分為兩個間斷，準備階段Prepare phase，提交階段commit phase，2是指兩個階段，P是指準備階段，C是指提交階段。
七、你是如何截取二進制日志的？傳統(tǒng)、GTID有什么不同點？
基于Position號截取日志，
mysqlbinlog --start-position=起點 --stop-position=終點 來截取。
不同點在于GTID截取日志需要include-gtids=GTID號。還可以排除不需要截取的使用--exclude-gtids.GTID的冪等性，恢復(fù)時需要加上--skip-gtids
八、如何配置慢日志？
開關(guān)
slow_query_log=1
文件位置及名字
slow_query_log_file=/data/mysql/slow.log
設(shè)置慢查詢時間
long_query_time=0.1
沒走索引的語句也記錄
log_queries_not_using_indexes
九、慢日志如何處理？慢日志在什么時候有用？
自帶mysqldumpslow 分析日志工具
第三方工具：pt-query-diagest將慢查詢可視化
SQL語句慢會記錄到慢日志中來分析
存儲引擎篇
一、mysql支持的存儲引擎類型有哪些？
show engines;查看
1.memory
2.innodb
3.pereormance_schema
4.myisam
5.mrg_mysiam
6.blackhole
7.csv
8.archive
二、innodb存儲引擎的核心特性有哪些？innodb和myisam的區(qū)別？
innodb核心特性：
事務(wù)
MVCC
行鎖
熱備
自動故障恢復(fù)
聚集索引
外鍵
區(qū)別：
myisam:
不支持事務(wù)
不支持外鍵
不支持行鎖，支持表鎖
讀操作效率高，innodb寫的效率高
都支持全文索引
表占用空間較大
非聚集索引
innodb:相反
三、TokuDB等存儲引擎相較于innodb有什么優(yōu)勢？在什么場景下應(yīng)用？
TokuDB的優(yōu)點：
1.高壓縮比，
2.高寫入的性能
3.增刪字段秒級
缺點：
1.cpu usr態(tài)消耗高，
2.響應(yīng)時間長
四、mysql的碎片是如何產(chǎn)生的？你是怎么處理的？
大批量的delete操作會產(chǎn)生碎片、
alter table 表 engine=innodb;第一次效果明顯
最好的處理方式是。邏輯導(dǎo)數(shù)據(jù)，手工truncate刪除表。再導(dǎo)入、
五、簡述物理存儲結(jié)構(gòu)？
表空間：段、區(qū)、頁
日志文件：redo.undo
臨時表：ibtmp1
六、請介紹innodb的表空間類型和作用
共享表空間：存放著系統(tǒng)的數(shù)據(jù)
獨立表空間：存放用戶數(shù)據(jù)，一個表一個ibd文件，數(shù)據(jù)行和索引信息?？梢杂脕砘謴?fù)數(shù)據(jù)、
普通表空間：一般不用
重做表空間：undo+臨時表 存儲回滾日志
七、innodb共享表空間在不同版本有什么變化？
需要將所有數(shù)據(jù)存儲到同一個表空間中 ，管理比較混亂
5.5版本出現(xiàn)的管理模式，也是默認的管理模式。
5.6版本以，共享表空間保留，只用來存儲:數(shù)據(jù)字典信息,undo,臨時表。
5.7 版本,臨時表被獨立出來了
8.0版本,undo也被獨立出去了
八、簡述表空間遷移的過程？
將A實例的表數(shù)據(jù)遷移到B上。
1.在目標實例B上創(chuàng)建此昂通的表
2.在目標庫上執(zhí)行Alter table discard tablespace;
3.在源庫a上執(zhí)行FLUSH TABLES t FOR EXPORT;生成.cfg文件
4..ibd文件和.cfg文件拷貝到目標實例b
5.在源庫a執(zhí)行unlock tables;
6.在目標庫b執(zhí)行alter table t1 import tablespace;
九、共享表空間如何擴容？
配置文件參數(shù)：
Innodb_data_file_path=xx
十、如何獨立undo表空間？
innodb_undo_directory
innodb_undo_tablespaces
innodb_undo_log_truncate
innodb_purge_rseg_truncate_frequency
十一、什么是事務(wù)的ACID特性？ACID是如何保證的？
A原子性： 通過undo redo保證
C一致性：通過redo undo mvcc 鎖保證
i隔離性：通過隔離級別、MVCC、鎖保證
D持久性：redo保證
十二、簡述事務(wù)的工作流程
1.根據(jù)sql層的處理結(jié)果，找到需要的uodate數(shù)據(jù)頁。
2.將數(shù)據(jù)頁加載IBP中
3.生成undo日志
4.undo落地
5.修改IBP數(shù)據(jù)頁
6.記錄數(shù)據(jù)頁修改redo,更新LSN
7.redo落地
8.如果此時宕機，事務(wù)未提交成功
對數(shù)據(jù)也redo lsn號，先前滾，后回滾?；謴?fù)過程被稱為故障自動恢復(fù)
十三、什么是MVCC？如何保證？
多版本并發(fā)控制
依賴于undo日志
解決讀寫事務(wù)之間不會沖突
RC：書屋開始之后，每條查詢語句讀數(shù)據(jù)時，都會獲取系統(tǒng)當前最新的快照
RR：事務(wù)開始之后，第一次在數(shù)據(jù)查詢的時候，獲取一個一次性快照read view，一直持續(xù)到事務(wù)結(jié)束
十四、請簡述CSR自動故障恢復(fù)的過程？
事務(wù)執(zhí)行中如果宕機，redo，undo中會有日志，自動前滾重做，保證故障自動恢復(fù)、
十五、什么是LSN？作用是什么？
日志序列號
磁盤數(shù)據(jù)頁,redo文件,buffer pool,redo buffer
MySQL 每次數(shù)據(jù)庫啟動,都會比較磁盤數(shù)據(jù)頁和redolog的LSN,必須要求兩者LSN一致數(shù)據(jù)庫才能正常啟動
十六、什么是WAL機制？
redo日志優(yōu)先落盤。達到數(shù)據(jù)持久化的目的。
十七、簡述Checkpoint的功能？
作用：
1、縮短數(shù)據(jù)庫的恢復(fù)時間；
2、緩沖池不夠用時，將臟頁刷新到磁盤；
3、重做日志不可用時，刷新臟頁。
刷新條件：
**1、MasterThread Checkpoint：**異步刷新，每秒或每10秒從緩沖池臟頁列表刷新一定比例的頁回磁盤。異步刷新，即此時InnoDB存儲引擎可以進行其他操作，用戶查詢線程不會受阻。
**2、****FLUSH_LRU_LIST Checkpoint：**
InnoDB存儲引擎需要保證LRU列表中差不多有N個空閑頁可供使用。
mysql5.6之后，也就是Innodb1.2.x開始，這個檢查放在了單獨的線程（Page Cleaner）中進行。
設(shè)置參數(shù)：innodb_lru_scan_dept：控制LRU列表中可用頁的數(shù)量，該值默認1024
**3、Async/Sync Flush Checkpoint：**
指重做日志不可用的情況，需要強制刷新頁回磁盤，此時的頁時臟頁列表選取的。
這種情況是保證重做日志的可用性，說白了就是，重做日志中可以循環(huán)覆蓋的部分空間太少了，換種說法，就是極短時間內(nèi)產(chǎn)生了大量的redo log。
計算公式：
寫入日志的LSN:redo_lsn
刷新回磁盤的最新頁LSN:checkpoint_lsn
定義:
checkpoint_age = redo_lsn - checkpoint_lsn
async_water_mark = 75% * total_redo_file_size
sync_water_mark = 90% * total_redo_file_size
4.Dirty Page too much Checkpoint**
即臟頁太多，強制checkpoint.保證緩沖池有足夠可用的頁。
參數(shù)設(shè)置：innodb_max_dirty_pages_pct = 75
十八、簡述MySQL的隔離級別？什么是臟讀、不可重復(fù)讀、幻讀？
RU: 讀未提交 。 臟讀，不可重復(fù)讀，幻讀。**READ_UNCOMMITTED**
RC: 讀以提交 。 不可重讀，幻讀。**READ_COMMITED**
RR: 可重復(fù)讀 。 幻讀。**REPEATABLE_READ**
SE: 可串行化 。**SERLALIZABLE** 不管多少事務(wù)，挨個運行
臟讀：臟讀就是指當一個事務(wù)正在訪問數(shù)據(jù)，并且對數(shù)據(jù)進行了修改，而這種修改還沒有提交到數(shù)據(jù)庫中，這時，另外一個事務(wù)也訪問這個數(shù)據(jù)，然后使用了這個數(shù)據(jù)。
不可重復(fù)讀：是指在一個事務(wù)內(nèi)，多次讀同一數(shù)據(jù)。在這個事務(wù)還沒有結(jié)束時，另外一個事務(wù)也訪問該同一數(shù)據(jù)
幻讀：是指當事務(wù)不是獨立執(zhí)行時發(fā)生的一種現(xiàn)象，例如第一個事務(wù)對一個表中的數(shù)據(jù)進行了修改，這種修改涉及到表中的全部數(shù)據(jù)行
十九.簡述MySQL中鎖的種類及作用？
全局鎖：對數(shù)據(jù)庫整個實例加鎖。在座全庫邏輯備份時使用
表級鎖：一種是表鎖，一種是元數(shù)據(jù)鎖。 一般不會使用。影響太大
行鎖：一張表上任何時刻只能有一個更新
死鎖：并發(fā)系統(tǒng)中不同線程出現(xiàn)循環(huán)資源依賴，設(shè)計的線程都在等特別的線程釋放時，就回導(dǎo)致這幾個線程都進入無限等待狀態(tài)
二十、簡述double write的作用？
保證數(shù)據(jù)頁的完整性。
二十一、簡述AHI(自適應(yīng)HASH)的作用？
索引的索引。快速從BP中找到索引頁。
二十二、簡述Change buffer作用？
如果目標索引列需要修改的輔助索引的數(shù)據(jù)已經(jīng)在內(nèi)存，那就直接更改。
如果不在，先將數(shù)據(jù)頁修改記錄到 change buffer中.將來數(shù)據(jù)頁被調(diào)到內(nèi)存中再一次性更新
二十三、如何監(jiān)控MySQL的鎖狀態(tài)？
show status like 'innodb_rows_lock%'
select * from information_schema.innodb_trx;
select * from sys.innodb_lock_waits;
select * from performance_schema.threads;
select * from performance_schema.events_statements_current;
select * from performance_schema.events_statements_history;
二十四、請列舉InnoDB核心參數(shù)有哪些？ 并介紹其作用?
innodb_buffer_pool_size
innodb_log_buffer_size
innodb_flush_log_at_trx_commit
innodb_flush_method
