@gordon.gan/specflow 1.4.0-beta → 1.4.2-beta

package/skills/database/mysql/references/06-index-optimization.md

@@ -0,0 +1,232 @@
+# 索引与执行计划 (Index & Query Optimization)
+
+## 简介
+
+索引是 MySQL 性能优化的核心手段。正确的索引能大幅减少扫描行数，错误的索引设计则会导致全表扫描和性能灾难。
+
+## 索引类型
+
+| 索引类型 | 底层结构 | 版本要求 | 适用场景 |
+|---------|---------|---------|---------|
+| **B-Tree** | B+ 树 | 全版本 | 等值/范围/排序查询（默认） |
+| **Hash** | 哈希表 | MEMORY 引擎 | 等值查询（不支持范围） |
+| **Fulltext** | 倒排索引 | 5.6+ | 全文搜索 (MATCH AGAINST) |
+| **Spatial** | R-Tree | 5.7+ | 空间数据查询 |
+| **Descending** | B+ 树降序 | 8.0+ | 混合排序方向优化 |
+| **Invisible** | 同 B-Tree | 8.0+ | 测试删除影响而不实际删除 |
+| **Functional Key Parts** | 表达式索引 | 8.0.13+ | 函数/表达式索引 |
+
+### B-Tree 索引创建
+
+```sql
+-- 普通索引
+CREATE INDEX idx_name ON user (name);
+
+-- 唯一索引
+CREATE UNIQUE INDEX uk_email ON user (email);
+
+-- 复合索引（最左前缀原则）
+CREATE INDEX idx_city_age ON user (city, age);
+
+-- 前缀索引（字符串前 N 字符）
+CREATE INDEX idx_email_prefix ON user (email(10));
+
+-- 全文索引
+CREATE FULLTEXT INDEX ftx_content ON article (title, content);
+
+-- 降序索引 (MySQL 8.0+)
+CREATE INDEX idx_created_desc ON `order` (created_at DESC);
+
+-- 不可见索引（测试用）
+CREATE INDEX idx_test ON user (name) INVISIBLE;
+ALTER TABLE user ALTER INDEX idx_test VISIBLE;
+
+-- 函数索引 (MySQL 8.0.13+)
+CREATE INDEX idx_phone_last4 ON user ((RIGHT(phone, 4)));
+```
+
+## 复合索引最左前缀原则
+
+复合索引 `idx_a_b_c (a, b, c)`：
+
+| 查询条件 | 索引使用情况 |
+|---------|-------------|
+| `WHERE a = 1` | ✅ 使用 a |
+| `WHERE a = 1 AND b = 2` | ✅ 使用 a, b |
+| `WHERE a = 1 AND b = 2 AND c = 3` | ✅ 使用 a, b, c |
+| `WHERE a = 1 ORDER BY b` | ✅ 使用 a（排序） |
+| `WHERE a = 1 AND c = 3` | ✅ 使用 a（c 只能过滤） |
+| `WHERE a IN (1, 2) AND b = 3` | ✅ 使用 a, b |
+| `WHERE b = 2` | ❌ 跳过了 a |
+| `WHERE c = 3` | ❌ 跳过了 a, b |
+
+### 索引设计原则
+
+1. **区分度高的列放前面**：选择性 = `COUNT(DISTINCT col) / COUNT(*)`
+2. **等值条件列放前面**：`=` 比范围查询列放前面
+3. **覆盖索引**：查询列全在索引中（Extra 显示 `Using index`），避免回表
+4. **索引下推 (ICP)**：MySQL 5.6+，引擎层用 WHERE 条件过滤索引记录后再回表
+
+## EXPLAIN 执行计划分析
+
+### 使用 EXPLAIN
+
+```sql
+EXPLAIN SELECT u.name, o.order_no
+FROM user u
+JOIN `order` o ON u.id = o.user_id
+WHERE u.id = 100;
+```
+
+### EXPLAIN 输出列
+
+| 列名 | 含义 | 关键值 |
+|------|------|--------|
+| `id` | SELECT 标识符，id 越大越先执行 | |
+| `select_type` | 查询类型 | SIMPLE, PRIMARY, SUBQUERY, DERIVED, UNION |
+| `table` | 表名 | |
+| `partitions` | 扫描的分区 | |
+| `type` | 访问类型（性能排序） | system > const > eq_ref > ref > range > index > **ALL** |
+| `possible_keys` | 可能使用的索引 | |
+| `key` | 实际使用的索引 | |
+| `key_len` | 使用的索引字节长度 | 越大越好（匹配更多列） |
+| `ref` | 索引匹配的列或常量 | |
+| `rows` | 预估扫描行数 | 越小越好 |
+| `filtered` | 过滤后百分比 | |
+| `Extra` | 额外信息 | **🔑 重要** |
+
+### type 访问类型（从优到劣）
+
+| type | 说明 | 示例 |
+|------|------|------|
+| **system** | 表只有一行 | 最好 |
+| **const** | 主键/唯一索引等值查询 | `WHERE id = 1` |
+| **eq_ref** | JOIN 主键/唯一索引关联 | `ON u.id = o.user_id` |
+| **ref** | 普通索引等值查询 | `WHERE name = '张三'` |
+| **range** | 索引范围扫描 | `WHERE id > 100`, `LIKE '张%'` |
+| **index** | 全索引扫描 | 不推荐 |
+| **ALL** | 全表扫描 | **❌ 最差** |
+
+### Extra 关键信息
+
+| Extra 值 | 含义 |
+|----------|------|
+| **Using index** | 覆盖索引（无需回表）✅ 最佳 |
+| **Using where** | 用 WHERE 过滤 |
+| **Using index condition** | 索引下推 ICP ✅ |
+| **Using temporary** | 使用临时表（需优化）❌ |
+| **Using filesort** | 文件排序（需优化）❌ |
+| **Using join buffer** | JOIN 未用索引 ❌ |
+| **Using MRR** | 多范围读取优化 ✅ |
+
+### EXPLAIN ANALYZE (MySQL 8.0.18+)
+
+```sql
+-- 实际执行并显示各步骤耗时和行数
+EXPLAIN ANALYZE
+SELECT u.name, COUNT(o.id) AS order_count
+FROM user u
+LEFT JOIN `order` o ON u.id = o.user_id
+GROUP BY u.id
+ORDER BY order_count DESC
+LIMIT 10;
+```
+
+## SQL 优化原则
+
+```
+★ 核心原则：减少扫描行数，减少回表，减少排序
+
+1. WHERE 条件列建索引（符合最左前缀）
+2. 避免 SELECT *，仅取需要的列（利用覆盖索引）
+3. 用 EXISTS 代替 IN（大数据量下）
+4. 用 UNION ALL 代替 UNION（不需要去重时）
+5. 用 LIMIT 限制结果集大小
+6. 大表分页用游标（WHERE id > last_id）而非 OFFSET
+7. JOIN 的关联列必须有索引
+8. GROUP BY / ORDER BY 的列尽量利用索引
+9. 避免在 WHERE 条件列上使用函数或计算
+10. 拆分大查询为多次小查询（减少锁范围）
+```
+
+## 常见优化案例
+
+### 隐式类型转换（索引失效）
+
+```sql
+-- ❌ phone 是 VARCHAR，传 INT 导致全表扫描
+SELECT * FROM user WHERE phone = 13800138000;
+
+-- ✅ 字符类型就传字符串
+SELECT * FROM user WHERE phone = '13800138000';
+```
+
+### WHERE 条件函数操作（索引失效）
+
+```sql
+-- ❌ DATE() 函数使索引失效
+SELECT * FROM `order` WHERE DATE(created_at) = '2024-01-01';
+
+-- ✅ 范围查询可用索引
+SELECT * FROM `order` WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02';
+```
+
+### 大分页优化
+
+```sql
+-- ❌ OFFSET 越大越慢（先扫描再丢弃）
+SELECT * FROM `order` ORDER BY id LIMIT 100000, 20;
+
+-- ✅ 游标分页
+SELECT * FROM `order` WHERE id > 100000 ORDER BY id LIMIT 20;
+
+-- ✅ 子查询 + JOIN 方式
+SELECT * FROM `order`
+JOIN (SELECT id FROM `order` ORDER BY id LIMIT 100000, 20) AS tmp
+ON `order`.id = tmp.id;
+```
+
+### OR 改为 UNION
+
+```sql
+-- ❌ OR 可能用不到复合索引
+SELECT * FROM user WHERE name = '张三' OR email = 'zhangsan@example.com';
+
+-- ✅ UNION 分别用各自索引
+SELECT * FROM user WHERE name = '张三'
+UNION
+SELECT * FROM user WHERE email = 'zhangsan@example.com';
+```
+
+## 慢查询配置
+
+```ini
+# my.cnf
+slow_query_log = ON                          # 开启慢查询
+slow_query_log_file = /var/log/mysql/slow.log # 慢查询日志文件
+long_query_time = 1                          # 超过 1 秒的查询记录
+log_queries_not_using_indexes = ON           # 记录未使用索引的查询
+min_examined_row_limit = 100                 # 扫描行数超过此值才记录
+```
+
+### 分析慢查询
+
+```bash
+# mysqldumpslow 排序取前10
+mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
+
+# Percona Toolkit 分析
+pt-query-digest /var/log/mysql/slow.log
+```
+
+## 索引设计规范
+
+1. 每个表必须有主键（推荐 BIGINT AUTO_INCREMENT 或有序 UUID）
+2. 主键不宜过长（B+ 树二级索引过大）
+3. 每个表索引数不超过 5-8 个（过多影响写入性能）
+4. 大表（> 1000 万行）索引必须业务验证后创建
+5. 字符串区分度低或长度大时用前缀索引
+6. ORDER BY / GROUP BY / JOIN 的列考虑建索引
+7. 不建索引的列：频繁更新、区分度极低（如性别）
+8. 用 INVISIBLE 索引测试后再删除
+9. 避免冗余索引（如 idx_a_b 和 idx_a 重复）

