数据库深度专题：原理与实践 on PlumePHP

13. NewSQL 与分布式数据库

Fri, 14 Aug 2026 16:13:00 +0800

1. CAP 与 BASE

CAP 定理: 分布式系统中不可能同时满足
 Consistency（一致性）
 Availability（可用性）
 Partition Tolerance（分区容错）

BASE 理论（妥协）:
 Basically Available（基本可用）
 Soft state（软状态）
 Eventually consistent（最终一致）

2. Spanner

Google 的全球分布式数据库：

12. SQL 注入与安全防护

Fri, 14 Aug 2026 16:12:00 +0800

1. 注入类型

-- 联合注入
' UNION SELECT password FROM users --

-- 布尔盲注
' AND 1=1 --
' AND 1=2 --

-- 时间盲注
' AND IF(1=1, SLEEP(5), 0) --

-- 堆叠注入
'; DROP TABLE users; --

2. 防御

方法	说明
参数化查询	`?` 占位符，预编译
ORM	框架自动转义
输入验证	白名单校验
最小权限	应用账号只给必要权限
WAF	检测 SQL 关键字

// ❌ 拼接 SQL
String sql = "SELECT * FROM users WHERE name = '" + name + "'";

// ✅ 参数化
String sql = "SELECT * FROM users WHERE name = ?";
pstmt.setString(1, name);

11. 数据库设计范式与反范式

Fri, 14 Aug 2026 16:11:00 +0800

1. 范式定义

**范式（Normalization）**是关系数据库设计的一套标准，用于减少数据冗余、避免更新异常。每提升一级范式，约束条件更严格。

10. 读写分离与分库分表

Fri, 14 Aug 2026 16:10:00 +0800

1. 读写分离架构

1.1 为什么需要读写分离

大多数业务场景读多写少（读:写 ≈ 8:1 ~ 50:1）。将读请求分发到多个从库，可线性扩展读性能。

单库架构的问题：

 App ──→ MySQL
 │
 ├── 读请求（80% CPU）
 └── 写请求（20% CPU）
 
 读请求增加 → CPU 100% → 所有请求变慢

读写分离架构：

 写请求 ──→ [Master] ──→ 异步复制 ──→ [Slave 1]
 ──→ [Slave 2]
 ──→ [Slave 3]
 
 读请求 ──→ [负载均衡器] ──→ Slave 1 / Slave 2 / Slave 3

1.2 实现方式

方式	原理	代表产品	侵入性
代理层	独立进程解析 SQL 路由	MySQL Router、ProxySQL、MaxScale	无
中间件	分库分表中间件内置读写分离	ShardingSphere、MyCat	低
应用层	代码中配置多数据源	Spring RoutingDataSource	高

// Spring Boot 应用层读写分离
@Configuration
public class DataSourceConfig {
 @Bean
 public DataSource routingDataSource(
 @Qualifier("masterDataSource") DataSource master,
 @Qualifier("slaveDataSource") DataSource slave) {
 DynamicRoutingDataSource routing = new DynamicRoutingDataSource();
 Map<Object, Object> targets = new HashMap<>();
 targets.put("master", master);
 targets.put("slave", slave);
 routing.setTargetDataSources(targets);
 routing.setDefaultTargetDataSource(master);
 return routing;
 }
}

// Service 方法指定数据源
@Transactional(readOnly = true) // 走 Slave
public List<Order> getOrders() { ... }

@Transactional // 走 Master
public void createOrder(Order order) { ... }

1.3 复制延迟问题

写 Master ──→ 复制到 Slave（延迟 1ms ~ 数秒）
 │
 └──→ 用户立即读 Slave → 读不到刚写入的数据！

解决策略：
1. 关键读走 Master（写入后立即读取的场景）
2. 缓存补偿（写入后先更新缓存，读时先查缓存）
3. 半同步复制（Semi-Sync：至少一个 Slave 确认后再返回）
4. 会话绑定（同一连接内写后读走 Master）

2. 分库分表

2.1 何时需要分库分表

指标	建议分片
单表数据量	> 500万行（MySQL）/ > 1亿（PostgreSQL）
单库磁盘	> 500GB
单库 QPS	> 5000（读）/ > 1000（写）
单表索引大小	> 内存容量

2.2 分片策略

策略	实现	优点	缺点
哈希分片	`hash(key) % N`	数据均匀	扩容需迁移数据
范围分片	按 ID 或时间区间	范围查询友好	热点风险
列表分片	按枚举值映射	灵活可控	需人工维护
一致性哈希	哈希环 + 虚拟节点	扩容迁移少	实现复杂

// 按用户 ID 哈希分表
String tableName = "order_" + (userId % 8); // order_0 ~ order_7

// 按月份分表
String tableName = "log_" + YearMonth.now().format(DateTimeFormatter.ofPattern("yyyyMM"));
// log_202601, log_202602, ...

2.3 ShardingSphere 实战

# shardingsphere-config.yaml
dataSources:
 ds_0: !!com.zaxxer.hikari.HikariDataSource
 jdbcUrl: jdbc:mysql://db0:3306/shop
 ds_1: !!com.zaxxer.hikari.HikariDataSource
 jdbcUrl: jdbc:mysql://db1:3306/shop

