高性能MySQL筆記

- - 《高性能MySQL》第1章 MySQL架構
  - - **第一章核心知識點總結**
    - **多選題**
    - 多選題答案
    - **答案與詳解總結**
  - 《高性能MySQL》第2章可靠性程世界中的監控
  - - 核心知識點
    - 多選題
    - 答案及解析
    - 重點鞏固方向
  - 《高性能MySQL》第3章 Performance Schema
  - - **第三章核心知識點總結**
    - **多選題**
    - 答案
    - **答案與詳解總結**
  - 《高性能MySQL》第4章操作系統和硬件優化
  - - **重難點解析**
    - **多選題**
    - 答案
    - **答案與詳解總結**
  - 《高性能MySQL》第5章優化服務器設置
  - - 多選題
    - 答案
  - 《高性能MySQL》第6章 schema設計與管理
  - - **第六章核心知識點**
    - **多選題**
    - **答案與詳解總結**
  - 《高性能MySQL》第7章創建性能的索引
  - - **第七章核心重難點總結**
    - **多選題**
    - 答案
  - 《高性能MySQL》第8章查詢性能優化
  - - **多選題**
    - 答案與解析
    - 重難點總結
  - 《高性能MySQL》第9章復制
  - - **第九章核心知識點總結**
    - 多選題
    - 答案與詳解匯總
  - 《高性能MySQL》第10章備份與恢復
  - - 多選題
    - 答案與解析
  - 《高性能MySQL》第11章擴展MySQL
  - - **答案與解析**
  - 《高性能MySQL》第12章云端的MySQL
  - - **重點內容**
    - **難點內容**
    - **10道Hard難度多選題**
    - **答案與詳解**
  - 《高性能MySQL》第13章 MySQL的合規性
  - - 章節重點內容
    - 多選題（答案及解析見最后）
    - 答案與解析

用于測試復習

《高性能MySQL》第1章 MySQL架構

第一章核心知識點總結

MySQL邏輯架構
- 分層結構：連接層、服務層、存儲引擎層
- 核心組件：查詢解析、優化器、存儲引擎API
- 存儲引擎差異（如InnoDB vs MyISAM）
事務與鎖機制
- ACID特性與隔離級別
- 鎖類型：表鎖、行鎖、間隙鎖（Next-Key Locking）
- MVCC（多版本并發控制）實現原理
復制與高可用
- 異步復制、半同步復制、全同步復制
- GTID（全局事務標識符）與Binlog日志格式
- 主從延遲與故障切換策略
數據文件與存儲引擎
- InnoDB表空間（System Tablespace、File-Per-Table）
- Redo Log與Undo Log的作用
- JSON數據類型的原生支持
性能與擴展性
- 線程池（Thread Pool）與連接管理
- 元數據鎖（Metadata Locks）與隱式提交
- 原子DDL（Atomic DDL）特性

多選題

1. 關于MySQL事務隔離級別，以下哪些描述正確？
A. READ UNCOMMITTED允許臟讀
B. REPEATABLE READ通過間隙鎖防止幻讀
C. SERIALIZABLE通過鎖住所有讀取行實現可串行化
D. READ COMMITTED在InnoDB中通過MVCC解決不可重復讀

2. InnoDB存儲引擎的鎖機制包含哪些特性？
A. 行級鎖（Row-Level Locking）
B. 表級鎖（Table-Level Locking）
C. 間隙鎖（Gap Locking）
D. 自適應哈希索引鎖（Adaptive Hash Locking）

3. MySQL復制中，以下哪些情況會導致主從數據不一致？
A. 主庫執行非事務性表（如MyISAM）的寫操作
B. 從庫未啟用read_only模式
C. 使用STATEMENT格式Binlog且存在UDF
D. 主從服務器系統時間不一致

4. 關于InnoDB的MVCC，以下哪些說法正確？
A. 每個事務可見的版本由Read View決定
B. 刪除操作通過標記刪除而非物理刪除
C. 更新操作會生成新版本記錄
D. MVCC僅適用于SELECT查詢

5. MySQL中哪些操作會導致隱式提交？
A. 執行ALTER TABLE
B. 啟動事務（START TRANSACTION）
C. 執行LOCK TABLES
D. 設置SET AUTOCOMMIT=0

6. InnoDB的Redo Log和Undo Log分別用于什么場景？
A. Redo Log用于崩潰恢復
B. Undo Log用于事務回滾
C. Redo Log用于事務持久化
D. Undo Log用于MVCC版本管理

7. 關于MySQL的復制拓撲，以下哪些設計不合理？
A. 主庫（Master）與從庫（Slave）使用不同Binlog格式
B. 主庫配置log_slave_updates以支持鏈式復制
C. 從庫開啟read_only但允許SUPER權限用戶寫入
D. 使用多源復制（Multi-Source Replication）合并多個數據源

8. InnoDB的原子DDL特性包含哪些？
A. DDL操作自動提交
B. DDL操作支持回滾
C. DDL操作生成Binlog事件
D. DDL操作期間禁止并發DML

9. 關于MySQL的JSON數據類型，以下哪些操作高效？
A. 直接查詢JSON字段的路徑（如col->"$.key"）
B. 為JSON字段創建全文索引
C. 提取JSON字段值創建虛擬列并索引
D. 存儲大體積JSON文檔（>1MB）

10. MySQL線程池（Thread Pool）的作用包括哪些？
A. 減少線程創建/銷毀的開銷
B. 控制并發連接數
C. 避免鎖競爭
D. 自動優化慢查詢

多選題答案

答案：A、B、C
詳解：

READ UNCOMMITTED允許事務讀取未提交數據（臟讀）。
REPEATABLE READ通過間隙鎖（Gap Lock）阻止幻讀，但需結合MVCC實現。
SERIALIZABLE對所有讀取行加鎖，強制串行執行。
READ COMMITTED在InnoDB中通過快照讀（Snapshot Read）解決不可重復讀，而非MVCC（MVCC僅在REPEATABLE READ及以上生效）。

答案：A、B、C
詳解：

InnoDB支持行級鎖（通過索引實現）和表級鎖（如LOCK TABLES）。
間隙鎖用于防止幻讀，適用于REPEATABLE READ隔離級別。
自適應哈希索引是優化查詢的輔助結構，非鎖機制。

答案：A、B、C
詳解：

非事務性表的寫操作無法回滾，導致主從不一致。
從庫未啟用read_only可能導致應用直接寫入，破壞復制。
STATEMENT格式Binlog在UDF（用戶自定義函數）中可能因執行環境差異導致不一致。
系統時間不一致不影響數據邏輯一致性，但可能影響Binlog時間戳。

答案：A、B、C
詳解：

MVCC通過Read View控制事務可見性，確保隔離性。
刪除操作標記為刪除（deleted_flag），實際清理由Purge線程完成。
更新操作生成新版本記錄，舊版本保留在Undo Log中。
MVCC也影響INSERT和UPDATE的并發控制。

5.答案：A、B、C
詳解：

DDL操作（如ALTER TABLE）隱式提交當前事務。
START TRANSACTION隱式提交未提交的事務。
LOCK TABLES隱式提交并鎖定表。
SET AUTOCOMMIT=0僅關閉自動提交，不提交事務。

答案：A、B、C、D
詳解：

Redo Log記錄數據頁變更，用于崩潰恢復（Write-Ahead Logging）。
Undo Log保存舊版本數據，用于事務回滾和MVCC。
Redo Log確保事務持久化，Undo Log支持一致性讀。

答案：A、C
詳解：

主從Binlog格式需一致（如ROW或STATEMENT），否則復制可能失敗。
從庫開啟read_only后，SUPER權限用戶仍可寫入，需額外限制。
鏈式復制（B）和多源復制（D）是合理設計。

答案：B、C
詳解：

原子DDL通過Undo Log實現回滾（如中途失敗可恢復）。
DDL操作生成Binlog事件，確保主從一致性。
DDL自動提交（A）正確，但非原子性特性；DDL期間允許并發DML（D）錯誤。

答案：C
詳解：

直接查詢JSON路徑（A）效率較低，需遍歷文檔。
MySQL不支持JSON字段的全文索引（B）。
虛擬列索引（C）可將JSON字段高效索引化。
大體積JSON（D）會占用過多存儲，影響性能。

答案：A、B
詳解：

線程池復用線程，減少創建/銷毀開銷（A）。
通過隊列管理連接，控制并發數（B）。
線程池不直接解決鎖競爭（C）或優化慢查詢（D）。

答案與詳解總結

事務隔離級別：AC（理解不同隔離級別的鎖機制與實現原理）
InnoDB鎖機制：ABC（區分行鎖、表鎖、間隙鎖的作用場景）
復制一致性：ABC（關注Binlog格式與數據類型兼容性）
MVCC核心：ABC（掌握Read View與Undo Log的協作機制）
隱式提交：ABC（區分DDL與事務控制語句的影響）
Redo/Undo Log：ABCD（理解WAL機制與版本管理的關系）
復制拓撲：AC（避免主從配置不一致與權限漏洞）
原子DDL：BC（利用Undo Log實現回滾與Binlog持久化）
JSON優化：C（虛擬列索引是高效查詢的關鍵）
線程池：AB（平衡連接效率與資源管理）

學習建議：結合MySQL官方文檔與Percona Toolkit工具驗證配置，通過Percona XtraBackup實踐原子DDL與備份恢復流程。

《高性能MySQL》第2章可靠性程世界中的監控

核心知識點

服務級別指標（SLI）與服務級別目標（SLO）的定義與區別
客戶體驗監控的三個核心維度（可用性、延遲、錯誤）
主動監控與被動監控的差異
復制延遲對業務的影響及監控策略
長期性能度量與業務節奏的關系
連接風暴與線程管理的監控要點
磁盤I/O性能的關鍵指標
錯誤類型的優先級分類
內存使用率的預測性監控
備份恢復時間的容量規劃

多選題

