MySQL管理之道_ 性能調優、高可用與監控（第2版）-by 賀春暢-讀書筆記

MySQL管理之道_ 性能調優、高可用與監控（第2版）-讀書筆記

MariaDB架構與歷史

• MariaDB：用Percona XtraDB代替InnoDB（前者是後者的增強版，完全兼容後者）
  • 新功能：多源複製、基於表的並行複製
  • 集成更多存儲引擎：Aria（增強版MyISAM）、SphinxSE、TokuDB（可看作ARCHIVE的升級版）、Cassandra、CONNECT、SEQUENCE及Spider（分庫分表）
  • 5.5: 線程池技術，減少連接建立的開銷，適合於高併發短連接應用場景，如秒殺（？）
• 線程池、審計日誌等功能在MySQL企業版中，需要付費

MySQL 5.7與MariaDB 10.1新特性

• p14 OLTP只讀模式下，MySQL 5.7有近100w的QPS，比5.6性能高3倍；OLTP讀寫模式下，近60w TPS
  • 注：官方測試的硬件配置：E7-8890 v3（72核）、512GB內存（靠）
• 5.7 InnoDB存儲引擎的提升：
  • 更改索引名字不鎖表
  • 在線DDL修改VARCHAR屬性不鎖表（不過還是建議使用pt-online-schema-change？）
  • 支持中文全文索引
  • Buffer Pool預熱改進
  • undo log回滾日誌支持在線收縮
  • share.ibd通用表空間
  • innodb_print_all_deadlocks = 1
  • 支持InnoDB只讀事務
  • 支持InnoDB表空間數據碎片整理（Facebook contrib）
  • 支持虛擬列（函數索引）：mod_id int(11) generated always as (id % 10) virtual, 插入時使用字面量default
  • 支持一張表多個INSERT／UPDATE／DELETE觸發器
  • 引入線程池（阿里巴巴開源的druid連接池？？？）
  • 支持explain update／delete（數據更新語句裏面也可以使用join？）
  • p57 MariaDB／TokuDB：爲什麼要關閉Transparent Huge Page？？
  • 優化器改進（SQL查詢優化與編譯器後端優化技術是有共通之處的）
    • 子查詢採用半連接優化（MySQL的子查詢一向支持不好，這方面沒有Oracle做的好，應用開發人員更喜歡寫子查詢？？？）
      • update／delete仍然不行
    • 優化派生子查詢（謂詞過濾條件下推）
    • 派生表索引優化（略）
    • 優化排序limit
    • 優化IN條件表達式
    • 優化union all（不創建臨時表）
    • 支持索引下推
    • 支持Multi Range Read（MRR）優化，收集主鍵並排序，把磁盤隨機IO改成順序IO
    • 支持Batched Key Access（BKA）索引優化，同樣是把隨機磁盤IO轉換爲順序IO
    • MariaDB 10.1: 支持Hash Join索引優化（這個地方很容易讓我想起Impala裏的2種分佈式join處理了）
      • Block Nested Loop Hash
      • Block Index Hash Join Batch Key Access Hash
  • 半同步複製改進
    • 《MySQL運維內參》裏有講到，從略
  • GTID複製改進
    • p96 從庫上執行操作時，切記先關閉binlog，再執行DML／DDL
  • 5.7從庫多線程複製：基於binlog組提交（《MySQL運維內參》裏有講到，多個處於prepare的事務可同時提交，略）
  • slave支持多源（多個主庫）複製

故障診斷

• innodb_buffer_pool_size：可設置爲60%~80%的內存，甚至可將數據庫全部放入內存（要是機房突然掉電怎麼辦？）
• p107 磁盤技術：比較火的Fusion-io？？？
• p109 Linux服務器性能監控：dstat？
• p125 如果是RR默認隔離級別，建議設置binlog_format=ROW。如果是Read-Commited，則ROW與MIXED效果是一樣的（...）
• p130 誤刪除ibdata數據文件，怎麼辦？（數據庫仍然開着，不要殺死mysqld進程，文件內容可從/proc//fd恢復）
• p132 update忘加where過濾條件誤操作恢復（模擬Oracle閃回）：實質就是從binlog中解析出原來的數據，再人工undo... 矬
  • 爲什麼不能直接rollback呢？？見鬼