shardingRule:
 tables:
 orders:
 actualDataNodes: ds_${0..1}.orders_${0..7}
 tableStrategy:
 inline:
 shardingColumn: user_id
 algorithmExpression: orders_${user_id % 8}
 databaseStrategy:
 inline:
 shardingColumn: user_id
 algorithmExpression: ds_${user_id % 2}
 keyGenerator:
 type: SNOWFLAKE
 column: order_id

3. 分布式主键

方案	原理	优点	缺点
Snowflake	41位时间+10位机器+12位序列	趋势递增、高性能	依赖时钟
Leaf（美团）	号段模式	稳定、可控	需维护号段表
Redis 自增	INCR	简单	单点、网络开销
数据库步长	auto_increment_offset	简单	扩展性差

// Snowflake 实现（简化）
public class SnowflakeIdGenerator {
 private final long workerId;
 private long sequence = 0;
 private long lastTimestamp = -1;
 
 public synchronized long nextId() {
 long timestamp = System.currentTimeMillis();
 if (timestamp < lastTimestamp) {
 throw new RuntimeException("Clock moved backwards");
 }
 if (timestamp == lastTimestamp) {
 sequence = (sequence + 1) & 0xFFF; // 12 bit
 if (sequence == 0) timestamp = tilNextMillis();
 } else {
 sequence = 0;
 }
 lastTimestamp = timestamp;
 return ((timestamp - EPOCH) << 22) | (workerId << 12) | sequence;
 }
}

4. 数据迁移

双写迁移方案（不停机）：

阶段 1：双写
 应用同时写入旧库和新库（新库异步）
 读仍然走旧库

阶段 2：数据校验 + 补平
 对比旧库和新库数据差异
 修复不一致数据

阶段 3：灰度切读
 1% 流量读新库 → 10% → 50% → 100%
 监控错误率和延迟

阶段 4：切写
 写操作切换到新库
 停止旧库写入

阶段 5：下线旧库
 保留一段时间后归档删除

09. 主从复制与数据同步

Fri, 14 Aug 2026 16:09:00 +0800

1. 复制架构

 ┌──────────────┐
 │ Client │
 └──────┬───────┘
 │
 ┌─────▼─────┐
 │ Master │ ← 处理写请求，记录 binlog
 │ (主库) │
 └─────┬─────┘
 │ binlog dump
 ┌─────────────┼─────────────┐
 ↓ ↓ ↓
 ┌────────┐ ┌────────┐ ┌────────┐
 │ Slave 1│ │ Slave 2│ │ Slave 3│ ← 读请求
 │(IO线程) │ │(IO线程) │ │(IO线程) │
 │(SQL线程)│ │(SQL线程)│ │(SQL线程)│
 └────────┘ └────────┘ └────────┘

2. 复制模式

2.1 异步复制（Asynchronous）

Client → Master (写入成功) → 立即返回
 ↓ 后台异步
 Slave（可能有延迟）

特点：快，不阻塞客户端，但 Master 宕机时可能丢失未同步数据
MySQL 默认模式

2.2 半同步复制（Semi-Synchronous）

Client → Master (prepare) → 等待至少 1 个 Slave ACK
 ↓
 Slave (收到 relay log)
 → ACK → Master commit → 返回客户端

特点：返回慢一些，但保证至少一个 Slave 已接收数据，降低丢失风险

2.3 组复制（Group Replication）

多主或单主模式，多数派确认后提交（Paxos 协议）。
自动故障检测和切换，数据强一致。
MySQL 5.7+ 内置。

模式	一致性	性能	故障场景数据丢失
异步	最终一致	最高	可能丢失所有未同步
半同步	至少一个副本	中	最多丢失一个事务
组复制	强一致	较低	不丢失（多数派确认）

3. Binlog

3.1 格式

格式	内容	优点	缺点
STATEMENT	原始 SQL 语句	体积小	非确定性函数（UUID/ NOW()）问题
ROW	行变更前后镜像	精确、安全	体积大（UPDATE 全表时膨胀）
MIXED	混合策略	平衡	复杂

-- 推荐配置（ROW 格式）
SET GLOBAL binlog_format = 'ROW';
SET GLOBAL binlog_row_image = 'FULL'; -- FULL / MINIMAL / NOBLOB

-- ROW 格式示例
-- UPDATE users SET status = 'active' WHERE id = 1
-- binlog 记录：
-- before_image: id=1, status='inactive'
-- after_image: id=1, status='active'

3.2 GTID（全局事务标识）

GTID = Master_UUID:Transaction_Sequence

示例：
 a1b2c3d4-e5f6-7890-abcd-ef1234567890:1-100
 
优势：
 - 自动定位复制位点，避免 file:position 管理
 - 故障切换更简单（CHANGE MASTER TO ... AUTO_POSITION=1）
 - 避免跳过事务导致的脑裂

4. 复制延迟

4.1 延迟原因

原因	说明
单线程 SQL 线程	经典 MySQL 只有 1 个 SQL 线程重放
大事务	一个事务修改大量行，Slave 重放慢
Slave 性能差	Slave 硬件弱于 Master
锁竞争	Slave 上也有读请求，与 SQL 线程竞争

4.2 并行复制

-- MySQL 5.7+ 并行复制配置
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL slave_parallel_workers = 8; -- SQL 线程数

-- LOGICAL_CLOCK：基于组提交（同一时刻提交的事务可并行）
-- DATABASE：基于库级别并行（不同库的事务并行）

4.3 监控延迟

