HA
MHA
（1）從宕機崩潰的master保存二進制日誌事件（binlog events）;
（2）識別含有最新更新的slave；
（3）應用差異的中繼日誌（relay log）到其他的slave；
（4）應用從master保存的二進制日誌事件（binlog events）；
（5）提升一個slave爲新的master；
（6）使其他的slave連接新的master進行復制；
MGR
MySQL 組複製實現了基於複製協議的多主更新(提一下和Oracle RAC的不同)
1)複製組由多個 server成員構成，並且組中的每個 server 成員可以獨立地執行事務。但所有讀寫（RW）事務只有在衝突檢測成功後纔會提交。只讀（RO）事務不需要在衝突檢測，可以立即提交。
2)換句話說，對於任何 RW 事務，提交操作並不是由始發 server 單向決定的，而是由組來決定是否提交。準確地說，在始發 server 上，當事務準備好提交時，該 server 會廣播寫入值（已改變的行）和對應的寫入集（已更新的行的唯一標識符）。然後會爲該事務建立一個全局的順序。最終，這意味着所有 server 成員以相同的順序接收同一組事務。因此，所有 server 成員以相同的順序應用相同的更改，以確保組內一致。
3)組複製使您能夠根據在一組 server 中複製系統的狀態來創建具有冗餘的容錯系統。因此，只要它不是全部或多數 server 發生故障，即使有一些 server 故障，系統仍然可用，最多隻是性能和可伸縮性降低，但它仍然可用。server 故障是孤立並且獨立的。它們由組成員服務來監控，組成員服務依賴於分佈式故障檢測系統，其能夠在任何 server 自願地或由於意外停止而離開組時發出信號。
4)他們是由一個分佈式恢復程序來確保當有 server 加入組時，它們會自動更新組信息到最新。並且多主更新確保了即使在單個服務器故障的情況下也不會阻止更新，不必進行 server故障轉移。因此，MySQL 組複製保證數據庫服務持續可用。
5)值得注意的一點是，儘管數據庫服務可用，但當有一個 server 崩潰時，連接到它的客戶端必須定向或故障轉移到不同的 server。
MySQL 組複製提供了高可用性，高彈性，可靠的 MySQL 服務。
MGR的侷限
僅支持InnoDB表，並且每張表一定要有一個主鍵，用於做write set的衝突檢測；
必須打開GTID特性，二進制日誌格式必須設置爲ROW，用於選主與write set
COMMIT可能會導致失敗，類似於快照事務隔離級別的失敗場景
目前一個MGR集羣最多支持9個節點
不支持外鍵於save point特性，無法做全局間的約束檢測與部分部分回滾
二進制日誌不支持binlog event checksum
Replication
半同步複製
AFTER_SYNC 這個即新的半同步方案，Waiting Slave dump在Storage Commit之前。
AFTER_COMMIT 老的半同步方案。
MySQL組提交(group commit)
binlog_group_commit_sync_delay
slave_parallel_workers
組提交與並行複製，減少主從延遲
GTID原理、使用GTID跳過複製錯誤
主從延時或同步終止的原因
- 大事務，binlog寫入是事務級的，有大事務存在的話會導致瞬時寫入的binlog較大，從庫的io thread壓力到導致延遲
- 網絡延時
- 主從兩臺機器的負載不一致
- 自增長鍵衝突導致主從不一致
- mysql異常宕機情況下，如果未設置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出現binlog或者relaylog文件出現損壞，導致主從不一致
- max_allowed_packet設置不一致導致延時
解決辦法
- 大事務改造，binlog寫入是事務級的，有大事務存在的話會導致瞬時寫入的binlog較大，從庫的io thread壓力到導致延遲
- 使用relay-fetch進行預熱，提高從庫應用日誌的速度
- 調整雙1，業務安全允許的情況下（半同步複製時可以考慮）
- 開啓多線程複製，show variables like '%slave_parallel%'（配合組提交，5.7）
- 調整從庫的max_allowed_packet不應小於主庫
MySQL會根據配置文件會限制server接受的數據包的大小。如果寫入大數據時，因爲默認的配置太小，插入和更新操作會因爲 max_allowed_packet 參數限制，而導致失敗。備份
xtrabackup
1.innobackupex 在啓動後，會先 fork 一個進程，啓動 xtrabackup進程，然後就等待 xtrabackup 備份完 ibd 數據文件；
2.xtrabackup 在備份 InnoDB 相關數據時，是有2種線程的，1種是 redo 拷貝線程，負責拷貝 redo 文件，1種是 ibd 拷貝線程，負責拷貝 ibd 文件；redo 拷貝線程只有一個，在 ibd 拷貝線程之前啓動，在 ibd 線程結束後結束。xtrabackup 進程開始執行後，先啓動 redo 拷貝線程，從最新的 checkpoint 點開始順序拷貝 redo 日誌；然後再啓動 ibd 數據拷貝線程，在 xtrabackup 拷貝 ibd 過程中，innobackupex 進程一直處於等待狀態（等待文件被創建）。
3.xtrabackup 拷貝完成idb後，通知 innobackupex（通過創建文件），同時自己進入等待（redo 線程仍然繼續拷貝）;
4.innobackupex 收到 xtrabackup 通知後，執行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位點，然後開始備份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷貝非 InnoDB 文件過程中，因爲數據庫處於全局只讀狀態，如果在業務的主庫備份的話，要特別小心，非 InnoDB 表（主要是MyISAM）比較多的話整庫只讀時間就會比較長，這個影響一定要評估到。
5.當 innobackupex 拷貝完所有非 InnoDB 表文件後，通知 xtrabackup（通過刪文件） ，同時自己進入等待（等待另一個文件被創建）；
6.xtrabackup 收到 innobackupex 備份完非 InnoDB 通知後，就停止 redo 拷貝線程，然後通知 innobackupex redo log 拷貝完成（通過創建文件）；
7.innobackupex 收到 redo 備份完成通知後，就開始解鎖，執行 UNLOCK TABLES；
8.最後 innobackupex 和 xtrabackup 進程各自完成收尾工作，如資源的釋放、寫備份元數據信息等，innobackupex 等待 xtrabackup 子進程結束後退出。
SQL優化
semi-join 針對insubquery，不會返回重複的記錄，遇到滿足條件的第一條記錄則返回並開始下一個條件的查詢
index condition push down
block nest loop
multi-range read 根據查詢語句中的二級索引查找到索引值後，再根據二級索引中的主鍵排序，取數時可極大的節省IO（相當於合併IO）
extra中出現using temporary表示查詢使用臨時表，需關注
extra中出現file sort 不一定使用了文本排序，也可能是在內存中排序，只是說排序操作未利用索引，需關注
利用索引組織表的特性進行SQL優化
在線DDL
5.7何時會降級爲copy的方式？
B樹和B+樹的區別
鎖
MySQL中InnoDB引擎的行鎖是通過加在什麼上完成（或稱實現）的？爲什麼是這樣子的？
Innodb的行鎖是加在索引實現的；
原因是:innodb是將primary key index和相關的行數據共同放在B+樹的葉節點；innodb一定會有一個primary key，secondary index查找的時候，也是通過找到對應的primary，再找對應的數據行；
監控
profiling分析SQL執行過程
show processlist結合awk工具實施監控
更新performance_schema 中的setup開頭的表，可以記錄更多數據庫運行信息至event表
(1)QPS(每秒Query量)
QPS = Questions(or Queries) / seconds
mysql > show global status like 'Question%';
(2)TPS(每秒事務量)
TPS = (Com_commit + Com_rollback) / seconds
mysql > show global status like 'Com_commit';
mysql > show global status like 'Com_rollback';
(3)key Buffer 命中率
mysql>show global status like 'key%';
key_buffer_read_hits = (1-key_reads / key_read_requests) 100%
key_buffer_write_hits = (1-key_writes / key_write_requests) 100%
(4)InnoDB Buffer命中率
mysql> show status like 'innodb_buffer_pool_read%';
innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%
(5)Query Cache命中率
mysql> show status like 'Qcache%';
Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;
(6)Table Cache狀態量
mysql> show global status like 'open%';
比較 open_tables 與 opend_tables 值
(7)Thread Cache 命中率
mysql> show global status like 'Thread%';
mysql> show global status like 'Connections';
Thread_cache_hits = (1 - Threads_created / connections ) * 100%
#####################################################
interactive_timeout
我們可以適當設置這個值，8小時太長了，不適用於生產環境。因爲一個連接長時間不工作，還佔用我們的連接數，會消耗我們的系統資源。
體系原理
兩階段提交，保證redo和binlog順序一致，xtrabackup有這個要求
double write
insert buffe/change buffer
刷新臨近頁
異步IO
MVCC原理闡述
行中有隱含字段 DB_TRX_ID、DB_ROLL_PTR，利用回滾段實現多版本
基本特徵
每行數據都存在一個版本，每次數據更新時都更新該版本。
修改時Copy出當前版本隨意修改，各個事務之間無干擾。
保存時比較版本號，如果成功（commit），則覆蓋原記錄；失敗則放棄copy（rollback）
InnoDB存儲引擎MVCC的實現策略
在每一行數據中額外保存兩個隱藏的列：當前行創建時的版本號和刪除時的版本號（可能爲空，其實還有一列稱爲回滾指針，用於事務回滾，不在本文範疇）。這裏的版本號並不是實際的時間值，而是系統版本號。每開始新的事務，系統版本號都會自動遞增。事務開始時刻的系統版本號會作爲事務的版本號，用來和查詢每行記錄的版本號進行比較。
每個事務又有自己的版本號，這樣事務內執行CRUD操作時，就通過版本號的比較來達到數據版本控制的目的。
分庫分表
簡單介紹下MyCat，DRDS，TDDL
分庫分表的原則是，儘量不分庫分表
講述TiDB項目經驗
全局ID
分佈式事務XA
分庫分表思路
linux調優
1.使用符號鏈接分散IO，建表時指定data directory
2.禁止操作系統更新文件的atime屬性
3.用裸設備存放innodb共享表空間（buffer pool中緩存了數據和索引，不需要文件系統緩存）
4.調整IO調度算法，mysql建議使用deadline調度算法
參數調優
innodb_flush_method=O_DIRECT
O_DIRECT相比fdatasync的優點是避免了雙緩衝，本身innodb buffer pool就是一個緩衝區，不需要再寫入到系統的buffer，但是有個缺點是由於是直接寫入到磁盤，所以相比fdatasync的順序讀寫的效率要低些。在大量隨機寫的環境中O_DIRECT要比fdatasync效率更高些，順序寫多的話，還是默認的fdatasync更高效。