關于服務級別指標（SLI）和服務級別目標（SLO），哪些說法正確？
A. SLI是衡量客戶是否滿意的具體指標
B. SLO必須包含具體時間范圍和數值目標
C. SLA是業務部門與客戶簽訂的包含SLO的協議
D. 99.9%的可用性意味著每年允許8小時停機
以下哪些屬于主動監控的關鍵指標？（多選）
A. 磁盤空間使用率增長率
B. 當前活躍數據庫連接數
C. 線程池中等待的查詢數量
D. 復制延遲趨勢分析
關于復制延遲監控，正確的描述是？
A. 只影響從副本讀取的業務場景
B. 是判斷是否需要分片的重要前兆
C. 主節點寫入性能不足的直接表現
D. 必須立即觸發隨叫隨到告警
以下哪些錯誤類型需要立即處理？（多選）
A. “Too many connections”
B. "Aborted connections"突然激增
C. "Lock wait timeout"偶發出現
D. 副本節點處于只讀模式
關于長期性能度量，正確的策略包括：
A. 使用平均值評估季度趨勢
B. 關注95%分位的查詢延遲
C. 分析業務高峰期流量模式
D. 完全依賴工具自動優化
內存監控的要點包含：
A. 監控memory_summary_by_thread_by_event_name
B. 通過swap分區使用率判斷內存壓力
C. 使用thread_cache_size限制內存泄漏
D. 關注memory_global_total的波動
關于連接風暴的特征，正確的描述是：
A. threads_connected與max_connections比值突增
B. 通常伴隨CPU利用率驟降
C. pt-kill工具可快速緩解
D. 必須立即重啟MySQL實例
磁盤I/O性能的關鍵指標包括：
A. iostat輸出的%util列
B. vmstat的si/so列
C. iowait時間占比超過30%
D. RAID控制器的緩存命中率
關于錯誤監控的陷阱，正確的有：
A. 所有ER_DEPRECATED錯誤都應立即修復
B. "Got error 28 from storage engine"需優先處理
C. 客戶端重試可解決所有"Lost connection"錯誤
D. 監控Connection_errors_peer_reset指標
備份恢復時間規劃需要考慮：
A. 數據集的功能分片可行性
B. 冷備份的存儲介質吞吐量
C. binlog日志的保留周期
D. 云存儲API的調用延遲

答案及解析

正確答案：A,B,C
解析：

D錯誤，99.9%可用性對應年停機時間為8.76小時（計算方式：365×24×0.1%）。
SLO必須明確時間范圍和數值（如"月度99.5%請求延遲<200ms"），SLA是包含SLO的正式協議。

正確答案：A,D
解析：

B和C屬于被動監控當前狀態，A（空間增長預測）和D（長期趨勢）屬于主動預防。

正確答案：B
解析：

A錯誤，主從數據不一致可能影響寫后讀一致性；C錯誤可能由網絡問題導致；D需根據業務影響決定告警級別。

正確答案：A,D
解析：

B可能是網絡問題，C可能暫時可容忍，D表明拓撲異常需要立即處理。

正確答案：B,C
解析：

A平均值可能掩蓋異常值，D自動優化無法替代人工分析業務模式。

正確答案：A,D
解析：

B swap使用反映OS內存管理，C thread_cache_size控制線程復用。

正確答案：A,C
解析：

B錯誤風暴伴隨CPU飆升，D重啟是最后手段。

正確答案：A,C
解析：

B監控swap，D RAID緩存需結合BBU狀態判斷。

正確答案：B,D
解析：

A舊版本兼容錯誤可能暫緩，C網絡故障需基礎設施排查。

正確答案：A,B,D
解析：

C影響時間點恢復，與全量恢復無關。

重點鞏固方向

SLI/SLO設計：掌握3個9/4個9的可用性計算（年停機時間=8760×(1-可用性百分比)）
監控分層：區分被動監控（Threads_running）和主動監控（磁盤增長率）
故障樹分析：例如Aborted connections激增可能指向網絡層問題而非DB本身
容量預測：通過(當前數據量 × 日增量 × 冗余系數) / 磁盤寫入速度計算備份窗口
指標關聯性：iowait高+%util>70%可能預示HDD陣列性能瓶頸，SSD則需要看queue_depth

《高性能MySQL》第3章 Performance Schema

第三章核心知識點總結

Performance Schema架構
- 插樁（Instrument）與消費者表（Consumer）的核心作用
- 線程（Thread）與Actor的管理機制
- 內存存儲與動態配置特性
關鍵組件與功能
- Events_ 表*：記錄等待、語句、階段、事務等事件
- Summary表：聚合分析（如內存使用、鎖爭用）
- Metadata Locks監控：解決DDL阻塞問題
高級用法
- 與sys Schema的聯動（如sys.ps_check_lost_instrumentation）
- 跟蹤內存分配與變量狀態
- 定位慢查詢與鎖沖突
性能與限制
- 插樁對CPU的額外開銷
- 內存表自動擴容與數據保留策略
- 不支持某些存儲引擎（如MyISAM）的監控

多選題

1. 關于Performance Schema的插樁（Instrument），哪些說法正確？
A. 插樁粒度可細化到SQL語句、鎖等待、內存分配等
B. 默認啟用所有插樁以覆蓋所有監控場景
C. 可通過setup_instruments表動態啟用/禁用特定插樁
D. 插樁啟用后，數據會永久存儲在磁盤上

2. 如何通過Performance Schema診斷鎖爭用問題？
A. 查看metadata_locks表中的鎖等待事件
B. 分析events_statements_summary_by_digest中的慢查詢
C. 檢查innodb_lock_wait_timeout變量值
D. 監控events_waits_current表中的wait/io/lock事件

3. Performance Schema的內存管理特性包括哪些？
A. 自動調整消費者表大小（如events_statements_history）
B. 通過performance_schema_max_*變量限制總內存占用
C. 支持將數據持久化到磁盤避免重啟丟失
D. 內存分配粒度可細化到單個線程

4. 如何通過Performance Schema檢測內存泄漏？
A. 監控memory_summary_by_thread_by_event_name表的CURRENT_ALLOC列
B. 檢查SHOW GLOBAL STATUS LIKE 'Memory_used'的變化趨勢
C. 啟用performance_schema.memory插樁并分析memory_events表
D. 通過information_schema.TABLES查看DATA_FREE值

5. Performance Schema中哪些表可用于分析慢查詢？
A. events_statements_history_long
B. statements_with_runtimes_in_95th_percentile（sys Schema視圖）
C. events_waits_current
D. file_summary_by_instance

6. 如何通過Performance Schema定位高CPU消耗的查詢？
A. 分析events_statements_summary_by_digest中的SUM_TIMER_WAIT
B. 檢查threads表中PROCESSLIST_ID對應的CPU使用率
C. 監控sys.processlist中的Time列
D. 查看events_stages_history中的STAGE_DURATION

7. Performance Schema中哪些配置會影響內存使用？
A. performance_schema_events_statements_history_size
B. performance_schema_max_table_instances
C. innodb_buffer_pool_size
D. max_connections

8. 如何通過Performance Schema檢測未提交的事務？
A. 查詢data_locks表中LOCK_STATUS = 'GRANTED'的記錄
B. 分析events_transactions_current表中的STATE列
C. 檢查INNODB_TRX表（InnoDB引擎）
D. 監控performance_schema.metadata_locks表

9. Performance Schema中哪些功能需要額外配置才能生效？
A. 跟蹤存儲過程執行
B. 記錄JSON操作
C. 監控臨時表使用
D. 自動檢測死鎖

10. 如何通過Performance Schema優化慢查詢的索引使用？
A. 分析events_statements_summary_by_digest中的FULL_SCAN次數
B. 檢查filesort_summary_by_index_usage表的INDEX_NAME列
C. 監控events_waits_history中的TABLE_IO_WAITS事件
D. 使用sys.schema_unused_indexes視圖

答案

答案：A, C
詳解：

A：正確。Performance Schema支持細粒度插樁，例如statement/sql/select（SQL語句）、wait/io/file/sql/binlog（Binlog寫入）等。
C：正確。可通過UPDATE setup_instruments SET ENABLED = 'YES'動態啟用插樁，無需重啟MySQL。
B：錯誤。默認僅啟用部分核心插樁（如statement、wait），需手動配置其他插樁。
D：錯誤。Performance Schema數據存儲在內存中，重啟后數據丟失。

答案：A, D
詳解：

A：正確。metadata_locks表記錄元數據鎖的持有者與等待者，可定位DDL阻塞問題。
D：正確。events_waits_current表中OBJECT_TYPE = 'LOCK'的記錄可直接反映鎖競爭。
B：錯誤。events_statements_summary_by_digest用于分析慢查詢，但無法直接定位鎖爭用。
C：錯誤。innodb_lock_wait_timeout是InnoDB事務鎖的超時參數，與Performance Schema無關。

答案：A, B, D
詳解：

A：正確。例如events_statements_history表默認保留每線程最近10條事件，自動擴容。
B：正確。可通過performance_schema_max_table_instances等變量限制表實例數量。
C：錯誤。Performance Schema數據不持久化，重啟后清空。
D：正確。每個線程的內存數據獨立存儲，避免跨線程干擾。

答案：A, C
詳解：

A：正確。memory_summary_by_thread_by_event_name可按線程和事件類型統計內存分配。
C：正確。啟用memory插樁后，memory_events表記錄內存分配與釋放事件。
B：錯誤。SHOW GLOBAL STATUS中的內存指標不精確，且不關聯具體事件。
D：錯誤。DATA_FREE反映表碎片，與內存無關。

答案：A, B
詳解：

A：正確。events_statements_history_long存儲所有線程的慢查詢事件（默認保留10,000條）。
B：正確。sys Schema的statements_with_runtimes_in_95th_percentile視圖直接展示慢查詢。
C：錯誤。events_waits_current記錄等待事件（如鎖、I/O），非直接查詢性能。
D：錯誤。file_summary_by_instance分析文件I/O性能，與查詢無關。

答案：A, B
詳解：

A：正確。events_statements_summary_by_digest的SUM_TIMER_WAIT字段可量化查詢耗時。
B：正確。通過threads表關聯PROCESSLIST_ID，可定位高CPU線程的執行階段。
C：錯誤。sys.processlist依賴Performance Schema數據，但無法直接關聯CPU消耗。
D：錯誤。events_stages_history記錄查詢階段（如排序、臨時表），非直接CPU指標。