-- 查看延迟
SHOW SLAVE STATUS\G
-- Seconds_Behind_Master: 0 ← 延迟秒数

-- 更精确的方法（pt-heartbeat）
-- Master 每秒写 heartbeat 表，Slave 计算差值

08. 连接池设计与原理

Fri, 14 Aug 2026 16:08:00 +0800

1. 为什么需要连接池

1.1 数据库连接的代价

创建一条数据库连接是昂贵的操作：

TCP 三次握手（~1-3ms，跨可用区更长）

TLS/SSL 握手（如有，~5-20ms）

数据库认证（密码验证、权限查询）

内存分配（数据库端为连接分配会话内存）

无连接池 vs 连接池：

无连接池：
 每次请求 ──→ 新建连接 ──→ 执行 SQL ──→ 关闭连接
 ↑ ↓
 └──── 每次 5-20ms ────┘

连接池：
 初始化：创建 10 条连接放入池中
 
 每次请求 ──→ 从池获取连接（< 1ms）──→ 执行 SQL ──→ 归还连接
 ↑ ↓
 └────────── 复用，无创建开销 ──────────┘

1.2 连接池核心收益

收益	说明
降低延迟	避免每次请求建立连接的开销
资源控制	限制最大连接数，防止数据库过载
连接复用	减少数据库端会话资源消耗
稳定性	预热连接、健康检查保障可用性

2. 连接池核心参数

2.1 参数详解

参数	作用	建议值
minimumIdle	最小空闲连接数	5-10（保持热连接）
maximumPoolSize	最大连接数	20-50（取决于 DB 配置）
connectionTimeout	获取连接最大等待时间	30s
idleTimeout	空闲连接超时回收	10min
maxLifetime	连接最大存活时间	30min（短于 DB wait_timeout）
keepaliveTime	保活检查间隔	5min

2.2 最大连接数设置

公式：连接池大小 = ((核心数 × 2) + 有效磁盘数)

更精确的计算：
 连接数 = (CPU 核心数 × 2) + 磁盘 spindle 数

示例（HikariCP 作者建议）：
 4 核服务器 → 约 10 个连接即可获得最大吞吐
 连接数再多，由于上下文切换和锁竞争，吞吐反而下降

生产环境经验：
 单机应用：10-20 连接
 微服务集群（10 实例 × 10 连接）：需 DB 支持 100+ 连接
 MySQL max_connections 默认 151，需按规模调整

3. 主流连接池对比

3.1 HikariCP（推荐）

“Fast, simple, reliable. Zero overhead.”

07. 查询优化与执行计划

Fri, 14 Aug 2026 16:07:00 +0800

1. 查询执行流程

SQL 语句
 → 词法/语法分析 → 解析树（Parse Tree）
 → 语义检查（表/列存在性、权限）
 → 查询重写（视图展开、子查询优化、常量传播）
 → 生成候选执行计划
 → 代价估算（统计信息 + 代价模型）
 → 选择最优计划
 → 执行引擎执行

2. EXPLAIN 详解

2.1 EXPLAIN 输出列

EXPLAIN ANALYZE
SELECT e.name, d.name, SUM(s.amount)
FROM employees e
JOIN departments d ON e.dept_id = d.id
JOIN sales s ON e.id = s.emp_id
WHERE s.date > '2024-01-01'
GROUP BY e.id, d.name;

列	说明	关键值
`id`	执行顺序编号	相同 id 从上到下执行
`select_type`	查询类型	SIMPLE/PRI/ SUBQUERY/DERIVED
`table`	访问的表	别名/子查询
`type`	访问类型	ALL < index < range < ref < eq_ref < const
`possible_keys`	可能用的索引
`key`	实际用的索引
`key_len`	索引使用长度	越短越好（但需完整匹配）
`ref`	索引对比值	const/列名
`rows`	估算扫描行数	越小越好
`filtered`	过滤后剩余比例	越高越好
`Extra`	额外信息	Using index 好，Using filesort 差

2.2 type 列优化目标

type	说明	场景
`system`	系统表，仅一行	极罕见
`const`	主键/唯一索引等值	`WHERE id = 1`
`eq_ref`	JOIN 主键/唯一索引	JOIN 条件为主键
`ref`	普通索引等值	`WHERE status = 'active'`
`range`	索引范围	`WHERE id BETWEEN 1 AND 100`
`index`	全索引扫描	索引覆盖 SELECT 列
`ALL`	全表扫描	无索引或索引未命中

优化目标：至少要达到 range，最好是 ref 或 eq_ref。

06. 锁机制与死锁处理

Fri, 14 Aug 2026 16:06:00 +0800

1. 锁粒度

锁类型	粒度	并发度	开销	代表
表锁	整张表	最低	最低	MyISAM
页锁	一页（通常 4KB/8KB）	中等	中等	BDB
行锁	单行记录	最高	最高	InnoDB

InnoDB 默认使用行锁，但在特定场景下会退化为表锁（如未命中索引的全表扫描）。

05. MVCC 多版本并发控制

Fri, 14 Aug 2026 16:05:00 +0800

1. MVCC 核心思想

MVCC（Multi-Version Concurrency Control） 通过保存数据的多个历史版本，实现 读不阻塞写、写不阻塞读，避免加锁带来的并发性能损失。

04. 事务 ACID 与隔离级别

Fri, 14 Aug 2026 16:04:00 +0800

1. ACID 属性