同步複製報錯故障處理

• p148 master上更新了一條記錄，slave上卻找不到（仍然是手工分析處理binlog，瘋了）
• slave意外宕機，可能損壞relay-log：找到binlog和POS點，重新同步（5.5 my.cnf：relay_log_recovery=1）
• ? 多臺slave上server-id重複（由於直接複製master點my.cnf到slave導致）
• 避免master上執行大事務（老生常談了）
  • 利用存儲過程，把大事務轉換爲小批量操作....
• p156 binlog_ignore_db引起的同步複製故障：使用replicate-ignore-db=代替

性能調優

• 數據類型：選擇夠用的就行
  • timestamp：默認隨行更新而更新？？？（這個特性我怎麼之前從來沒注意過？不過我之前實際項目開發也只用到4.1/5.0）
  • 5.6: year(2)自動轉換爲year(4)
  • varchar(5)升級到varchar(10)的底層磁盤存儲不變，但decimal(10,1)升級到decimal(10,2)就不行了——後者應該是底層位存儲模式不一致
• p192 5.6 online DDL
• 採用合適的鎖機制
  • 表鎖
  • 行鎖
    • p197 只有通過索引條件檢索數據，InnoDB纔會使用行鎖，否則使用表鎖
  • 頁面鎖（粒度介於前兩者之間，NDB？）
• 選擇合適的事務隔離級別
  • innodb_flush_log_at_trx_commit=0(每隔1秒刷盤)/1（每次事務提交刷盤）/2（僅刷到日誌文件）
    • p204 事務提交後，先刷binlog，再刷到redo log,... => 中間發生宕機，可導致主從數據不一致
  • p208 間隙鎖：主要是防止幻讀。RR隔離級別下，當對數據進行條件／範圍檢索時，對其範圍內也許並不存在的值加鎖。RC級別下，沒有間隙鎖。
• SQL優化與合理利用索引
  • p212 error 1093: 通過子查詢刪除已查詢的記錄會報錯，可更改子查詢引入臨時表（更像是MySQL底層實現的bug？？？）
  • p216 類似select count(*)千萬不要在主庫上執行，因爲InnoDB無表級計數器，需要全表掃描一次才能得到彙總
  • p219 避免使用having子句，用where限制記錄的數目
  • p222 聯合索引要遵循最左原則（這個太不智能了！）
  • p225 當取出數據超過全表的20%，優化器就不會使用索引了；
    • 一條SQL只能有一個索引，如果有多個，優化器選擇最優的（！）
    • order by後如果有多個字段排序，順序要一致，如果一個生序一個降序，會出現Using filesort（性能差）

備份與恢復

• p259 取代mysqldump的新工具：mydumper
• p263 熱備份與恢復
  • xtrabackuo／innobackupex（後者是前者的perl腳本封裝）

高可用MHA架構集羣管理

• MHA與MMM都是採用Perl編寫的（？）

MySQL架構演進：“一主多從、讀寫分離”

• p294 HAProxy提供了高可用、負載均衡以及基於TCP／HTTP的應用代理。
• p295 MySQL Proxy一直沒有發佈GA版本，不能用在生產系統裏？？？？
  • MaxScale的GA版本？
  • 作者這裏推薦OneProxy，但是OneProxy爲什麼不支持預編譯語句？怎麼防止SQL拼接的注入攻擊？？見鬼
    • CSDN上曾經有篇文章談到基於proxy的LB解決方案，技術核心在於SQL語句的語法解析... 另，淘寶也有過類似應用

Codership Galera Cluster集羣架構搭建與管理

• HAProxy結合Galera Cluster實現無單點秒級故障轉移*

OneProxy分庫分表的搭建與管理

• 數據訪問層TDDL／ZDAL是個什麼鬼？
• 注意：分庫分表不支持：跨庫join、分佈式事務XA、存儲過程

Lepus慢日誌分析平臺搭建與維護