package/skills/database/mysql/references/07-replication-ha.md

@@ -0,0 +1,213 @@
+# 主从复制与高可用 (Replication & High Availability)
+
+## 简介
+
+MySQL 主从复制是生产环境中最常用的高可用和读写分离方案。主库（Master）记录二进制日志（Binlog），从库（Slave）通过网络读取并回放日志，实现数据同步。
+
+## 复制原理
+
+```
+┌─────────────┐          ┌─────────────┐
+│   Master    │          │   Slave     │
+├─────────────┤          ├─────────────┤
+│   Binlog    │─────→    │ Relay Log   │
+│  (二进制日志) │  IO线程  │  (中继日志)  │
+└─────────────┘          └──────┬──────┘
+                               │ SQL线程
+                               ▼
+                           ┌─────────────┐
+                           │  Slave Data  │
+                           └─────────────┘
+```
+
+**复制流程**：
+1. Master 提交事务时写入 Binlog
+2. Slave 的 IO 线程读取 Master 的 Binlog，写入 Relay Log
+3. Slave 的 SQL 线程回放 Relay Log，应用到自身数据
+
+## 主从同步配置
+
+### Master 配置
+
+```ini
+# my.cnf
+server-id = 1
+log_bin = /var/log/mysql/mysql-bin
+binlog_format = ROW             # ROW 格式最安全（推荐）
+binlog_expire_logs_seconds = 604800  # 保留 7 天
+sync_binlog = 1                 # 每次事务提交同步（最安全）
+```
+
+```sql
+-- 创建复制用户
+CREATE USER 'replicator'@'%' IDENTIFIED BY 'password';
+GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';
+FLUSH PRIVILEGES;
+
+-- 查看 Master 状态
+SHOW MASTER STATUS;
+-- File: mysql-bin.000001, Position: 1234
+```
+
+### Slave 配置
+
+```ini
+# my.cnf
+server-id = 2
+relay_log = /var/log/mysql/mysql-relay-bin
+read_only = 1                   # 只读（防止误写）
+```
+
+```sql
+-- 设置主节点
+CHANGE MASTER TO
+  MASTER_HOST = '192.168.1.100',
+  MASTER_PORT = 3306,
+  MASTER_USER = 'replicator',
+  MASTER_PASSWORD = 'password',
+  MASTER_LOG_FILE = 'mysql-bin.000001',
+  MASTER_LOG_POS = 1234;
+
+-- 启动复制
+START SLAVE;
+
+-- 查看复制状态（关键字段）
+SHOW SLAVE STATUS\G
+-- Slave_IO_Running: Yes      -- IO 线程正常
+-- Slave_SQL_Running: Yes     -- SQL 线程正常
+-- Seconds_Behind_Master: 0   -- 延迟秒数（0 最佳）
+
+-- 停止复制
+STOP SLAVE;
+
+-- 重置复制
+RESET SLAVE ALL;
+```
+
+### 复制状态监控关键字段
+
+| 字段 | 说明 | 正常值 |
+|------|------|--------|
+| `Slave_IO_Running` | IO 线程状态 | Yes |
+| `Slave_SQL_Running` | SQL 线程状态 | Yes |
+| `Seconds_Behind_Master` | 延迟秒数 | 0（或很小） |
+| `Last_IO_Error` | IO 线程错误 | 空 |
+| `Last_SQL_Error` | SQL 线程错误 | 空 |
+| `Relay_Log_Space` | Relay Log 大小 | 稳定值 |
+| `Exec_Master_Log_Pos` | 已执行位置 | 持续增长 |
+
+## 复制模式对比
+
+| 模式 | 说明 | 一致性 | 性能 | 推荐度 |
+|------|------|--------|------|--------|
+| **异步 (ASYNC)** | Master 不等待 Slave 确认 | 最终一致性 | 最高 | 默认 |
+| **半同步 (SEMISYNC)** | 至少一个 Slave 写入 Relay Log | 较高 | 略微降低 | ★★★★★ |
+| **全同步 (Group Replication)** | 多数节点确认 | 强一致性 | 最低 | 特定场景 |
+
+### 半同步复制配置
+
+```sql
+-- Master 和 Slave 都安装插件
+INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
+INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
+
+-- Master 启用
+SET GLOBAL rpl_semi_sync_master_enabled = 1;
+SET GLOBAL rpl_semi_sync_master_timeout = 1000;  -- 1s 超时降级为异步
+
+-- Slave 启用
+SET GLOBAL rpl_semi_sync_slave_enabled = 1;
+```
+
+## 复制延迟处理
+
+### 常见延迟原因
+
+1. Slave 硬件弱于 Master
+2. 大事务（一次 DELETE/UPDATE 百万行）
+3. Slave 上存在慢查询锁竞争
+4. 单线程 SQL 回放（MySQL 5.6+ 可开启并行复制）
+
+### 并行复制配置 (MySQL 5.7+)
+
+```ini
+# my.cnf
+slave_parallel_workers = 4
+slave_parallel_type = LOGICAL_CLOCK
+```
+
+### 应用层处理延迟
+
+```sql
+-- 关键读走主库（如支付成功后的订单查询）
+-- 普通读走从库（容忍秒级延迟）
+
+-- 判断延迟：如果从库读不到数据，降级读主库
+```
+
+## 高可用方案
+
+| 方案 | 原理 | 优点 | 缺点 | 推荐场景 |
+|------|------|------|------|---------|
+| **主从 + 手动切换** | 手动执行 CHANGE MASTER | 简单 | 切换时间 10min+ | 非关键业务 |
+| **MHA** | 自动检测 Master 故障切换 | 成熟稳定 | 需独立管理节点 | 经典方案 |
+| **Orchestrator** | 自动故障检测/拓扑管理 | 自动修复 | 复杂度中等 | **推荐方案** |
+| **InnoDB Cluster** | Group Replication + MySQL Router | 原生方案 | 需 8.0+ | MySQL 官方方案 |
+| **ProxySQL + 读写分离** | 中间层路由 | 灵活路由 | 引入代理层 | 配合复制使用 |
+
+### Orchestrator 工作流程
+
+```
+1. 检测 Master 故障（心跳超时）
+2. 选择最优 Slave（延迟最小、数据最新）
+3. 自动提升为新 Master
+4. 重新配置其他 Slave 指向新 Master
+5. 通知应用层新 Master 地址（通过 API / Consul）
+```
+
+## 读写分离架构
+
+### 应用层实现
+
+```text
+// 伪代码
+if (sql.startsWith("SELECT")) {
+    connection = slavePool.getConnection();
+} else {
+    connection = masterPool.getConnection();
+}
+```
+
+### ProxySQL 实现
+
+```sql
+-- ProxySQL 配置读写分离组
+INSERT INTO mysql_replication_hostgroups 
+(writer_hostgroup, reader_hostgroup, comment) 
+VALUES (10, 20, '读写分离');
+
+-- SELECT 自动路由到从节点（reader_hostgroup=20）
+-- DML 自动路由到主节点（writer_hostgroup=10）
+```
+
+## 分库分表 (Sharding)
+
+### 何时需要分库分表
+
+单表 > 5000 万行或单实例 > 2TB 且预期继续增长。
+
+### 方案选择
+
+| 方案 | 类型 | 说明 |
+|------|------|------|
+| ShardingSphere | 中间件 + 客户端 | Java 生态首选 |
+| MyCAT | 数据库中间件 | 传统方案 |
+| Vitess | 分布式方案 | YouTube 开源 |
+| TiDB | 原生分布式 | 彻底解决但需切换数据库 |
+
+### 分库分表注意事项
+
+1. **分片键选择**：`user_id % shard_count` 或 `order_id % shard_count`
+2. **跨分片查询**：全局表、广播表、ER 分片
+3. **分布式 ID**：雪花算法、Leaf、Segment
+4. **分布式事务**：XA / TCC / Saga / Seata