1.1 四大特性

属性	含义	InnoDB 实现机制
Atomicity（原子性）	事务要么全完成，要么全不完成	Undo Log（回滚日志）
Consistency（一致性）	事务前后数据库处于一致状态	约束、触发器、外键、业务规则
Isolation（隔离性）	并发事务互不干扰	MVCC + 锁
Durability（持久性）	事务提交后数据永久保存	Redo Log + WAL（预写日志）

1.2 InnoDB 的事务日志

Undo Log（回滚日志）：
 - 记录数据修改前的旧值
 - 事务回滚时，用 Undo Log 恢复数据
 - 作用：原子性 + MVCC 版本链

Redo Log（重做日志）：
 - 记录数据修改后的新值
 - 事务提交时，先写 Redo Log，再刷脏页
 - 作用：持久性（崩溃恢复）

Write-Ahead Logging (WAL)：
 - 先写日志，再写磁盘
 - 日志顺序写（快） vs 数据页随机写（慢）
 - Redo Log 顺序写提高性能，同时保证不丢数据

2. 四种隔离级别

SQL 标准定义了四种隔离级别，从低到高限制越来越严格，但并发性能逐渐降低。

03. B+ 树索引原理

Fri, 14 Aug 2026 16:03:00 +0800

1. 为什么需要 B+ 树

1.1 磁盘 I/O 问题

数据库的数据存储在磁盘上，磁盘 I/O 是性能瓶颈。B+ 树的设计目标是减少磁盘 I/O 次数。

磁盘读取特点：
- 顺序读：快（磁盘预读）
- 随机读：慢（磁头寻道时间 ~ 10ms）
- 最小读取单位：页（Page，通常 4KB/8KB/16KB）

B+ 树通过让树尽可能"矮胖"，减少随机 I/O：
 树高 3 → 最多 2 次随机 I/O（根→叶子）
 树高 4 → 最多 3 次随机 I/O
 
对于 2000 万行数据（InnoDB，16KB 页）：
 每页存储约 1170 个 key（假设 key 为 8B + 指针 6B）
 树高 3 可存储：1170 × 1170 × 16 ≈ 2190 万行

1.2 B-Tree vs B+Tree

B-Tree：
 [10, 20]
 / | \
 [5,8] [15,18] [25,30]
 数据存储在所有节点（内部节点也存数据）
 问题：内部节点大，树变高

B+Tree（数据库标准）：
 [10, 20] ← 内部节点：只存 key 用于导航
 / | \
 [5,8] [15,18] [25,30] → 叶子节点：存 key + 数据，且叶子间有链表
 叶子节点通过链表连接，范围查询高效

特性	B-Tree	B+Tree
数据存储	所有节点	仅叶子节点
叶子链表	无	有（范围查询友好）
树高	较高	更矮
全表扫描	遍历整棵树	仅遍历叶子
空间利用率	较低	更高

2. InnoDB 索引结构

2.1 聚簇索引（Clustered Index）

聚簇索引就是表本身。数据行按主键顺序存储在 B+ 树的叶子节点中。

02. 关系模型与 SQL 基础

Fri, 14 Aug 2026 16:02:00 +0800

1. 关系代数

关系数据库基于关系代数，核心操作：

操作	SQL 对应	说明
σ (选择)	WHERE	按条件过滤行
π (投影)	SELECT	选择列
⋈ (连接)	JOIN	表关联
∪ (并)	UNION	合并结果集
− (差)	EXCEPT	差集
ρ (重命名)	AS	别名

2. SQL 核心语法

-- 条件聚合
SELECT
 department,
 COUNT(*) AS total_employees,
 COUNT(CASE WHEN salary > 100000 THEN 1 END) AS high_earners,
 AVG(salary) FILTER (WHERE status = 'active') AS avg_salary
FROM employees
GROUP BY department
HAVING COUNT(*) > 5;

-- 窗口函数
SELECT
 name,
 department,
 salary,
 RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS dept_rank,
 salary - AVG(salary) OVER (PARTITION BY department) AS diff_from_avg,
 SUM(salary) OVER (ORDER BY hire_date) AS running_total
FROM employees;

-- CTE 递归查询（组织架构）
WITH RECURSIVE org_tree AS (
 SELECT id, name, manager_id, 0 AS level
 FROM employees WHERE manager_id IS NULL
 UNION ALL
 SELECT e.id, e.name, e.manager_id, ot.level + 1
 FROM employees e
 JOIN org_tree ot ON e.manager_id = ot.id
)
SELECT * FROM org_tree;

01. 数据库系统概述与分类

Fri, 14 Aug 2026 16:01:00 +0800

1. 数据库分类全景

数据库系统
 ├── 关系型数据库 (RDBMS)
 │ ├── 商业：Oracle、SQL Server、DB2
 │ ├── 开源：PostgreSQL、MySQL、MariaDB
 │ └── 特点：ACID、SQL、强一致性、成熟生态
 │
 ├── NoSQL 数据库
 │ ├── 文档型：MongoDB、CouchDB、Firestore
 │ ├── 键值型：Redis、DynamoDB、Riak
 │ ├── 列族型：Cassandra、HBase、ScyllaDB
 │ ├── 图数据库：Neo4j、Dgraph、JanusGraph
 │ └── 搜索引擎：Elasticsearch、OpenSearch
 │
 ├── NewSQL 数据库
 │ ├── Google Spanner、CockroachDB、TiDB、YugabyteDB
 │ └── 特点：水平扩展 + ACID + SQL 兼容
 │
 └── 专用数据库
 ├── 时序数据库：InfluxDB、TimescaleDB、TDengine
 ├── 向量数据库：Pinecone、Milvus、pgvector
 └── 内存数据库：Redis、SAP HANA、MemSQL