答案：A, B
詳解：

A：正確。控制每個線程保存的歷史事件數量，值越大內存占用越高。
B：正確。限制Performance Schema表的最大實例數，防止內存耗盡。
C：錯誤。InnoDB緩沖池與Performance Schema無關。
D：錯誤。max_connections影響線程池資源，但非直接內存配置。

答案：B, C
詳解：

B：正確。events_transactions_current中STATE = 'ACTIVE'表示未提交事務。
C：正確。INNODB_TRX表（需啟用InnoDB監控）直接顯示未提交事務詳情。
A：錯誤。data_locks表記錄鎖沖突，無法直接關聯事務狀態。
D：錯誤。metadata_locks表監控元數據鎖，非事務鎖。

答案：A, B
詳解：

A：正確。需啟用statement/procedure/*插樁才能跟蹤存儲過程。
B：正確。需啟用wait/lock/json/*插樁才能監控JSON操作。
C：錯誤。臨時表監控默認啟用，無需額外配置。
D：錯誤。死鎖檢測由InnoDB自動完成，與Performance Schema無關。

答案：A, B, D
詳解：

A：正確。FULL_SCAN次數高表明需添加索引避免全表掃描。
B：正確。filesort_summary_by_index_usage顯示排序操作是否利用索引。
D：正確。schema_unused_indexes列出未使用的索引，可優化冗余索引。
C：錯誤。TABLE_IO_WAITS反映I/O等待，非直接索引優化依據。

答案與詳解總結

插樁與消費者表：動態配置、細粒度監控
鎖爭用診斷：元數據鎖表、等待事件表
內存管理：自動擴容、線程隔離、配置限制
慢查詢分析：摘要表、sys視圖、執行階段跟蹤
索引優化：全表掃描檢測、排序索引利用率、冗余索引識別

通過以上題目，可深入理解Performance Schema的核心機制與實戰應用。

《高性能MySQL》第4章操作系統和硬件優化

第四章聚焦于操作系統和硬件優化，核心是通過底層系統調優提升MySQL性能。以下是重難點提煉及10道高難度多選題：

重難點解析

硬件選型
- CPU：多核高頻CPU更適合高并發場景，NUMA架構需合理配置內存分配策略
- 存儲：SSD（NVMe）是主流選擇，HDD僅適用于冷數據或超大容量場景
- 網絡：萬兆網卡+RDMA技術可降低延遲
文件系統優化
- XFS：支持大文件、高吞吐，推薦用于MySQL數據目錄（innodb_file_per_table開啟時）
- EXT4：適合小規模數據，但存在元數據鎖競爭問題
RAID配置
- RAID 10：讀寫性能均衡，適合寫密集型場景
- RAID 5/6：存儲效率高，但寫懲罰顯著（需計算奇偶校驗）
- RAID控制器緩存：必須啟用BBU電池保護，否則禁用寫緩存
操作系統調優
- I/O調度器：數據庫推薦noop或deadline（SSD用noop，HDD用deadline）
- 內存管理：vm.swappiness=0禁用交換分區，避免性能抖動
- 大頁面（HugePages）：減少TLB miss，需結合innodb_large_prefix使用
性能監控工具
- iostat -x 1：監控磁盤IOPS、吞吐量和飽和度
- pidstat -d 1：跟蹤進程級磁盤I/O行為

多選題

1. 關于RAID配置的選擇，以下哪些說法正確？
A. RAID 5適合寫密集型業務
B. RAID 10的重建速度比RAID 5快
C. RAID 0提供冗余能力
D. RAID控制器緩存需搭配電池保護

2. MySQL數據目錄掛載XFS文件系統的優勢包括？
A. 支持大文件（>16TB）
B. 減少元數據鎖競爭
C. 自動優化SSD磨損均衡
D. 兼容EXT4工具鏈

3. 以下I/O調度器配置適用于SSD的是？
A. noop
B. deadline
C. cfq
D. kyber

4. 關于內存管理參數vm.swappiness，正確的說法是？
A. 值越大越傾向于使用物理內存
B. 設置為0可完全禁用交換分區
C. MySQL建議設置為10-20
D. 默認值60適合數據庫服務器

5. 以下哪些硬件特性對MySQL性能影響顯著？
A. CPU多核與超線程
B. 內存通道數
C. 磁盤轉速（RPM）
D. 網卡多隊列

6. NUMA架構下MySQL優化的關鍵點包括？
A. 綁定MySQL進程到單一NUMA節點
B. 開啟innodb_numa_interleave
C. 禁用透明大頁面（Transparent Huge Pages）
D. 增加innodb_buffer_pool_instances

7. RAID緩存策略中，以下哪些描述正確？
A. write-back模式需電池保護
B. write-through模式無寫懲罰
C. RAID 5的write-back性能優于write-through
D. 控制器緩存大小應設置為內存的10%-20%

8. 監控磁盤I/O性能時，需關注哪些指標？
A. iops
B. await（平均等待時間）
C. %util（利用率）
D. svctm（服務時間）

9. 以下關于大頁面（HugePages）的配置，正確的是？
A. 需在BIOS中啟用內存頁大小設置
B. MySQL參數innodb_large_pages=ON
C. 大頁面大小通常為2MB或1GB
D. 與innodb_buffer_pool_size無關

10. 優化操作系統TCP/IP棧時，哪些參數需調整？
A. net.core.somaxconn
B. tcp_tw_reuse
C. tcp_max_syn_backlog
D. fs.file-max

答案

答案：B, D
解析：

RAID 5的寫懲罰高（需計算奇偶校驗），僅適合讀密集型場景（A錯）
RAID 10重建僅需復制存活磁盤數據，RAID 5需重建校驗塊（B對）
RAID 0無冗余（C錯）
RAID控制器緩存需電池保護防止斷電數據丟失（D對）

答案：A, B, D
解析：

XFS支持最大16EB文件（A對）
XFS采用分配組設計，減少元數據鎖競爭（B對）
SSD磨損均衡需通過discard或fstrim手動觸發（C錯）
XFS兼容EXT4工具（如mkfs.xfs與mkfs.ext4語法相似）（D對）

答案：A, D
解析：

noop直接將I/O請求傳遞給驅動，適合SSD（A對）
kyber是Linux 5.0+的SSD優化調度器（D對）
deadline適合HDD（B錯）
cfq已廢棄（C錯）

答案：C
解析：

swappiness=0表示盡可能不交換（非完全禁用）（B錯）
MySQL推薦swappiness=1（D錯），但部分場景可設為10-20（C對）
值越大越傾向交換（A錯）

答案：A, B, C, D
解析：

多核CPU提升并行處理能力（A對）
內存通道數影響帶寬（如DDR4 4通道）（B對）
高轉速HDD（15k RPM）降低隨機I/O延遲（C對）
網卡多隊列（RSS）提升網絡吞吐（D對）

答案：A, B, C
解析：

NUMA綁核避免跨節點內存訪問延遲（A對）
innodb_numa_interleave強制內存交錯分配（B對）
THP（Transparent Huge Pages）會導致內存碎片（C對）
innodb_buffer_pool_instances與NUMA無關（D錯）

答案：A, C
解析：

write-back依賴緩存加速，需電池防斷電（A對）
write-through無緩存，寫性能低（B錯）
RAID 5的write-back通過緩存合并寫操作提升性能（C對）
緩存大小通常為硬盤容量的1%-2%（D錯）

答案：A, B, C, D
解析：

iops反映I/O吞吐能力
await體現響應延遲
%util接近100%表示飽和
svctm顯示單次I/O處理時間

答案：A, B, C
解析：

BIOS需支持并啟用大頁面（A對）
MySQL需顯式開啟innodb_large_pages（B對）
大頁面常見大小為2MB（C對）
innodb_buffer_pool_size需大于大頁面最小值（D錯）

答案：A, B, C, D
解析：

somaxconn限制監聽隊列長度（A對）
tcp_tw_reuse允許復用TIME_WAIT連接（B對）
tcp_max_syn_backlog增大SYN隊列（C對）
fs.file-max提升文件描述符上限（D對）

答案與詳解總結

RAID配置：B, D
XFS優勢：A, B, D
SSD調度器：A, D
內存管理：C
硬件特性：A, B, C, D
NUMA優化：A, B, C
RAID緩存：A, C
I/O監控：A, B, C, D
大頁面：A, B, C
TCP參數：A, B, C, D

通過底層系統調優，可顯著提升MySQL在高并發、大數據量場景下的穩定性與性能。

《高性能MySQL》第5章優化服務器設置

第五章聚焦 MySQL服務器配置優化，涵蓋從基礎參數調優到高級InnoDB設置的全方位策略。核心重難點包括：

內存管理
- InnoDB緩沖池（innodb_buffer_pool_size）的合理分配
- 線程緩存（thread_cache_size）與連接管理
- 操作系統緩存與MySQL緩存的協同
I/O優化
- 日志文件大小（innodb_log_file_size）與寫入性能
- 事務日志刷新策略（innodb_flush_log_at_trx_commit）
- 磁盤調度器與RAID配置
并發控制
- 線程并發度（innodb_thread_concurrency）
- 鎖機制與死鎖處理
- 并行復制（多線程復制）配置
安全與可靠性
- 最大連接數（max_connections）與資源限制
- 安全參數（max_connect_errors、sql_mode）
- 備份與恢復策略
高級InnoDB特性
- 自適應哈希索引（innodb_adaptive_hash_index）
- 嚴格模式（innodb_strict_mode）
- 文件格式與頁大小配置

多選題

關于InnoDB緩沖池（innodb_buffer_pool_size）的配置，以下哪些說法正確？
A. 應設置為服務器物理內存的50%-75%
B. 大小會影響數據頁的緩存效率
C. 修改后需重啟MySQL生效
D. 可動態調整無需重啟

以下哪些參數與MySQL事務日志（redo log）相關？
A. innodb_log_file_size
B. innodb_flush_log_at_trx_commit
C. sync_binlog
D. max_connections

以下哪些場景適合使用innodb_file_per_table？
A. 需要頻繁刪除大表釋放空間
B. 需要跨表空間優化存儲
C. 需要減少文件系統碎片
D. 需要提升備份效率

關于線程緩存（thread_cache_size），以下哪些描述正確？
A. 默認值通常足夠，無需調整
B. 緩存空閑線程以加速新連接
C. 過大可能導致內存浪費
D. 僅適用于短連接場景

以下哪些參數會影響MySQL的I/O性能？
A. innodb_flush_method
B. innodb_io_capacity
C. innodb_read_io_threads
D. max_connections

以下哪些是MySQL安全加固的推薦配置？
A. 設置max_connect_errors=1000
B. 禁用local_infile
C. 啟用sql_mode=STRICT_TRANS_TABLES
D. 設置skip_networking

關于InnoDB的鎖機制，以下哪些說法正確？
A. 行級鎖通過索引實現
B. 共享鎖（S鎖）允許并發讀取
C. 意向鎖用于表級鎖定
D. 死鎖檢測默認關閉

以下哪些配置會影響MySQL的復制延遲？
A. binlog_group_commit_sync_delay
B. innodb_flush_log_at_trx_commit=2
C. slave_parallel_workers=4
D. max_connections=1000

以下哪些場景適合使用pt-online-schema-change工具？
A. 修改大表的索引
B. 添加全文索引
C. 在線變更主鍵
D. 刪除無用列

關于MySQL內存分配，以下哪些說法正確？
A. innodb_buffer_pool_size應盡可能大
B. key_buffer_size對InnoDB無效
C. sort_buffer_size建議設置為16MB
D. read_rnd_buffer_size影響排序性能

答案

答案：A、B、C

詳解：

A：InnoDB緩沖池是MySQL內存占用最高的組件，通常建議占服務器內存的50%-75%（需扣除操作系統和其他應用內存）。
B：緩沖池緩存數據和索引頁，大小直接影響緩存命中率，進而影響查詢性能。
C：緩沖池大小需在MySQL啟動時通過配置文件設置，修改后需重啟生效。
D：錯誤，動態調整需使用SET GLOBAL，但重啟后仍會失效。

答案：A、B

詳解：

A：innodb_log_file_size控制單個日志文件大小，影響寫入性能和恢復時間。
B：innodb_flush_log_at_trx_commit決定事務日志的刷新策略（0/1/2），影響數據持久性與性能。
C：sync_binlog控制二進制日志的同步頻率，與事務日志無關。
D：max_connections限制最大連接數，與日志無關。

答案：A、B、C

詳解：

A：啟用后每個表獨立存儲，刪除表時可直接刪除.ibd文件，釋放空間。
B：不同表可存儲在不同目錄或存儲設備，優化I/O分布。
C：減少單個大文件的碎片問題，提升存儲效率。
D：錯誤，備份效率通常與表空間無關，取決于備份工具。

答案：B、C

詳解：

B：線程緩存保存空閑線程，減少創建新線程的開銷，提升連接效率。
C：若設置過大（如數萬），可能占用過多內存，尤其在內存有限的服務器中。
A：錯誤，默認值（如80）可能不足，需根據連接負載調整。
D：錯誤，長連接同樣受益于線程緩存，減少頻繁創建線程的開銷。

答案：A、B、C

詳解：

A：innodb_flush_method控制數據文件與日志的寫入方式（如O_DIRECT），影響I/O效率。
B：innodb_io_capacity指定InnoDB的I/O吞吐量上限，需與硬件匹配。
C：innodb_read_io_threads和innodb_write_io_threads控制讀寫線程數，影響并發I/O能力。
D：max_connections限制連接數，與I/O無直接關系。

答案：B、C

詳解：

B：禁用local_infile防止通過LOAD DATA INFILE注入攻擊。
C：STRICT_TRANS_TABLES模式嚴格檢查數據合法性，避免無效數據寫入。
A：max_connect_errors默認100較小，但設置為1000可能掩蓋惡意攻擊，需謹慎。
D：skip_networking禁用TCP/IP連接，僅允許本地Socket連接，但可能影響遠程管理。

答案：A、B、C

詳解：

A：InnoDB行鎖通過索引記錄實現，無索引可能導致表鎖。
B：共享鎖（S鎖）允許多個事務讀取同一行。
C：意向鎖（如IS鎖）用于表級鎖定，表示事務即將獲取行級鎖。
D：錯誤，InnoDB默認啟用死鎖檢測，超時后主動回滾其中一個事務。

答案：A、B、C

詳解：

A：binlog_group_commit_sync_delay控制組提交的延遲時間，增大可提升吞吐但增加延遲。
B：innodb_flush_log_at_trx_commit=2異步刷盤，提升性能但可能增加復制延遲。
C：slave_parallel_workers啟用多線程復制，減少延遲。
D：max_connections限制連接數，與復制延遲無直接關系。

答案：A、B、C、D

詳解：

pt-online-schema-change支持在線修改表結構，避免鎖表，適用于大表操作。
包括添加/刪除索引、修改列、變更主鍵等場景。

答案：B、D

詳解：

B：key_buffer_size僅對MyISAM引擎有效，InnoDB使用緩沖池。
D：read_rnd_buffer_size用于隨機讀取排序，增大可減少排序時間。
A：錯誤，緩沖池過大會導致操作系統緩存不足，通常建議不超過總內存的75%。
C：sort_buffer_size建議根據查詢負載調整，盲目增大可能導致內存碎片。

《高性能MySQL》第6章 schema設計與管理

第六章核心知識點

數據類型優化原則
- 選擇最小存儲空間類型（如TINYINT優于INT）
- 避免NULL列（影響索引統計和查詢優化）
- 使用整型存儲IP地址（INET_ATON()/INET_NTOA()）
- 優先使用ENUM替代固定值字符串（如狀態字段）
范式與反范式設計
- 反范式化適用于讀多寫少場景（如冗余高頻查詢字段）
- 避免過度反范式化（如犧牲寫入性能存儲大字段）
索引設計
- 覆蓋索引（Using index）避免回表
- 前綴索引優化長文本（如VARCHAR(255)的前5個字符）
- 多列索引順序遵循最左前綴原則
- 冗余索引檢測（如(a,b)與(a)重復）
Schema管理
- 在線DDL工具（如pt-online-schema-change避免鎖表）
- 源碼控制與自動化部署（如Git管理DDL變更）
- 避免DDL高峰期執行（如業務低峰期操作）
特殊場景設計
- JSON類型優化（避免存儲大對象，使用虛擬列索引）
- 分區表設計（按時間或范圍分區分攤查詢壓力）

多選題

1. 關于MySQL數據類型選擇，以下哪些說法正確？
A. 使用VARCHAR(255)作為默認字符串長度
B. 整數類型應優先選擇最小存儲空間（如TINYINT）
C. ENUM適合存儲固定值列表（如性別、狀態）
D. TEXT類型適合存儲頻繁更新的短文本

2. 以下哪些場景適合反范式設計？
A. 用戶表存儲冗余的country_name（避免JOIN）
B. 訂單表存儲product_price歷史值（避免關聯價格表）
C. 日志表存儲user_id和username（減少關聯查詢）
D. 商品表存儲category_id和category_name（避免頻繁JOIN）

3. 索引設計中，哪些情況會導致索引失效？
A. 索引列使用LIKE 'abc%'
B. 索引列包含NULL值
C. 索引列在查詢條件中使用OR連接
D. 索引列是字符串但查詢條件未加引號

4. 關于在線DDL操作，以下哪些描述正確？
A. ALGORITHM=INPLACE無需重建表
B. LOCK=NONE允許讀寫操作
C. 所有DDL操作都支持在線模式
D. pt-online-schema-change通過觸發器實現無鎖變更

5. 以下哪些情況適合使用前綴索引？
A. VARCHAR(255)的URL字段（取前10個字符）
B. TEXT類型字段的全文搜索
C. 高基數字段（如email）的精確查詢
D. 頻繁更新的字段（減少索引維護成本）

6. 關于JSON數據類型，以下哪些說法正確？
A. JSON字段適合存儲結構化數據（如配置信息）
B. JSON索引通過虛擬列實現（如column->"$.key"）
C. JSON類型比傳統表結構查詢更快
D. 大JSON對象應存儲在文件系統（如對象存儲）

7. 以下哪些屬于Schema設計陷阱？
A. 過度使用VARCHAR(255)
B. 在WHERE條件中使用函數（如WHERE YEAR(date) = 2023）
C. 為每個查詢單獨創建索引
D. 使用ENUM存儲動態擴展的枚舉值

8. 關于分區表設計，以下哪些描述正確？
A. 范圍分區適合按時間歸檔歷史數據
B. 列表分區適合枚舉值分片（如省份）
C. 分區表自動優化查詢性能
D. 分區鍵必須包含在主鍵中

9. 以下哪些工具可用于在線Schema變更？
A. pt-online-schema-change
B. gh-ost
C. FLUSH TABLES WITH READ LOCK
D. ALTER TABLE ... ALGORITHM=INSTANT

10. 關于Schema管理，以下哪些實踐是正確的？
A. 將Schema變更納入版本控制（如Git）
B. 生產環境直接執行未經測試的DDL
C. 使用pt-online-schema-change避免鎖表
D. 所有DDL操作在業務高峰期執行

答案與詳解總結

答案：B, C
解析：

B：更小的整數類型減少存儲空間和內存占用（如TINYINT僅需1字節）。
C：ENUM通過整數存儲固定值，比字符串更節省空間且查詢更快。
A：VARCHAR(255)默認長度浪費空間，應按實際需求設置。
D：TEXT類型適合大文本，頻繁更新會導致碎片化。

答案：A, B, C, D
解析：
反范式化適用于高頻讀場景，通過冗余字段減少JOIN操作。所有選項均通過冗余提升查詢性能，但需權衡寫入成本。
答案：B, D
解析：

B：NULL值使索引統計不準確，可能導致優化器放棄使用索引。
D：字符串未加引號會導致類型隱式轉換，使索引失效（如WHERE id = 123對字符串id無效）。
A：LIKE 'abc%'可使用前綴索引。
C：OR條件需所有字段都有索引才會生效，否則可能全表掃描。

答案：A, B, D
解析：

A：INPLACE算法直接修改數據文件，無需重建表（如添加列）。
B：LOCK=NONE允許并發讀寫（部分操作仍需短暫鎖）。
C：復雜操作（如修改字符集）不支持在線模式。
D：pt-online-schema-change通過觸發器和影子表實現無鎖變更。

答案：A, D
解析：

A：長文本取前綴減少索引大小，適合查詢前綴匹配。
D：前綴索引減少索引維護成本（如頻繁更新的status字段）。
B：全文搜索應使用FULLTEXT索引。
C：高基數字段需完整索引保證選擇性。

答案：A, B, D
解析：

A：JSON適合非結構化或半結構化數據（如用戶偏好設置）。
B：MySQL 5.7+支持虛擬列索引（如ALTER TABLE t ADD INDEX idx_key ((data->"$.key"))）。
C：JSON查詢通常比傳統表結構慢（需解析JSON路徑）。
D：大JSON對象存儲在文件系統可減少數據庫體積。

答案：A, B, C, D
解析：

A：浪費存儲空間且影響索引效率。
B：函數操作導致索引失效。
C：索引過多影響寫入性能。
D：動態枚舉需ALTER TABLE，建議改用關聯表。

答案：A, B, D
解析：

A：范圍分區按時間范圍分片，便于清理舊數據。
B：列表分區按離散值分片（如PARTITION BY LIST (province)）。
C：分區表需配合查詢條件才能生效（如WHERE date BETWEEN ...）。
D：分區鍵必須為主鍵的一部分。

答案：A, B, D
解析：

A：Percona工具，通過觸發器和影子表實現無鎖變更。
B：GitHub工具，基于binlog的異步變更。
C：鎖表操作，不支持在線變更。
D：MySQL 8.0+支持部分操作的即時變更。

答案：A, C
解析：

A：版本控制確保變更可追溯和回滾。
B：未經測試的DDL可能導致生產事故。
C：pt-online-schema-change通過觸發器實現無鎖變更。
D：高峰期執行DDL會導致性能下降。

通過這些問題，可鞏固第六章關于數據類型、索引、Schema設計的核心難點。

《高性能MySQL》第7章創建性能的索引

第七章核心重難點總結

索引類型與底層原理
- B-tree索引（InnoDB默認）的存儲結構與最左前綴匹配原則
- 覆蓋索引的原理與優勢（減少回表操作）
- 全文索引（FULLTEXT）與空間索引（SPATIAL）的適用場景
- 聚簇索引（InnoDB）與非聚簇索引（MyISAM）的區別
索引設計策略
- 最左前綴原則與復合索引設計（列順序影響查詢效率）
- 冗余索引的識別與避免（如(a,b)與(a)的冗余性）
- 前綴索引在長文本字段（如VARCHAR(255)）中的應用
- 索引選擇性（Cardinality）的優化（高選擇性列優先建索引）
索引優化技巧
- 索引覆蓋掃描（Covering Index）的適用場景
- 利用索引排序（避免filesort）
- 聯表查詢中的索引優化（JOIN順序與索引選擇）
- 索引下推（Index Condition Pushdown, ICP）的原理
索引維護與診斷
- 索引統計信息的維護（ANALYZE TABLE的作用）
- 碎片化索引的檢測與優化（OPTIMIZE TABLE vs. ALTER TABLE）
- 鎖機制對索引性能的影響（如間隙鎖在RR隔離級別下的行為）

多選題

題目1：關于B-tree索引的描述，哪些是正確的？
A. InnoDB的聚簇索引將數據與索引存儲在同一結構中
B. B-tree索引支持范圍查詢（如BETWEEN和>操作符）
C. 索引列的順序不影響查詢效率
D. B-tree索引的葉子節點直接存儲數據行

題目2：以下哪些情況會導致索引失效？
A. 在索引列上使用LIKE 'abc%'
B. 索引列上使用函數（如LOWER(column)）
C. 索引列是字符串類型，但查詢條件未加引號（如WHERE col=123）
D. 使用復合索引時，查詢條件僅包含最左列

題目3：關于覆蓋索引的描述，哪些正確？
A. 覆蓋索引可以避免回表操作
B. 覆蓋索引必須包含查詢的所有列
C. 覆蓋索引只能用于SELECT *查詢
D. 聚簇索引天然支持覆蓋索引

題目4：關于索引合并（Index Merge）的描述，哪些正確？
A. 索引合并總是比單索引查詢更高效
B. 索引合并適用于OR條件或UNION查詢
C. 索引合并可能導致更高的CPU和內存消耗
D. 索引合并僅適用于InnoDB引擎

題目5：關于全文索引（FULLTEXT）的描述，哪些正確？
A. 全文索引支持精確匹配（如=操作符）
B. 全文索引只能用于MATCH ... AGAINST查詢
C. 全文索引的停用詞列表可通過配置自定義
D. MyISAM和InnoDB均原生支持全文索引

題目6：關于索引對排序（ORDER BY）的影響，哪些正確？
A. 索引順序必須與ORDER BY完全一致才能避免filesort
B. ASC和DESC混合排序時，索引無法生效
C. 覆蓋索引可以避免排序操作
D. 索引對GROUP BY的優化原理與ORDER BY相同

題目7：關于冗余索引的描述，哪些正確？
A. 聯合索引(a,b)與(a)構成冗余
B. 冗余索引會降低寫操作性能
C. 主鍵索引與唯一索引必然冗余
D. 通過pt-duplicate-key-checker工具可檢測冗余索引

題目8：關于鎖與索引的關系，哪些正確？
A. 非唯一索引的間隙鎖范圍小于唯一索引
B. 聚簇索引的鎖沖突概率高于非聚簇索引
C. 索引覆蓋查詢可減少鎖競爭
D. READ COMMITTED隔離級別下不會使用間隙鎖

題目9：關于索引統計信息的描述，哪些正確？
A. ANALYZE TABLE會鎖表并重新收集統計信息
B. 索引基數（Cardinality）越高，選擇性越好
C. InnoDB的統計信息基于采樣，可能不精確
D. 索引統計信息過期會導致優化器選擇次優執行計劃

題目10：關于多列索引設計的描述，哪些正確？
A. 多列索引列順序應遵循高選擇性優先原則
B. (a,b,c)索引可優化WHERE a=val1 AND c=val3查詢
C. 索引列順序對范圍查詢效率無影響
D. 前綴索引適用于高基數字符串列的聯合索引

答案

答案：A, B
解析：

A正確：InnoDB的聚簇索引將主鍵和數據行存儲在一起，其他索引存儲主鍵值。
B正確：B-tree索引天然支持范圍查詢，因其有序性。
C錯誤：索引列順序影響最左前綴匹配，順序錯誤會導致索引失效。
D錯誤：B-tree索引的葉子節點存儲數據行指針（非聚簇索引）或數據行本身（聚簇索引）。

答案：B, C
解析：

B正確：函數操作會導致索引無法使用（如LOWER(column)）。
C正確：隱式類型轉換（如字符串列與數字比較）會導致索引失效。
A錯誤：LIKE 'abc%'可使用前綴索引（若列是字符串類型）。
D錯誤：復合索引最左列單獨使用時有效（最左前綴原則）。

答案：A, D
解析：

A正確：覆蓋索引通過索引直接返回數據，無需回表。
B錯誤：覆蓋索引只需包含查詢所需列的子集（非全部）。
C錯誤：覆蓋索引適用于任何返回列被索引覆蓋的查詢（如SELECT col1, col2）。
D正確：聚簇索引的葉子節點存儲數據行，天然支持覆蓋索引。

答案：B, C
解析：

B正確：索引合并用于處理多索引條件（如WHERE a=1 OR b=2）。
C正確：索引合并需要掃描多個索引并合并結果，增加資源消耗。
A錯誤：索引合并可能比單索引更慢（需額外合并操作）。
D錯誤：索引合并是MySQL優化器的通用策略，不限于InnoDB。

答案：B, C
解析：

B正確：全文索引僅支持MATCH ... AGAINST語法。
C正確：MySQL允許自定義停用詞列表（通過ft_stopword_file配置）。
A錯誤：全文索引不支持精確匹配，僅支持自然語言或布爾搜索。
D錯誤：InnoDB從MySQL 5.6開始支持全文索引，MyISAM原生支持。

答案：C, D
解析：

C正確：覆蓋索引直接返回有序數據，無需額外排序。
D正確：GROUP BY和ORDER BY均依賴索引有序性，優化原理類似。
A錯誤：部分索引順序匹配（如前綴匹配）可減少排序開銷。
B錯誤：MySQL 8.0支持混合排序（如ORDER BY a ASC, b DESC）的索引優化。

答案：A, B, D
解析：

A正確：(a)是(a,b)的前綴，構成冗余。
B正確：冗余索引增加維護成本（插入、更新時需更新多個索引）。
C錯誤：主鍵與唯一索引可能覆蓋不同列，不一定冗余。
D正確：Percona Toolkit的pt-duplicate-key-checker可自動化檢測。

答案：B, C
解析：

B正確：聚簇索引的行鎖可能升級為間隙鎖（如RR隔離級別）。
C正確：覆蓋索引減少數據頁訪問，降低鎖競爭概率。
A錯誤：非唯一索引的間隙鎖范圍可能更大（需防止幻讀）。
D錯誤：READ COMMITTED仍可能使用間隙鎖（如UPDATE ... FOR UPDATE）。

答案：B, C, D
解析：

B正確：基數表示唯一值比例，越高選擇性越好。
C正確：InnoDB采用隨機采樣，統計信息可能偏差。
D正確：統計信息不準確會導致優化器誤判（如低估掃描行數）。
A錯誤：ANALYZE TABLE在InnoDB中為在線操作（不鎖表）。

答案：A, B
解析：

A正確：高選擇性列前置可過濾更多無效數據。
B正確：多列索引支持最左前綴匹配（如a=val1和a=val1 AND c=val3）。
C錯誤：范圍查詢會終止索引使用（如WHERE a>10 AND b=val僅用a列）。
D錯誤：前綴索引適用于單列長文本，不適用于聯合索引。

注：每題解析均結合第七章核心知識點，涵蓋索引原理、設計策略、優化技巧與維護實踐。

《高性能MySQL》第8章查詢性能優化

多選題

題目1：關于EXPLAIN執行計劃中的type字段，以下哪些描述正確？
A. "const"表示通過主鍵或唯一索引查詢單條記錄
B. "index"表示全索引掃描，需要掃描整棵索引樹
C. "ALL"表示全表掃描，通常需要優化
D. "range"表示范圍查詢，只能使用B-Tree索引
E. "ref"表示使用非唯一索引進行等值查詢

題目2：以下哪些操作會導致MySQL使用臨時表？
A. GROUP BY子句中的列無索引
B. ORDER BY子句中的列與GROUP BY列不一致
C. 使用DISTINCT且無法通過索引優化
D. 查詢包含UNION ALL操作
E. 使用覆蓋索引的查詢

題目3：關于覆蓋索引（Covering Index），以下哪些說法正確？
A. 可以避免回表查詢，減少磁盤I/O
B. 需要包含查詢中所有SELECT的列
C. 對COUNT(*)操作有顯著優化效果
D. 僅適用于等值查詢，不適用于范圍查詢
E. 索引列順序不影響覆蓋索引的效果

題目4：以下哪些是優化JOIN操作的合理策略？
A. 盡量使用小表作為驅動表
B. 為JOIN條件的列添加合適索引
C. 使用STRAIGHT_JOIN強制指定表連接順序
D. 將子查詢改寫為JOIN操作
E. 增加join_buffer_size參數以優化Block Nested-Loop

題目5：關于索引條件下推（Index Condition Pushdown, ICP），以下哪些正確？
A. 僅適用于InnoDB存儲引擎
B. 將WHERE條件從Server層下推到存儲引擎層
C. 可以減少回表次數
D. 需要滿足索引覆蓋查詢的條件
E. 在EXPLAIN中通過"Using index condition"標識

題目6：以下哪些情況可能導致MySQL選擇錯誤的執行計劃？
A. 統計信息不準確
B. 存在強制索引提示（FORCE INDEX）
C. 查詢中包含無法下推的函數（如YEAR()）
D. 使用LIMIT子句限制返回行數
E. 存在多列索引的前綴列參與查詢

題目7：關于MySQL的查詢重寫優化，以下哪些是有效方法？
A. 將OR條件改寫為UNION ALL
B. 將IN子查詢改寫為EXISTS子查詢
C. 使用派生表（Derived Table）代替臨時表
D. 利用延遲關聯（Deferred Join）優化分頁查詢
E. 將NOT IN改寫為LEFT JOIN加IS NULL

題目8：以下哪些是使用EXPLAIN分析時的關鍵字段？
A. possible_keys
B. filtered
C. Extra
D. partitions
E. ref

題目9：關于索引選擇性（Selectivity），以下哪些正確？
A. 選擇性越高，索引效果越好
B. 計算方式為唯一值數量除以總行數
C. 多列索引的選擇性由第一列決定
D. 低選擇性的列不適合單獨建立索引
E. 對VARCHAR列的前綴索引選擇性可能更高

題目10：以下哪些屬于MySQL優化器的局限性？
A. 無法自動選擇最優的JOIN順序
B. 對復雜表達式索引的支持不完善
C. 忽略索引中的列順序導致全索引掃描
D. 統計信息更新不及時影響執行計劃
E. 無法利用覆蓋索引優化包含TEXT列的查詢

答案與解析

題目1答案：ABCE
解析：

D錯誤，"range"可用于B-Tree和SPATIAL索引。
其他選項均符合EXPLAIN的type字段定義（《高性能MySQL》第8章查詢執行計劃分析）。

題目2答案：ABC
解析：

D錯誤，UNION ALL不會創建臨時表，UNION會去重可能使用臨時表。
E錯誤，覆蓋索引避免臨時表。
參考第8章臨時表與文件排序優化部分。

題目3答案：ACE
解析：

B錯誤，只需包含WHERE和SELECT所需列，無需所有列。
D錯誤，覆蓋索引適用于范圍查詢。
E錯誤，索引列順序影響是否覆蓋查詢條件（最左前綴原則）。

題目4答案：ABCDE
解析：

所有選項均為JOIN優化策略（驅動表選擇、索引、執行順序控制、子查詢改寫、緩沖區調整）。

題目5答案：BCE
解析：

A錯誤，ICP適用于支持ICP的引擎如InnoDB和MyISAM。
D錯誤，ICP不需要覆蓋索引，而是過濾索引中的條件。

題目6答案：AC
解析：

B錯誤，強制索引可能糾正而非導致錯誤計劃。
D/E不直接影響優化器選擇錯誤。

題目7答案：ACDE
解析：

B錯誤，EXISTS和IN的性能差異取決于具體場景，非絕對優化方法。

題目8答案：ABCE
解析：

D（partitions）僅在分區表時相關，非通用關鍵字段。

題目9答案：ABDE
解析：

C錯誤，多列索引的選擇性由所有列組合決定。

題目10答案：ABD
解析：

C錯誤，優化器會考慮列順序。
E錯誤，覆蓋索引可包含TEXT列（但需前綴索引）。

重難點總結

執行計劃分析：理解EXPLAIN的type、Extra字段含義及臨時表觸發條件。
索引優化：覆蓋索引、ICP、索引選擇性計算、多列索引設計。
JOIN與子查詢：驅動表選擇、執行順序控制、子查詢改寫策略。
優化器限制：統計信息準確性、復雜表達式處理、索引選擇策略。
查詢重寫技巧：OR轉UNION、延遲關聯、NOT IN優化等。

題目設計覆蓋了索引設計、執行計劃解讀、優化器行為等核心難點，需結合書中案例與原理深入掌握。

《高性能MySQL》第9章復制

第九章核心知識點總結

復制格式
- 基于語句（Statement-Based Replication, SBR）
- 基于行（Row-Based Replication, RBR）
- 混合模式（Mixed Replication）
- 重點：RBR是MySQL 5.6+默認格式，解決SBR的不確定性問題（如非確定性函數、觸發器）。
全局事務標識符（GTID）
- 通過server_uuid和事務ID唯一標識事務。
- 解決傳統復制位點管理的痛點（如日志切換、主從切換）。
- 關鍵配置：gtid_mode=ON，enforce_gtid_consistency=ON。
半同步復制（Semi-Synchronous Replication）
- 至少一個從庫確認接收事務后主庫才提交。
- 提升數據安全性，但可能增加延遲。
- 參數：rpl_semi_sync_master_enabled=1。
多線程復制
- LOGICAL_CLOCK模式：基于組提交并行重放事務。
- DATABASE模式：按數據庫分線程（僅適用于多庫場景）。
- 配置：slave_parallel_workers=N（N≥2）。
延遲復制（Delayed Replication）
- 通過CHANGE MASTER TO MASTER_DELAY=N設置延遲時間（單位：秒）。
- 用于災難恢復（如誤刪表后可回退到延遲時間點）。
復制拓撲
- 主從復制（Master-Slave）
- 主主復制（Master-Master）
- 主從從鏈式復制（Chain Replication）
- 推薦架構：主動-被動模式（Active-Passive）或主動-只讀池模式（Active-ReadOnly Pool）。
故障切換與高可用
- 使用VIP（虛擬IP）或中間件（如Orchestrator）自動化切換。
- 切換步驟：停止寫入→驗證從庫同步→提升從庫為主庫→重定向流量。
復制過濾
- replicate-do-db/replicate-ignore-db（按數據庫過濾）
- replicate-do-table/replicate-ignore-table（按表過濾）
- 注意：過濾可能導致主從數據不一致，慎用。

多選題

1. 關于GTID的描述，哪些是正確的？
A. GTID由server_uuid和遞增的事務ID組成
B. GTID模式必須關閉二進制日志（Binary Log）
C. GTID可簡化主從切換流程
D. GTID不兼容傳統基于位置的復制

2. 半同步復制的主要作用是什么？
A. 提升復制性能
B. 確保至少一個從庫接收事務
C. 防止主庫崩潰導致數據丟失
D. 自動修復主從數據不一致

3. 多線程復制的適用場景包括哪些？
A. 單庫寫入，多庫讀取
B. 高并發事務的混合讀寫
C. 復制拓撲中存在大量延遲節點
D. 需要最大化利用多核CPU

4. 下列哪些配置可提升復制可靠性？
A. sync_binlog=1
B. innodb_flush_log_at_trx_commit=0
C. relay_log_recovery=ON
D. expire_logs_days=7

5. 主從復制延遲的可能原因包括哪些？
A. 主庫寫入壓力過大
B. 從庫硬件性能不足
C. 網絡帶寬不足
D. 使用基于語句的復制（SBR）

6. 關于復制過濾器的描述，哪些正確？
A. binlog_do_db基于當前默認數據庫過濾
B. replicate-ignore-table在從庫過濾指定表
C. 復制過濾器可防止誤刪表
D. 過濾器可能導致主從數據不一致

7. 主從切換時需要考慮哪些風險？
A. 數據丟失
B. 短暫服務中斷
C. 緩沖池（Buffer Pool）污染
D. 自動化切換工具的可靠性

8. 哪些場景適合使用環形復制（Circular Replication）？
A. 多數據中心災備
B. 高可用集群
C. 跨區域數據同步
D. 避免單點故障

9. 多源復制（Multi-Source Replication）的用途包括哪些？
A. 聚合多個數據源到單一從庫
B. 實現跨實例數據同步
C. 替代分片（Sharding）
D. 提升單實例寫入性能

10. 關于復制拓撲設計的最佳實踐，哪些正確？
A. 主從復制使用主動-被動模式
B. 主主復制需配置auto_increment_increment
C. 延遲復制用于備份和容災
D. 所有從庫配置為讀寫分離

答案與詳解匯總

答案：A, C
詳解：

A正確：GTID唯一標識事務，格式為server_uuid:transaction_id。
C正確：GTID自動跟蹤復制進度，切換時無需手動找位點。
B錯誤：GTID必須啟用二進制日志。
D錯誤：GTID與基于位置的復制可通過MASTER_AUTO_POSITION=1兼容。

答案：B, C
詳解：

B正確：半同步確保事務提交前至少一個從庫已接收日志。
C正確：減少主從數據丟失風險（至少有一個從庫有最新數據）。
A錯誤：半同步可能增加延遲。
D錯誤：半同步不修復不一致，需人工介入。

答案：A, D
詳解：

A正確：LOGICAL_CLOCK模式可并行不同庫的事務。
D正確：通過多線程提升從庫重放速度（依賴多核CPU）。
B錯誤：混合讀寫場景需串行化，無法并行。
C錯誤：延遲節點需單獨優化，多線程不適用。

答案：A, C
詳解：

A正確：每次事務提交同步二進制日志到磁盤。
C正確：從庫崩潰后自動清理損壞的中繼日志。
B錯誤：設置為0會降低事務持久性。
D錯誤：控制日志過期時間，與可靠性無關。

答案：A, B, C, D
詳解：

A/B/C/D均正確：高寫入壓力、低性能從庫、網絡延遲、SBR的不確定性均會導致延遲。

答案：A, B, D
詳解：

A正確：binlog_do_db根據主庫當前數據庫過濾。
B正確：replicate-ignore-table在從庫過濾表。
C錯誤：過濾器無法防止誤操作，需結合權限控制。
D正確：過濾可能導致主從數據不一致（如部分表未復制）。

答案：A, B, C, D
詳解：

A/B/C/D均正確：切換可能導致短暫數據丟失、服務中斷、緩存失效，需驗證工具可靠性。

答案：A, C
詳解：

A/C正確：環形復制適用于多中心災備和跨區域同步。
B/D錯誤：環形復制復雜度高，不適合高可用集群或單點故障規避。

答案：A, B
詳解：

A/B正確：多源復制用于合并多實例數據或跨實例同步。
C/D錯誤：多源復制不替代分片，也無法提升單實例寫入性能。

答案：A, B, C
詳解：

A正確：主動-被動避免腦裂。
B正確：主主需設置自增步長避免沖突。
C正確：延遲復制可用于數據恢復。
D錯誤：從庫應設為只讀，避免數據不一致。

《高性能MySQL》第10章備份與恢復

核心知識點：

邏輯備份 vs 物理備份的優缺點
在線熱備份的實現方式及工具選擇
二進制日志在時間點恢復中的核心作用
InnoDB崩潰恢復機制與REDO/UNDO日志
備份一致性保障（FLUSH TABLES WITH READ LOCK應用）
延遲復制在數據修復中的應用場景
云環境下的備份存儲策略設計
備份驗證方法論（checksum驗證、抽樣恢復測試）
并行備份恢復的優化技巧
容災方案中的備份層級設計

多選題

1. 關于InnoDB崩潰恢復機制，以下哪兩項描述正確？
A) 依賴REDO日志進行前滾操作
B) UNDO日志用于保證事務原子性
C) CHECKPOINT機制會清理所有已提交事務
D) 崩潰恢復階段會重建整個緩沖池

2. 使用Percona XtraBackup時，必須滿足哪兩個條件才能執行增量備份？
A) 啟用GTID模式
B) 前一次完整備份的LSN信息
C) 使用獨立表空間文件
D) 關閉二進制日志記錄

3. 關于時間點恢復(PITR)，正確的操作步驟包含：
A) 恢復最新全量備份后直接應用所有binlog
B) 必須保留從備份開始到故障點的所有binlog
C) 使用mysqlbinlog工具按時間范圍過濾日志
D) 需要同步恢復所有從庫的relay log

4. 在云數據庫環境中實施備份策略時，應重點考慮：
A) 跨區域存儲副本
B) 對象存儲的版本控制功能
C) 備份文件加密算法選擇
D) 定期執行備份文件完整性校驗

5. 關于延遲復制技術的應用場景，正確的描述是：
A) 可替代常規備份方案
B) 有效防止誤操作導致數據丟失
C) 需要配合CHANGE MASTER TO配置
D) 延遲時間應設置為業務低峰期時長

6. 使用mysqldump進行邏輯備份時，可能造成鎖定的操作包括：
A) --single-transaction參數
B) --lock-all-tables參數
C) 備份InnoDB表時默認加鎖
D) 使用–master-data參數

7. 驗證備份完整性的有效方法有：
A) 對比備份前后checksum值
B) 在沙箱環境執行完整恢復流程
C) 定期進行備份文件大小比對
D) 使用備份驗證專用存儲過程

8. 關于二進制日志管理策略，正確的做法是：
A) 設置expire_logs_days自動清理
B) 所有從庫啟用log_slave_updates
C) 使用PURGE BINARY LOGS手動刪除
D) 將binlog與數據文件分盤存儲

9. 在大型實例中優化備份性能的手段包括：
A) 采用文件系統快照技術
B) 增加innodb_buffer_pool_size
C) 使用–parallel參數并行導出
D) 關閉AUTOCOMMIT模式

10. 設計容災方案時，必須包含的備份層級是：
A) 實時同步的異地災備
B) 每日增量備份
C) 季度全量歸檔備份
D) 交易日志持續傳輸

答案與解析

1. AB
解析：A正確，REDO日志用于重做已提交事務；B正確，UNDO保證事務回滾。C錯誤，CHECKPOINT不會清理已提交事務；D錯誤，緩沖池通過正常加載恢復。

2. BC
解析：B正確，增量依賴LSN；C正確，需要file-per-table。A無關GTID；D錯誤，二進制日志不影響物理備份。

3. BC
解析：B正確，需完整binlog序列；C正確，時間過濾必要。A錯誤，不能直接應用所有；D錯誤，從庫恢復無關。

4. AD
解析：A正確，地域容災需求；D正確，完整性驗證關鍵。B版本控制非必須；C加密算法非云環境獨有。

5. BC
解析：B正確，防誤刪有效；C正確，延遲復制配置。A錯誤，不能替代備份；D時間設置與業務周期無關。

6. BD
解析：B鎖定全表；D獲取binlog位置時短暫鎖。A使用事務不鎖定；C InnoDB默認無鎖。

7. AB
解析：A正確，校驗值比對；B正確，實際恢復驗證。C大小變化不說明問題；D無專用存儲過程。

8. AD
解析：A自動清理必要；D分盤存儲優化IO。B非所有從庫需要；C手動刪除有風險。

9. AC
解析：A快照提升速度；C并行加速。B緩沖池影響有限；D無關備份性能。

10. ABD
解析：A異地容災核心；B增量保證恢復點；D日志連續保障。C季度歸檔非必須層級。

《高性能MySQL》第11章擴展MySQL

1. 關于水平分片的優缺點，以下哪些描述是正確的？
A) 減少單節點負載壓力
B) 天然支持跨分片事務
C) 分片鍵選擇不當易導致熱點
D) 降低應用層代碼復雜度
E) 支持靈活的多表JOIN操作

2. 選擇分片鍵時需重點考慮哪些因素？
A) 字段值的高基數性
B) 字段的頻繁更新頻率
C) 查詢模式中的過濾條件
D) 字段的存儲空間大小
E) 跨分片關聯的可能性

3. 跨分片查詢可能引發哪些問題？
A) 網絡延遲顯著增加
B) 事務一致性難以保證
C) 分片中間件負載激增
D) 單分片索引失效
E) 數據冗余存儲成本上升

4. 關于數據遷移至分片集群的挑戰，哪些正確？
A) 遷移期間需保證零停機
B) 增量數據同步難以處理
C) 分片規則變更導致數據重分布
D) 應用層無需修改查詢邏輯
E) 跨分片唯一ID生成復雜

5. 分片中間件的核心功能包括？
A) 自動負載均衡
B) SQL查詢解析路由
C) 分布式事務協調
D) 物理存儲引擎優化
E) 跨分片結果集合并

6. 分片與復制結合使用時，哪些場景適合？
A) 分片內實現讀寫分離
B) 跨分片強一致性事務
C) 分片副本提升高可用性
D) 分片間數據實時同步
E) 副本延遲影響跨分片查詢

7. 分片集群監控應關注哪些指標？
A) 各分片QPS均衡度
B) 中間件連接池利用率
C) 單分片鎖等待時間
D) 跨分片查詢響應延遲
E) 分片鍵哈希沖突率

8. 分片節點故障處理步驟包括？
A) 自動切換至備用節點
B) 手動修改分片路由表
C) 臨時關閉整個集群
D) 數據回補與一致性校驗
E) 優先修復故障節點

9. 分片自動化管理工具的作用是？
A) 動態調整分片數量
B) 自動優化分片鍵選擇
C) 彈性擴縮容分片資源
D) 自動重構跨分片事務
E) 智能路由復雜JOIN查詢

10. 云環境下分片設計的特殊考慮包括？
A) 利用對象存儲降低成本
B) 跨可用區部署容災
C) 依賴SDK實現分片邏輯
D) 按需付費的彈性擴展
E) 避免使用托管數據庫服務

答案與解析

AC
- A正確，分片分散負載；C正確，分片鍵不合理會導致數據傾斜；B錯誤，跨分片事務需額外處理；D錯誤，應用需適配分片邏輯；E錯誤，JOIN難度增加。
ACE
- A（高基數避免熱點）、C（查詢過濾匹配分片鍵）、E（減少跨分片關聯）正確；B（頻繁更新破壞路由）、D（存儲大小無關）錯誤。
ABC
- A（多節點通信延遲）、B（事務難保證）、C（中間件負載高）正確；D（索引仍有效）、E（冗余非必然結果）錯誤。
BCE
- B（增量同步復雜）、C（規則變更需重分布）、E（唯一ID生成難）正確；A（零停機難實現）、D（需修改邏輯）錯誤。
ABE
- A（負載均衡）、B（查詢路由）、E（結果合并）正確；C（部分中間件支持，非核心）、D（存儲引擎無關）錯誤。
AC
- A（分片內讀寫分離）、C（副本高可用）正確；B（強一致需額外機制）、D（分片間不同步）、E（延遲非必然）錯誤。
ABD
- A（負載均衡）、B（中間件性能）、D（跨分片延遲）正確；C（單分片鎖無關分片）、E（哈希沖突率非常規指標）錯誤。
ABDE
- A（自動切換）、B（路由調整）、D（數據校驗）、E（修復節點）正確；C（關閉集群不可行）錯誤。
AC
- A（動態擴縮）、C（彈性資源）正確；B（分片鍵需人工設計）、D（事務需業務處理）、E（JOIN非自動化）錯誤。
ABD
- A（對象存儲降低成本）、B（跨可用區容災）、D（按需擴展）正確；C（分片邏輯多在中間件）、E（云托管可支持分片）錯誤。

解析重點：

分片策略：哈希分片（均衡但難范圍查詢）與范圍分片（易熱點但支持范圍）的權衡。
分片鍵選擇：需結合查詢模式和高基數，避免頻繁更新字段。
跨分片事務：通常犧牲強一致性，采用最終一致性或業務補償。
中間件角色：路由、合并結果，但不處理存儲引擎優化。
云環境特性：彈性擴展和跨區部署是核心優勢，需結合云服務特性設計。

《高性能MySQL》第12章云端的MySQL

重點內容

分片（Sharding）策略：水平分片與功能分片的區別、分片鍵設計原則、數據路由機制。
讀寫分離與負載均衡：中間件（ProxySQL/Vitess）的作用、復制拓撲的優化。
分布式數據一致性：CAP理論的應用、最終一致性方案（如異步復制）、分布式事務（XA/2PC）。
自動化運維：分片擴容/縮容、自動化故障轉移、監控指標（如復制延遲、分片負載）。
云原生擴展：云數據庫的彈性擴展、Serverless架構適配。

難點內容

分片鍵選擇的權衡：業務查詢模式與分片鍵的關聯性，避免熱點問題。
跨分片事務的復雜性：分布式鎖、補償事務的實現。
在線分片遷移：不停機數據遷移工具（如gh-ost）的使用與風險控制。
全局唯一ID生成：Snowflake算法、數據庫自增ID的局限性。
多租戶架構設計：資源隔離與數據隔離的平衡。

10道Hard難度多選題

關于MySQL分片策略，以下哪些說法正確？
A. 水平分片通過將數據按行分布到不同節點實現擴展。
B. 功能分片適用于按業務模塊劃分數據的場景。
C. 分片鍵應選擇高基數字段以避免數據傾斜。
D. 所有分片策略均需支持跨分片事務。
以下哪些中間件適合用于MySQL分片管理？
A. Vitess
B. ProxySQL
C. Redis
D. MyCat
在分片擴容過程中，可能面臨哪些挑戰？
A. 數據遷移期間的服務停機。
B. 分片鍵需要動態調整。
C. 跨分片查詢性能下降。
D. 全局唯一ID生成沖突。
關于MySQL復制拓撲的可擴展性設計，正確的是？
A. 鏈式復制（Chain Replication）能減少主節點負載。
B. 半同步復制確保所有副本數據強一致。
C. 多源復制適用于聚合多個數據源的場景。
D. 環形復制（Ring Replication）可提高寫吞吐量。
分片鍵設計時，需重點考慮哪些因素？
A. 字段的查詢頻率。
B. 字段的數據類型大小。
C. 業務事務的隔離級別。
D. 數據分布的均勻性。
以下哪些方法可用于實現分布式事務？
A. XA協議（兩階段提交）。
B. 基于消息隊列的最終一致性。
C. 使用全局鎖（如Redis分布式鎖）。
D. 單庫事務的串行化隔離級別。
分片環境下，以下哪些查詢可能無法高效執行？
A. 按分片鍵等值查詢。
B. 跨分片的JOIN操作。
C. 基于分片鍵的范圍查詢。
D. 單分片內的聚合統計。
云數據庫（如AWS Aurora）的擴展性優勢包括？
A. 自動讀寫分離。
B. 存儲與計算層分離。
C. 內置分片管理功能。
D. 按需彈性擴容。
監控分片集群時，應關注哪些關鍵指標？
A. 單個分片的QPS/TPS。
B. 跨分片查詢的響應時間。
C. 分片間的數據一致性延遲。
D. 中間件的連接池使用率。
關于分片后的數據備份與恢復，正確的是？
A. 每個分片需獨立備份。
B. 邏輯備份（如mysqldump）比分片物理備份更高效。
C. 恢復時需確保所有分片的時間點一致性。
D. 云數據庫的Snapshot功能可替代分片備份。

答案與詳解

AB
- A正確：水平分片按行拆分數據。
- B正確：功能分片按業務模塊劃分（如用戶庫、訂單庫）。
- C錯誤：高基數字段不一定避免傾斜，需結合查詢模式。
- D錯誤：部分場景可避免跨分片事務（如本地分片操作）。
ABD
- A正確：Vitess是K8s原生分片管理工具。
- B正確：ProxySQL支持讀寫分離和分片路由。
- D正確：MyCat是開源分片中間件。
- C錯誤：Redis是緩存數據庫，不直接管理分片。
ACD
- A正確：傳統擴容需停機，但在線工具（如Vitess）可避免。
- C正確：跨分片查詢需聚合結果，性能可能下降。
- D正確：擴容后新分片ID生成需兼容舊邏輯。
- B錯誤：分片鍵一般固定，動態調整需重構數據。
AC
- A正確：鏈式復制減少主節點同步壓力。
- C正確：多源復制用于聚合數據（如分析庫）。
- B錯誤：半同步僅保證至少一個副本接收日志，非強一致。
- D錯誤：環形復制易導致數據沖突，極少使用。
AD
- A正確：查詢頻率影響路由效率。
- D正確：均勻分布避免熱點。
- B錯誤：數據類型大小影響存儲，非分片鍵核心因素。
- C錯誤：隔離級別是事務屬性，與分片鍵無關。
ABC
- A正確：XA協議是標準分布式事務方案。
- B正確：消息隊列實現最終一致性（如Saga模式）。
- C正確：全局鎖可協調跨分片操作。
- D錯誤：單庫事務無法解決跨分片問題。
B
- B正確：跨分片JOIN需合并數據，性能低下。
- A/C/D錯誤：分片鍵相關查詢可路由到單分片，效率高。
ABD
- A正確：云數據庫自動分離讀寫流量。
- B正確：存儲與計算解耦（如Aurora共享存儲）。
- D正確：按需擴展計算節點。
- C錯誤：分片管理仍需應用層設計。
ABCD
- 所有選項均為分片集群監控重點。
AC
- A正確：分片獨立備份便于恢復。
- C正確：恢復需全局一致性（如GTID）。
- B錯誤：邏輯備份對大數據量分片效率低。
- D錯誤：云Snapshot可能不保證分片間一致性。

《高性能MySQL》第13章 MySQL的合規性

章節重點內容

合規性框架（GDPR、CCPA等核心要求）
數據加密策略（透明加密、傳輸層加密）
審計日志管理（記錄范圍、存儲周期）
數據生命周期控制（分類、保留策略）
分片與數據主權沖突
數據脫敏技術
訪問控制與權限管理
跨境數據流動限制
合規性監控體系
數據備份與恢復的合規性

多選題（答案及解析見最后）

關于GDPR合規性要求，以下哪些描述正確？
A) 要求數據最小化原則
B) 用戶有權要求永久刪除個人數據
C) 所有數據庫必須啟用透明數據加密(TDE)
D) 禁止跨境傳輸未脫敏的歐盟公民數據
E) 數據保留時間由業務需求決定即可
MySQL中實現數據加密的正確方法包括？
A) 使用InnoDB的透明數據加密(TDE)
B) 通過SSL/TLS加密客戶端-服務器通信
C) 在應用層實現字段級加密
D) 依賴文件系統級的全盤加密
E) 使用AES_ENCRYPT()函數直接加密列數據
審計日志應記錄哪些關鍵操作？
A) 用戶登錄失敗嘗試
B) 所有SELECT查詢的執行計劃
C) 數據庫Schema變更(DDL)
D) 敏感表的訪問時間戳
E) 慢查詢日志中的性能指標
數據生命周期管理的關鍵步驟包括？
A) 按數據類型分類標簽
B) 動態延長所有數據的保留時間
C) 制定自動化數據刪除策略
D) 將過期數據遷移到低成本存儲
E) 實時監控CPU使用率
分片策略可能引發的合規性問題有？
A) 跨分片查詢導致性能下降
B) 不同分片所在地區的數據主權沖突
C) 分片備份的完整性難以驗證
D) 單分片故障影響全局可用性
E) 分片間數據一致性難以保障
設計數據保留策略時需優先考慮？
A) 法律法規要求的最短保留時間
B) 業務系統的歷史數據分析需求
C) 存儲介質的硬件成本
D) 用戶的個人偏好設置
E) 數據庫版本升級計劃
有效的數據脫敏技術包括？
A) 對身份證號部分字段掩碼(如310***********1234)
B) 使用不可逆哈希算法處理手機號
C) 將日期泛化為季度級別(如2023-Q2)
D) 通過正則表達式替換敏感關鍵詞
E) 對加密后的數據進行Base64編碼
訪問控制的最佳實踐包括？
A) 遵循最小權限原則分配賬戶權限
B) 定期審查已離職員工的數據庫賬戶
C) 為所有開發者共享只讀管理員賬戶
D) 啟用多因素認證(MFA)
E) 記錄所有權限變更操作
數據主權問題可能涉及？
A) 數據存儲的物理位置是否符合當地法律
B) 備份數據跨境傳輸的合法性
C) 第三方云服務商的合規認證狀態
D) 數據庫查詢響應時間的SLA
E) 索引優化策略的選擇
合規性監控系統的核心功能應包括？
A) 自動檢測未加密的敏感數據字段
B) 定期生成數據訪問審計報告
C) 實時攔截所有高風險SQL操作
D) 動態調整InnoDB緩沖池大小
E) 對比當前策略與最新法規差異