摘錄自 極客時間 的丁奇
有了redo log，innodb就可以保證即使資料庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。
重要的日誌模組：binlog
這兩種日誌有以下三點不同。
redo log是innodb引擎特有的；binlog是mysql的server層實現的，所有引擎都可以使用。
redo log是物理日誌，記錄的是「在某個資料頁上做了什麼修改」；binlog是邏輯日誌，記錄的是這個語句的原始邏輯，比如「給id=2這一行的c欄位加1 」。
redo log是迴圈寫的，空間固定會用完；binlog是可以追加寫入的。「追加寫」是指binlog檔案寫到一定大小後會切換到下乙個，並不會覆蓋以前的日誌。
innodb_flush_log_at_trx_commit設定成1，這樣可以保證mysql異常重啟之後資料不丟失（每次事務的redo log都直接持久化到磁碟）
sync_binlog設定成1，mysql異常重啟之後binlog不丟失（表示每次事務的binlog都持久化到磁碟）
1.最左原則
非主鍵索引的查詢需要多掃瞄一棵索引樹。因此，我們在應用中應該盡量使用主鍵查詢。
覆蓋索引可以減少樹的搜尋次數，顯著提公升查詢效能，所以使用覆蓋索引是乙個常用的效能優化手段。（不需要回表）
2.索引字段不能進行函式操作，但是索引欄位的引數可以玩函式.
例如where id+1=1000改寫成where id=1000-1就能夠用上索引快速查詢，也不會主動做這個語句重寫。
2.1案例一：條件字段函式操作
select count(*) from tradelog where month(t_modified)=7;
用這個替換
select count(*) from tradelog where
-> (t_modified >= '2016-7-1' and t_modified<'2016-8-1') or
-> (t_modified >= '2017-7-1' and t_modified<'2017-8-1') or
-> (t_modified >= '2018-7-1' and t_modified<'2018-8-1');
select * from tradelog where tradeid=110717;
對於優化器來說，這個語句相當於：
mysql> select * from tradelog where cast(tradid as signed int) = 110717;1.備庫所在機器的效能要比主庫所在的機器效能差。
當然，這種部署現在比較少了。因為主備可能發生切換，備庫隨時可能變成主庫，所以主備庫選用相同規格的機器，並且做對稱部署，是現在比較常見的情況。
2.備庫的壓力大
這種情況，我們一般可以這麼處理：
一主多從。除了備庫外，可以多接幾個從庫，讓這些從庫來分擔讀的壓力。
通過binlog輸出到外部系統，比如hadoop這類系統，讓外部系統提供統計類查詢的能力。
3.大事務
主庫上必須等事務執行完成才會寫入binlog，再傳給備庫
不要一次性地用delete語句刪除太多資料。其實，這就是乙個典型的大事務場景。
另一種典型的大事務場景，就是大表ddl，用13章的online ddl
MySQL45講學習筆記（三九）
例 table t insert into t values null,1 此時自增值為2 自增值的儲存策略 myisam 儲存於資料檔案中。innodb mysql5.7及以前會儲存於記憶體中，每次重啟開啟會去找自增列的最大值，然後將這個值 1作為當前自增值。重啟會修改表的自增值，例 假設當前表自...
實戰mysql45講 MySQL實戰45講
作者簡介 林曉斌，網名 丁奇 前阿里資深技術專家，曾負責阿里雲rds核心開發團隊和運維團隊，並推動了alisql分支開源。作為活躍的mysql社群貢獻者，丁奇專注於資料儲存系統 mysql原始碼研究和改進 mysql效能優化和功能改進，熱衷於解決mysql疑難問題。課程亮點 你將獲得 前阿里資深技術...
mysql45講 自增主鍵
使主鍵索引盡量遞增的順序，避免了頁 因此索引更緊湊。但不能保證是連續遞增的。1.myisam 引擎的自增值儲存在資料檔案中 2.innodb的自增值儲存在記憶體裡，在mysql8.0之後，將自增值的變更記錄存在了redo log中，重啟時依靠redo log恢復之前的值。當主鍵id被設為自增後，新插...