2. OLTP vs OLAP

维度	OLTP（在线事务处理）	OLAP（在线分析处理）
用途	日常业务操作	数据分析、报表、决策支持
数据规模	GB ~ TB	TB ~ PB
查询模式	点查、短事务、少量行	全表扫描、聚合、多表 JOIN
写入	高并发随机写入	批量导入、ETL
更新	频繁 UPDATE/DELETE	mostly 追加（Append-only）
响应时间	毫秒级	秒 ~ 分钟级
代表	MySQL、PostgreSQL、Oracle	ClickHouse、Snowflake、BigQuery

3. NoSQL 选型指南

类型	数据模型	适用场景	代表产品
文档型	JSON/BSON 文档	内容管理、用户资料、 catalogs	MongoDB
键值型	key-value	缓存、会话、购物车	Redis、DynamoDB
列族型	宽列存储	时序数据、日志、IoT	Cassandra
图数据库	节点 + 边	社交网络、知识图谱、推荐	Neo4j
搜索引擎	倒排索引	全文检索、日志分析	Elasticsearch

4. 选型决策树

需要水平扩展？
 ├── 是 → 需要 ACID 事务？
 │ ├── 是 → NewSQL (TiDB/CockroachDB/Spanner)
 │ └── 否 → NoSQL
 │ ├── 键值查询为主 → Redis/DynamoDB
 │ ├── 文档模型 → MongoDB
 │ ├── 时序数据 → InfluxDB/TimescaleDB
 │ └── 图关系 → Neo4j
 └── 否 → 复杂分析查询为主？
 ├── 是 → ClickHouse/DuckDB/Snowflake
 └── 否 → PostgreSQL / MySQL
 ├── 需要高级功能（JSON/全文/GIS）→ PostgreSQL
 └── 追求简单、广泛兼容 → MySQL

PostgreSQL 被称为"世界上最先进的开源关系型数据库"，功能丰富（JSONB、数组、范围类型、全文检索、GIS 扩展），适合作为大多数应用的首选数据库。

备份恢复与高可用方案

Thu, 13 Aug 2026 11:35:00 +0800

数据是企业最核心的资产。完善的备份恢复策略与高可用架构是保障数据安全、业务连续性的底线工程。本文系统讲解 MySQL 备份恢复方案与高可用架构选型。

1. 备份策略设计

1.1 备份维度

维度	策略	RPO	RTO
全量备份	每周/每日全备	24h	小时级
增量备份	XtraBackup 增量 + Binlog	小时级	分钟级
实时复制	主从同步 + Binlog	秒级	秒级
跨地域备份	异地机房/云存储	取决于同步	分钟级

1.2 321 备份原则

3 份数据副本
2 种不同存储介质
1 份异地备份

2. 物理备份：Percona XtraBackup

2.1 特点

热备份：不锁表或只锁很短时间
支持增量备份
支持流式压缩备份
支持并行备份

2.2 全量备份

# 全量备份
xtrabackup --backup --target-dir=/backup/full/$(date +%Y%m%d) \
 --user=backup --password=xxx --host=localhost

# 备份过程：
# 1. 拷贝 InnoDB 数据文件（不锁表）
# 2. 执行 FLUSH TABLES WITH READ LOCK（FTWRL）复制非 InnoDB 文件
# 3. 记录 Binlog 位点（用于恢复时点）
# 4. 解锁

2.3 增量备份

# 周日全量
xtrabackup --backup --target-dir=/backup/full

# 周一增量（基于周日全量）
xtrabackup --backup --target-dir=/backup/inc1 \
 --incremental-basedir=/backup/full

# 周二增量（基于周一增量）
xtrabackup --backup --target-dir=/backup/inc2 \
 --incremental-basedir=/backup/inc1

# 恢复：准备（apply log）→ 合并 → 恢复
xtrabackup --prepare --apply-log-only --target-dir=/backup/full
xtrabackup --prepare --apply-log-only --target-dir=/backup/full \
 --incremental-dir=/backup/inc1
xtrabackup --prepare --target-dir=/backup/full \
 --incremental-dir=/backup/inc2

# 拷贝恢复
xtrabackup --copy-back --target-dir=/backup/full \
 --datadir=/var/lib/mysql

2.4 流式备份到远程

# 压缩流式备份到远程
xtrabackup --backup --stream=xbstream --compress \
 | ssh backup-server "xbstream -x -C /backup/"

# 或使用 nc/socat

3. 逻辑备份：mysqldump / mydumper

3.1 mysqldump

# 全库逻辑备份（单线程，适合小库）
mysqldump -u root -p --all-databases --single-transaction \
 --routines --triggers --events > full_backup.sql

# 关键参数：
# --single-transaction: 开启事务一致性备份（InnoDB）
# --master-data=2: 记录 Binlog 位点到注释
# --quick: 不缓存全表到内存（大表必选）
# --where: 条件备份

3.2 mydumper（多线程逻辑备份）