package/skills/database/mysql/references/08-backup-restore.md

@@ -0,0 +1,207 @@
+# 备份与恢复 (Backup & Restore)
+
+## 简介
+
+MySQL 备份分为逻辑备份（mysqldump）和物理备份（XtraBackup）。逻辑备份导出 SQL 语句，适合小规模和迁移场景；物理备份直接复制数据文件，适合大数据库的快速恢复。
+
+## mysqldump — 逻辑备份
+
+### 基本用法
+
+```bash
+# 备份单个数据库（推荐使用 --single-transaction 避免锁表）
+mysqldump -u root -p --single-transaction --routines --triggers --events shop > shop_backup.sql
+
+# 备份所有数据库
+mysqldump -u root -p --all-databases --single-transaction > all_db_backup.sql
+
+# 只备份表结构
+mysqldump -u root -p --no-data shop > shop_schema.sql
+
+# 只备份数据
+mysqldump -u root -p --no-create-info shop > shop_data.sql
+
+# 压缩备份
+mysqldump -u root -p shop | gzip > shop_backup.sql.gz
+
+# 备份特定表
+mysqldump -u root -p shop user order product > critical_tables.sql
+
+# 备份到远程服务器
+mysqldump -u root -p shop | ssh user@backup-server "cat > /backups/shop.sql"
+```
+
+### 关键参数说明
+
+| 参数 | 说明 | 推荐 |
+|------|------|------|
+| `--single-transaction` | InnoDB 事务一致性备份，不锁表 | **必选**（InnoDB） |
+| `--lock-tables` | MyISAM 表锁 | 仅 MyISAM 时需要 |
+| `--routines` | 备份存储过程和函数 | ✅ 推荐 |
+| `--triggers` | 备份触发器 | ✅ 推荐 |
+| `--events` | 备份事件调度器 | ✅ 推荐 |
+| `--quick` | 逐行导出（防止大表内存溢出） | ✅ 大表推荐 |
+| `--opt` | 快速导出（默认开启） | 默认 |
+
+### 恢复
+
+```bash
+# 基本恢复
+mysql -u root -p shop < shop_backup.sql
+
+# 恢复压缩备份
+gunzip < shop_backup.sql.gz | mysql -u root -p shop
+
+# 恢复多个数据库
+mysql -u root -p < all_db_backup.sql
+```
+
+## XtraBackup — 物理备份
+
+Percona XtraBackup 是 MySQL 物理备份的事实标准，支持热备份 InnoDB 表而不影响读写。
+
+### 安装
+
+```bash
+# macOS
+brew install percona-xtrabackup
+
+# Ubuntu
+apt install percona-xtrabackup-80
+
+# CentOS
+yum install percona-xtrabackup-80
+```
+
+### 全量备份与恢复
+
+```bash
+# 全量备份
+xtrabackup --backup --target-dir=/data/backup/full/ --user=root --password=xxx
+
+# 准备恢复（应用 redo log，使数据一致）
+xtrabackup --prepare --target-dir=/data/backup/full/
+
+# 恢复到 MySQL 数据目录
+xtrabackup --copy-back --target-dir=/data/backup/full/
+# 或手动复制
+rsync -avrP /data/backup/full/ /var/lib/mysql/
+chown -R mysql:mysql /var/lib/mysql/
+```
+
+### 增量备份与恢复
+
+```bash
+# 全量备份（基础）
+xtrabackup --backup --target-dir=/data/backup/full/
+
+# 增量备份（基于全量）
+xtrabackup --backup --target-dir=/data/backup/inc1/ \
+  --incremental-basedir=/data/backup/full/
+
+# 第二个增量备份（基于前一个增量）
+xtrabackup --backup --target-dir=/data/backup/inc2/ \
+  --incremental-basedir=/data/backup/inc1/
+
+# 增量恢复流程
+# 1. 准备全量（应用 log 但不回滚未提交事务）
+xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full/
+
+# 2. 合并增量 1
+xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full/ \
+  --incremental-dir=/data/backup/inc1/
+
+# 3. 合并增量 2（最后一次不用 --apply-log-only）
+xtrabackup --prepare --target-dir=/data/backup/full/ \
+  --incremental-dir=/data/backup/inc2/
+
+# 4. copy-back 恢复
+xtrabackup --copy-back --target-dir=/data/backup/full/
+```
+
+## 二进制日志与 PITR（时间点恢复）
+
+PITR（Point-In-Time Recovery）允许恢复到某个精确的时间点，是应对误操作（DROP TABLE、DELETE 全表）的核心手段。
+
+### 启用二进制日志
+
+```ini
+# my.cnf
+log_bin = /var/log/mysql/mysql-bin
+binlog_format = ROW         # ROW 格式最安全
+binlog_expire_logs_seconds = 604800  # 保留 7 天
+```
+
+### 查看二进制日志
+
+```sql
+-- 查看 Binlog 是否开启
+SHOW VARIABLES LIKE 'log_bin';
+
+-- 列出所有 Binlog 文件
+SHOW BINARY LOGS;
+
+-- 查看 Binlog 事件
+SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 10;
+
+-- 查看当前 Binlog 位置
+SHOW MASTER STATUS;
+```
+
+### PITR 恢复流程
+
+```bash
+# Step 1: 恢复最近的完整备份
+mysql -u root -p shop < shop_backup.sql
+
+# Step 2: 回放二进制日志到指定时间点
+mysqlbinlog --stop-datetime="2024-01-15 10:00:00" \
+  /var/log/mysql/mysql-bin.* | mysql -u root -p
+
+# 指定位置恢复
+mysqlbinlog --stop-position=12345 \
+  /var/log/mysql/mysql-bin.000001 | mysql -u root -p
+
+# 指定开始和结束范围
+mysqlbinlog \
+  --start-datetime="2024-01-15 09:00:00" \
+  --stop-datetime="2024-01-15 10:00:00" \
+  /var/log/mysql/mysql-bin.000001 \
+  /var/log/mysql/mysql-bin.000002 \
+  | mysql -u root -p shop
+```
+
+## 备份策略推荐
+
+### 生产环境备份策略
+
+```
+┌──────────────────────────────────────────────┐
+│ 生产环境备份策略：                              │
+│                                               │
+│ 每日凌晨 2:00: 全量备份 (XtraBackup 物理备份)    │
+│ 每 6 小时:      增量备份 (XtraBackup 增量)       │
+│ 实时:           二进制日志持续归档 (BINLOG)       │
+│ 保留周期:       最近 7 天全量 + 30 天增量         │
+│ 异地备份:       备份文件同步到对象存储 (OSS/S3)    │
+│ 定期演练:       每月一次恢复测试                   │
+└──────────────────────────────────────────────┘
+```
+
+### 备份检查清单
+
+- [ ] 全量备份是否成功（检查 `xtrabackup` 退出码）
+- [ ] 备份文件大小是否合理（过大/过小要排查）
+- [ ] 异地备份是否同步完成
+- [ ] 二进制日志是否连续不中断
+- [ ] 每月恢复演练验证备份可用性
+- [ ] 备份保留策略是否符合合规要求
+
+## 注意事项
+
+- **不要只依赖一种备份方式**：逻辑备份 + 物理备份 + Binlog 三者配合
+- **测试恢复**：定期在测试环境演练恢复流程，确保备份可用
+- **监控备份状态**：通过脚本监控备份成功率，发送告警
+- **备份加密**：敏感数据的备份文件应加密存储
+- **备份压缩**：物理备份建议用 `--compress` 参数，可节省 3-5 倍存储空间
+- **mysqldump 对超大表（> 50GB）不适用**：导出和导入都极慢，建议用 XtraBackup