# 多线程备份（推荐大库）
mydumper -u root -p xxx -B mydb -t 4 -o /backup/mydumper/

# -t 4: 4 个线程
# 输出：每个表一个文件 + metadata（Binlog 位点）

# 恢复
myloader -u root -p xxx -d /backup/mydumper/ -t 4 -B mydb

3.3 物理 vs 逻辑备份对比

维度	物理备份（XtraBackup）	逻辑备份（mysqldump）
速度	快（文件拷贝）	慢（逐行导出）
大小	紧凑（数据文件）	较大（文本+INSERT）
恢复速度	极快	慢
跨版本	有限制	兼容性好
部分恢复	难	容易（单表恢复）
增量备份	支持	不支持
适用	大库、生产环境	小库、数据迁移

4. 基于 Binlog 的 PITR（时间点恢复）

4.1 原理

全量备份（周日 00:00）
 │
 ▼
恢复全量 ──► 应用增量（周一、周二）
 │
 ▼
 应用 Binlog（精确到秒）
 │
 ▼
 恢复到"误删前 1 秒"

4.2 恢复步骤

# 1. 恢复全量 + 增量（见上节）

# 2. 查找目标 Binlog 文件和位点
mysqlbinlog /var/lib/mysql/binlog.000042 | grep -i "DROP TABLE"
# 找到误操作的位点：2024-01-15 14:30:25

# 3. 应用 Binlog 到目标位点前
mysqlbinlog --start-position=xxx --stop-datetime="2024-01-15 14:30:24" \
 /var/lib/mysql/binlog.000042 /var/lib/mysql/binlog.000043 \
 | mysql -u root -p

4.3 延迟从库（预防误操作最佳实践）

# 配置延迟从库（延迟 1 小时）
[mysqld]
replica_parallel_workers = 4

CHANGE REPLICATION SOURCE TO
 SOURCE_DELAY = 3600; -- 延迟 3600 秒

# 误操作后可快速从延迟从库恢复

5. 高可用架构方案

5.1 主从复制（基础）

Master ──► Binlog ──► Slave
 │ │
 │ └── 只读查询、备份
 └── 写请求

复制模式：
- 异步复制：Master 不等待 Slave 确认（默认，可能丢数据）
- 半同步复制：Master 等至少一个 Slave ACK（减少丢数据风险）
- 组复制：Multi-Master（MySQL 8.0 Group Replication）

5.2 MHA（Master High Availability）

架构：
Manager 节点（监控+决策）
 │
 ├── Master (写)
 ├── Slave1 (候选新主)
 └── Slave2 (从)

故障检测：Manager 定期 ping 所有节点
故障转移：
 1. 检测到 Master 不可达
 2. 从 Slaves 中选举最新数据的节点
 3. 应用差异 Binlog（relay log）
 4. 提升为新的 Master
 5. 其他 Slaves 重新指向新 Master
 
切换时间：通常 10-30 秒

局限：Manager 单点、需要 SSH 免密、只支持一主多从

5.3 Orchestrator（推荐）

优势（相比 MHA）：
1. 可视化拓扑管理（Web UI）
2. 支持 GTID 和普通复制
3. 可以处理复杂拓扑（级联复制）
4. sophisticated 故障检测（避免网络抖动误判）
5. 手工/自动故障转移都支持
6. 支持 Pre-failover hooks（自定义逻辑）

部署：
docker run -d --name orchestrator \
 -p 3000:3000 \
 openarkcode/orchestrator

关键配置：
"RecoveryMasterPromotionIgnoreHostnameFilters": [],
"RecoverMasterClusterFilters": [".*"],
"RecoveryPeriodBlockSeconds": 3600 # 故障恢复后禁止再次切换的时间

5.4 MySQL Group Replication（MGR）

原生高可用（MySQL 5.7+）：

Primary-Secondary 模式：
 Primary: 读写
 Secondary × N: 只读（自动复制）
 
 Primary 故障 → 自动选举新 Primary（基于 Paxos 算法）

Multi-Primary 模式：
 多个节点都可读写
 冲突检测：Certification-based
 局限：不支持 SERIALIZABLE、外键需小心

配置要点：
group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
group_replication_local_address = "node1:33061"
group_replication_group_seeds = "node1:33061,node2:33061,node3:33061"
group_replication_single_primary_mode = ON

5.5 方案对比

方案	自动故障转移	数据一致性	复杂度	适用
主从手动	❌	异步	低	非核心系统
MHA	✅	半同步可选	中	中大型系统
Orchestrator	✅	配置灵活	中	推荐方案
MGR	✅	强一致（多数派）	中	MySQL 8.0+
MySQL Router	✅	取决于后端	低	配合 MGR
ProxySQL	✅	配置灵活	中	读写分离 + 故障转移

6. 读写分离架构

 ┌──► Read Replica 1
App ──► ProxySQL ├──► Read Replica 2
 │ (读负载均衡)
 └──► Master (写)
 
ProxySQL 规则：
- SELECT ... FOR UPDATE → Master
- SELECT * FROM ... → Replica
- INSERT/UPDATE/DELETE → Master
- 自定义规则（按用户、Schema、查询 pattern）

7. 灾难恢复演练

7.1 定期演练计划

演练类型	频率	内容
全量恢复	每季度	从备份恢复到测试环境，验证可用
PITR 恢复	每半年	恢复到指定时间点，验证精度
故障切换	每月	模拟主库宕机，验证自动切换
跨区域恢复	每年	从异地备份恢复完整环境

7.2 恢复时间目标

分级	RTO	RPO	方案
核心业务	< 5min	< 1min	MGR + 异地热备
重要业务	< 30min	< 1h	MHA/Orchestrator + Binlog
一般业务	< 4h	< 24h	定时备份 + 手动恢复

8. 总结

数据库备份与高可用是系统工程：

数据库性能监控与诊断

Thu, 13 Aug 2026 11:30:00 +0800

数据库是系统核心组件，其性能直接影响用户体验。建立完善的监控与诊断体系，是 DBA 和 SRE 的核心能力。本文系统讲解 MySQL 性能监控的完整工具链与实践方法。

1. 监控指标体系

1.1 黄金指标（Google SRE 方法论）

指标类型	具体指标	说明
流量	QPS/TPS、连接数、Threads_connected	系统负载
延迟	查询耗时 P50/P95/P99、慢查询率	响应速度
错误	错误查询数、死锁数、锁等待超时	失败比例
饱和度	CPU、内存、磁盘 IO、Buffer Pool 命中率	资源瓶颈

1.2 关键公式

QPS = Queries / Uptime
TPS = (Com_commit + Com_rollback) / Uptime

Buffer Pool 命中率 = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)
 值 > 95% 为健康

慢查询占比 = Slow_queries / Queries × 100%
 应 < 1%，否则需要优化

2. Performance Schema

MySQL 5.5+ 内置的性能监控框架，低开销采集运行时数据。

NewSQL 选型对比

Thu, 13 Aug 2026 11:25:00 +0800

NewSQL 是一类兼顾关系型数据库的 ACID 事务与 NoSQL 水平扩展能力的分布式数据库。随着 TiDB、CockroachDB 等系统的成熟，NewSQL 正从理论走向大规模生产。本文对比主流 NewSQL 数据库，帮助团队做出合理选型。

Redis 高级实战

Thu, 13 Aug 2026 11:20:00 +0800

Redis 不仅是缓存，更是高性能数据结构服务。从单机到集群、从基础数据结构到企业级治理，本文深入 Redis 高级特性与生产实践。

1. Redis 数据结构原理

1.1 底层实现速查

用户类型	编码方式	场景
String	SDS / int / embstr	缓存、计数器
List	quicklist（3.2+）	队列、时间线
Hash	ziplist / hashtable	对象存储
Set	intset / hashtable	标签、去重
ZSet	ziplist / skiplist+hashtable	排行榜、延迟队列
Stream	radix tree	消息队列
Bitmap / Bitfield	raw string	签到、统计
HyperLogLog	稀疏/稠密编码	UV 统计
GEO	zset + geohash	位置服务
BloomFilter	RedisBloom 模块	去重判断

1.2 跳表（Skip List）：ZSet 的秘密

ZSet 同时维护跳表 + 哈希表：

Hash: { member → score } O(1) 查找 score
Skip List: 按 score 排序的分层链表 O(log n) 范围查询

跳表示例（ZSet 的 skiplist）：

Level 3: head ───────────────────────► 100
Level 2: head ───────────► 30 ───────► 100
Level 1: head ──► 10 ──► 30 ──► 50 ──► 100
Level 0: head ─► 10 ─► 20 ─► 30 ─► 50 ─► 100
 ▼
 有序遍历

跳表相比平衡树：实现简单、范围查询高效、并发修改更容易。

TiDB 架构深度解析

Thu, 13 Aug 2026 11:15:00 +0800

TiDB 是 PingCAP 开源的分布式 NewSQL 数据库，兼容 MySQL 协议，具备水平扩展、强一致性、高可用等特性。其架构深受 Google Spanner/F1 启发，融分布式存储、调度、计算于一体。本文深入解析 TiDB 各核心组件的设计原理。

HTAP 与 OLTP/OLAP 融合

Thu, 13 Aug 2026 11:10:00 +0800

传统数据库架构将在线事务处理（OLTP）和分析处理（OLAP）分离：核心业务数据存储于 MySQL/PostgreSQL 等行存数据库，批量导入数据仓库进行报表分析。这种架构存在数据延迟、架构复杂等问题。HTAP（Hybrid Transactional/Analytical Processing）旨在用一套系统同时高效处理两种负载。本文从存储引擎原理到工程实践全面解析 HTAP。

分布式事务（2PC/3PC/TCC/Saga）

Thu, 13 Aug 2026 11:05:00 +0800

单体数据库的事务通过 ACID 保证，但当数据分布在多个数据库或服务中时，如何保证跨节点的事务一致性？分布式事务是微服务架构和分库分表场景下的核心挑战。本文全面解析主流分布式事务协议和工程实践。

分库分表实战

Thu, 13 Aug 2026 11:00:00 +0800

当单库数据量超过千万级、QPS 超过数千时，单节点数据库会成为系统瓶颈。分库分表（Sharding）是解决单机数据库性能与容量限制的核心方案。本文系统讲解拆分策略、分片键设计、中间件选型和扩容迁移方案。

索引设计与 B+ 树原理

Thu, 13 Aug 2026 10:50:00 +0800

索引是数据库性能优化的基石，而 InnoDB 使用 B+ 树作为核心索引结构。本文从底层原理出发，解析 B+ 树的结构设计、聚簇索引与二级索引的差异、哈希索引的应用场景，以及实际开发中的高级索引优化策略。

MVCC 多版本并发控制

Thu, 13 Aug 2026 10:45:00 +0800

MVCC（Multi-Version Concurrency Control，多版本并发控制）是 InnoDB 实现高并发读写不阻塞的核心机制。通过为每行数据维护多个版本，SELECT 读取不需加锁即可获取一致性快照，大幅提高并发性能。本文深入解析 MVCC 的底层实现。

事务与 ACID 原理

Thu, 13 Aug 2026 10:40:00 +0800

事务（Transaction）是数据库管理系统执行过程中的一个逻辑单位，由一个或多个 SQL 语句组成。事务的 ACID 特性是关系型数据库可靠性的基石，也是从单机走向分布式系统时面临的核心挑战。本文深入讲解 ACID 的每一项特性及其在 MySQL InnoDB 中的实现机制。

MySQL InnoDB 存储引擎深度解析

Thu, 13 Aug 2026 10:35:00 +0800

MySQL 是最流行的开源关系型数据库之一，而 InnoDB 作为 MySQL 5.5 版本起默认的存储引擎，凭借其高可靠性、高性能和丰富的功能特性，成为绝大多数 OLTP 系统的首选。本文将深入剖析 InnoDB 的核心架构与关键组件，帮助读者理解其底层工作原理。

ClickHouse 深入解析与实战

Mon, 03 Nov 2025 15:01:42 +0800

第一章　ClickHouse 概述与发展历程（ClickHouse Overview and Evolution）

1.1　诞生背景与设计初衷

一、从日志到分析的痛点

在 2010 年前后，互联网企业的流量监控与日志分析体系大多依赖于 Hadoop + Hive 模型：

clickhouse和tidb对比分析

Mon, 03 Nov 2025 15:00:42 +0800

一、总览对比

对比维度	ClickHouse	TiDB
类型定位	OLAP（在线分析处理）列式数据库	HTAP（混合事务 + 分析）分布式数据库
架构风格	Shared-Nothing 列存计算引擎	分布式事务数据库，兼容 MySQL 协议
主要用途	实时数据分析、BI 报表、大数据聚合	事务型业务 + 分析查询融合、OLTP/OLAP 混合
数据存储	列存 + 压缩 + 向量化计算	行存（TiKV）+ 列存（TiFlash）
事务特性	弱事务（单表、单节点）	完整分布式事务（两阶段提交）
扩展方式	水平扩展节点（Shard + Replica）	水平扩展 TiKV、TiFlash 节点
SQL 兼容	类似 ANSI SQL（不完全兼容 MySQL）	高度兼容 MySQL 语法
典型用户	Yandex、Cloudflare、腾讯、字节跳动	PingCAP、知乎、Shopee、Bilibili
场景类型	日志分析、指标聚合、BI 看板	在线业务数据库、OLTP+OLAP 混合

一句话总结：

数据库深度专题：原理与实践 on PlumePHP

13. NewSQL 与分布式数据库

1. CAP 与 BASE

2. Spanner

12. SQL 注入与安全防护

1. 注入类型

2. 防御

延伸阅读

11. 数据库设计范式与反范式

1. 范式定义

10. 读写分离与分库分表

1. 读写分离架构

1.1 为什么需要读写分离

1.2 实现方式

1.3 复制延迟问题

2. 分库分表

2.1 何时需要分库分表

2.2 分片策略

2.3 ShardingSphere 实战

3. 分布式主键

4. 数据迁移

延伸阅读

09. 主从复制与数据同步

1. 复制架构

2. 复制模式

2.1 异步复制（Asynchronous）

2.2 半同步复制（Semi-Synchronous）

2.3 组复制（Group Replication）

3. Binlog

3.1 格式

3.2 GTID（全局事务标识）

4. 复制延迟

4.1 延迟原因

4.2 并行复制

4.3 监控延迟

延伸阅读

08. 连接池设计与原理

1. 为什么需要连接池

1.1 数据库连接的代价

1.2 连接池核心收益

2. 连接池核心参数

2.1 参数详解

2.2 最大连接数设置

3. 主流连接池对比

3.1 HikariCP（推荐）

07. 查询优化与执行计划

1. 查询执行流程

2. EXPLAIN 详解

2.1 EXPLAIN 输出列

2.2 type 列优化目标

06. 锁机制与死锁处理

1. 锁粒度

05. MVCC 多版本并发控制

1. MVCC 核心思想

04. 事务 ACID 与隔离级别

1. ACID 属性

1.1 四大特性

1.2 InnoDB 的事务日志

2. 四种隔离级别

03. B+ 树索引原理

1. 为什么需要 B+ 树

1.1 磁盘 I/O 问题

1.2 B-Tree vs B+Tree

2. InnoDB 索引结构

2.1 聚簇索引（Clustered Index）

02. 关系模型与 SQL 基础

1. 关系代数

2. SQL 核心语法

延伸阅读

01. 数据库系统概述与分类

1. 数据库分类全景

2. OLTP vs OLAP

3. NoSQL 选型指南

4. 选型决策树

备份恢复与高可用方案

1. 备份策略设计

1.1 备份维度

1.2 321 备份原则

2. 物理备份：Percona XtraBackup

2.1 特点

第一章　ClickHouse 概述与发展历程（ClickHouse Overview and Evolution）

1.1　诞生背景与设计初衷