从主从复制到 SQLite：数据库可靠性、安全性与本地存储的完整知识图谱

数据库真正进入生产环境之后，问题就不再只是“SQL 会不会写”。

你还需要回答更多问题：

数据库读压力越来越大，怎么扩展？
主库刚写入的数据，从库为什么可能还读不到？
主库宕机以后，数据有没有可能丢？
DBA 手滑执行了一条 DELETE，还有没有救？
没有备份、没有 Binlog，只剩 .ibd 文件怎么办？
为什么字符串拼接 SQL 会演变成安全漏洞？
为什么有些数据适合放 MySQL，有些数据却更适合放 SQLite？
浏览器本地存储为什么又分 Cookie、LocalStorage、IndexedDB、WebSQL？

把这些问题放在一起，会发现它们其实围绕数据库工程的四个核心目标展开：

可用性、可恢复性、安全性，以及数据应该存在哪里。

本文基于几篇关于 MySQL 主从复制、InnoDB 数据恢复、SQL 注入、WebSQL 和 SQLite 的资料，对这些知识重新整理，并试图建立一套比单独记概念更容易理解的数据库知识图谱。

一、先建立整体视角：数据库工程不只是 CRUD

可以把这几部分知识放到同一张图里：

目标	典型问题	核心技术
性能与可用性	单库扛不住、主库故障	主从复制、读写分离、负载均衡、MGR
可恢复性	误删、文件损坏、主库故障	Binlog、备份、延迟从库、InnoDB Force Recovery
安全性	用户输入改变 SQL 语义	参数化查询、输入校验、最小权限、关闭生产错误信息
本地化存储	数据不值得每次访问服务器	LocalStorage、IndexedDB、WebSQL、SQLite

这四条线并不是彼此独立的。

例如：

主从复制既是性能方案，也是高可用方案；
Binlog 既服务于复制，也服务于恢复；
SQLite 既减少服务器压力，也改变了应用的数据边界；
SQL 注入看起来是 Web 安全问题，本质上却是“数据被错误地解释成了代码”。

因此，理解数据库时，最好不要只按 SQL 语法分类，而应该按系统目标来理解。

二、MySQL 主从复制：解决的并不只是“读多写少”

2.1 优化数据库，不要一上来就做主从

一个很重要的工程原则是：

架构复杂度应该随着问题复杂度逐步增加。

如果数据库出现性能问题，资料给出了一条很合理的优化顺序：

SQL / 索引优化
      ↓
缓存（例如 Redis）
      ↓
主从复制 + 读写分离

为什么？

因为三者的使用和维护成本通常是逐级提高的。

如果一条 SQL 本身写得很差，索引也没有建立好，那么直接加从库，很可能只是把“低效 SQL”复制到更多机器上。

所以主从复制不是数据库性能优化的第一步，而是当单机优化和缓存仍不足以满足需求后，才应该引入的系统级能力。

2.2 主从复制的三个主要价值

1. 读写分离

典型结构是：

                ┌─────────────┐
写请求 ───────→ │   Master    │
                └──────┬──────┘
                       │
                    replication
                       │
            ┌──────────┴──────────┐
            ↓                     ↓
      ┌───────────┐         ┌───────────┐
      │  Replica1 │         │  Replica2 │
      └───────────┘         └───────────┘
            ↑                     ↑
           读请求                读请求

主库负责写，从库负责读。

对于互联网系统常见的“读多写少”场景，这种结构可以明显降低主库压力。

如果存在多个从库，还可以进一步做读请求负载均衡：

read request
     ↓
load balancer / router
   ↙    ↓    ↘
R1     R2     R3

于是三个概念就被串起来了：

主从复制：把主库的数据同步给从库；
读写分离：写主库、读从库；
负载均衡：把读请求分散到多个从库。

它们不是一回事，但经常组合出现。

2. 热备份

主库的数据持续复制到从库，相当于始终存在一份接近实时的数据副本。

这是一种热备机制。

但要注意：

复制不等于备份。

如果有人在主库执行了错误的：

1	`DELETE FROM orders;`

这个操作同样可能被复制到从库。

结果就是：

1
2
3

主库：删了
  ↓ replication
从库：也删了

所以从库可以提升冗余，却不能代替独立备份。

这也是为什么后面还需要 Binlog、时间点备份、延迟从库等手段。

3. 高可用

当主库故障时，可以把一个从库提升为新的主库，从而缩短服务不可用时间。

高可用本质上是：

用冗余资源换故障恢复能力。

可用性越高，成本通常也越高。

因此架构设计不是单纯追求“越高越好”，而是要根据业务损失、恢复目标和维护成本进行权衡。

三、MySQL 主从同步的核心：Binlog

3.1 Binlog 是什么

Binlog，即 Binary Log，记录的是数据库发生的更新事件。

可以简单理解为：

INSERT
UPDATE
DELETE
...
        ↓
      Binlog

主从复制并不是直接把整个数据文件不停地拷贝给从库，而是把主库发生的变更以日志事件的形式传递出去。

3.2 经典复制链路

资料将经典 MySQL 主从复制概括为三个关键线程：

主库：Binlog Dump Thread

负责读取 Binlog，并把日志事件发送给从库。

从库：I/O Thread

连接主库，接收 Binlog，并把内容写入本地的：

1	`Relay Log`

也就是中继日志。

从库：SQL Thread

读取 Relay Log，并重放其中的变更事件。

完整链路可以记成：

客户端
  │
  │ write
  ↓
Master
  │
  ├─ 执行事务
  │
  └─ 写 Binlog
        │
        ↓
Binlog Dump Thread
        │
        ↓
Replica I/O Thread
        │
        ↓
Relay Log
        │
        ↓
Replica SQL Thread
        │
        ↓
Replica Data

最值得记住的不是线程名字，而是这一条逻辑：

主库记录变化 → 从库接收变化 → 从库重放变化。

四、为什么会出现“刚写完却读不到”？

4.1 复制存在时间差

假设刚完成一笔更新：

T0：主库 UPDATE 成功
T1：客户端立即读取
T2：Binlog 到达从库
T3：从库完成 Relay Log 重放

如果：

T1 < T3

那么客户端从从库读取时，看到的就是旧数据。

也就是：

write master
    ↓
success
    ↓
read replica
    ↓
old value

这就是典型的复制延迟导致的读后写不一致（read-after-write consistency 问题）。

4.2 一个非常实用的原则：不是所有读请求都应该读从库

如果某个查询对实时性要求非常高，例如：

用户修改密码
   ↓
立即跳转个人信息页
   ↓
必须看到刚刚修改后的结果

那么这次读取可以继续访问主库。

因此读写分离不应该简单理解为：

1 2	`SELECT → 从库 INSERT / UPDATE / DELETE → 主库`

更合理的是：

普通读            → 从库
允许短暂旧数据的读 → 从库
强一致性读         → 主库
写后立即读         → 主库 / 一致性路由
写操作             → 主库

这也是为什么真正的数据库路由策略通常比“判断 SQL 是 SELECT 还是 UPDATE”复杂得多。

五、复制模式：性能和一致性之间的取舍

5.1 异步复制

基本过程：

Client
  │ COMMIT
  ↓
Master
  │
  ├─ 本地提交成功
  └─ 立即返回客户端
       │
       └── Binlog 再异步发送给 Replica

优点：

主库不需要等待从库；
写入延迟低；
吞吐量高。

缺点：

如果出现：

主库提交成功
   ↓
还没同步给从库
   ↓
主库宕机

那么提升某个从库为新主库时，这笔已向客户端确认成功的事务可能并不存在于新主库。

所以异步复制更偏向：

性能优先。

5.2 半同步复制

半同步复制会在事务返回客户端之前，多等待一个确认过程。

逻辑可以理解为：

Master COMMIT
     │
     ↓
发送 Binlog
     │
     ↓
至少一个 Replica 收到并写入 Relay Log
     │
     ↓ ACK
     │
     ↓
Master 返回客户端成功

相比异步复制，它增加了一次网络等待，因此写延迟会上升，但数据安全性更好。

资料中还提到了 MySQL 5.7 中用于配置等待从库数量的参数：

1	`rpl_semi_sync_master_wait_for_slave_count`

核心思想不是记参数，而是理解：

等待确认的副本越多，一致性保障通常越强，但写入延迟也会增加。

5.3 MGR：从“复制日志”走向“组一致性”

MySQL Group Replication（MGR）进一步引入复制组和一致性协议。

多个节点形成一个组：

Node A
Node B
Node C
Node D
Node E

对于读写事务，不再只是“主库写完以后通知从库”，而是需要复制组中的多数节点参与一致性确认。

因此它体现的是另一种设计思想：

传统复制：
先有主库决定
      ↓
再把结果复制出去

组复制：
事务提交
      ↓
先通过组内一致性协议
      ↓
再形成一致决定

这类机制的关键权衡仍然没有改变：

更强的一致性
      ↑
更多节点协作
      ↑
更高通信成本
      ↑
更高延迟

数据库架构里很少存在“免费午餐”。

六、复制解决不了一切：真正的数据安全还需要“可恢复性”

主从复制之后，一个新的问题出现了：

如果错误操作也被复制了怎么办？

因此数据库可靠性不能只有复制，还应该有：

Replication
+
Backup
+
Binlog
+
Recovery Procedure

可以把它们看成不同层次：

机制	主要解决的问题
主从复制	节点故障、读扩展
全量备份	大规模恢复
Binlog	时间点恢复、重放变更
延迟从库	给误操作留下“反应窗口”
InnoDB Force Recovery	数据文件已经损坏时尽量抢救数据

七、没有备份、没有 Binlog，只剩 `.ibd` 文件怎么办？

这是数据库运维里相当糟糕的一种情况。

但资料给出了一个重要事实：

即便进入最坏场景，也可能通过 InnoDB 数据文件尽量恢复部分数据。

这里的关键词是：

尽量。

不是保证 100%。

7.1 InnoDB 表空间

InnoDB 数据存储与 tablespace（表空间）相关。

资料中区分了两种方式：

共享表空间

多个表共享表空间文件。

优点是集中管理，但恢复单表时不够直观。

独立表空间

每张表拥有自己的：

1	`table_name.ibd`

因此：

1
2
3

users.ibd
orders.ibd
products.ibd

彼此独立。

独立表空间的一个重要优势，就是在故障恢复和表迁移时粒度更清晰。

八、为什么误删以后还有机会恢复？

InnoDB 中的某些删除行为并不意味着对应物理空间立刻被彻底抹掉。

可以把它粗略理解为：

DELETE
  ↓
记录被标记为删除
  ↓
空间未来可以被复用
  ↓
新数据不断写入
  ↓
原数据可能被覆盖

因此发生误删除后最危险的事情是：

继续向这张表写数据。

恢复时的第一原则反而不是“马上试各种 SQL”，而是：

停止写入
   ↓
保护现场
   ↓
复制原始数据文件
   ↓
在副本上分析和恢复

数据库恢复和磁盘数据恢复非常像：
覆盖发生得越多，恢复概率越低。

九、`innodb_force_recovery`：目标不是“修好”，而是“先把数据抢出来”

当 .ibd 文件中的数据页损坏严重时，MySQL 可能无法正常读取表。

InnoDB 提供：

1	`innodb_force_recovery`

用于强制恢复。

资料中的核心思路是：

默认值为 0；
出现损坏时从较低恢复级别开始；
如果仍无法启动或读取，再逐级提高；
高等级恢复模式更加激进，不应该轻易使用；
进入恢复模式后应尽快导出仍可读取的数据。

因此它不是一个长期运行模式，而是一个：

事故抢救模式。

9.1 数据恢复的典型思路

可以把资料中的流程整理为：

发现 InnoDB 文件损坏
        ↓
停止继续写入
        ↓
备份原始 .ibd 文件
        ↓
以较低级别 innodb_force_recovery 启动
        ↓
尝试读取数据
        ↓
定位可读取范围
        ↓
把可读取数据转储到新表
        ↓
退出 recovery 模式
        ↓
重建正常 InnoDB 表
        ↓
校验数据

文档实验中还利用了：

1
2
3

LIMIT
+
逐步缩小范围

来寻找损坏数据页附近的位置。

这里背后的思想非常值得记：

恢复的第一目标不是让原文件继续承担生产服务，而是尽可能把还活着的数据导出来。

十、真正正确的恢复策略：不要等事故发生以后才学习恢复

如果已经到了：

没有备份
+
没有 Binlog
+
.ibd 还损坏

那基本属于“最后抢救”。

更可靠的设计应该把恢复能力前置。

至少应该有：

定期全量备份
+
增量 / 日志恢复能力
+
开启 Binlog
+
备份有效性校验
+
恢复演练

还有一个经常被忽略的问题：

有备份，不代表能恢复。

一份从来没有做过恢复验证的备份，在事故发生前都只能算“可能有效”。

因此真正的备份体系应该包括：

Backup
   ↓
Verification
   ↓
Restore Drill

而不是只有第一步。

十一、SQL 注入：本质是“数据越过了代码边界”

SQL 注入最核心的原因其实并不复杂。

假设程序这么做：

固定 SQL
+
用户输入
+
字符串拼接
=
最终 SQL

程序希望用户输入只是：

但如果用户输入本身包含 SQL 语法，那么最终语句的结构就可能发生变化。

这意味着：

本来应该被当作数据的内容，被数据库解析器当成了 SQL 代码。

这就是 SQL 注入的根本问题。

11.1 危险写法

类似：

1	`$sql = "SELECT * FROM users WHERE id='$id'";`

风险并不在于 PHP，也不在于 GET 或 POST。

真正的问题是：

用户输入
   ↓
直接进入 SQL 字符串
   ↓
参与 SQL 语法解析

因此即使改成 POST，请求仍然可能存在注入。

十二、防 SQL 注入最重要的方法：参数化查询

安全方式的核心不是：

“把所有危险字符都过滤掉。”

而是：

从语义上把 SQL 和参数分开。

例如概念上：

1
2
3

SELECT *
FROM users
WHERE id = ?

然后把参数单独传递。

数据库看到的是：

1
2
3

SQL Template
+
Parameter

而不是：

1	`拼接后的 SQL 字符串`

于是用户输入无论是什么，本质上都只是“一个参数值”，而不是 SQL 结构的一部分。

12.1 一个非常重要的误区

不要把：

前端校验

当成安全边界。

原因很简单：

1
2
3

Browser UI
   ↓
HTTP Request

攻击者完全可以绕过你的页面，直接构造 HTTP 请求。

所以真正的校验必须在：

服务端

完成。

12.2 SQL 注入的防御链

资料中的防御思想可以整理为：

参数化查询
   +
服务端输入校验
   +
尽量避免动态 SQL 拼接
   +
生产环境关闭详细数据库错误
   +
数据库最小权限
   +
安全测试工具扫描

其中优先级最高的仍然是：

参数化查询。

输入过滤属于第二层保护，而不是参数化查询的替代方案。

十三、为什么生产环境不应该直接显示数据库错误？

开发阶段我们很喜欢看到：

1
2
3

SQL syntax error near ...
table xxx doesn't exist
column xxx unknown

因为方便排错。

但生产环境如果把这些信息原样返回，就相当于主动告诉外部：

数据库类型
SQL 结构
表结构线索
字段线索
后端实现细节

于是错误页面本身就可能成为信息泄漏渠道。

正确思路是：

用户看到：
“系统异常，请稍后重试”

服务端日志：
完整异常堆栈 + traceId + SQL 上下文

也就是：

详细错误留在内部，可控错误暴露给外部。

十四、数据库不一定都应该放在服务器：本地存储的另一条路线

前面的内容都在讨论服务端 MySQL。

但另一个重要问题是：

所有数据都必须远程访问数据库服务器吗？

答案显然不是。

浏览器和客户端应用都有本地存储能力。

资料将浏览器本地存储整理为：

类型	特点
Cookie	容量小，可以随 HTTP 请求发送
LocalStorage	持久化 Key-Value
SessionStorage	会话级 Key-Value
WebSQL	浏览器中的 SQL 数据库 API
IndexedDB	浏览器中的结构化 NoSQL 存储

它们共同解决的问题是：

让一部分数据离用户更近。

十五、WebSQL：在浏览器里操作一个关系型数据库

WebSQL 的思路很直接：

JavaScript
   ↓
WebSQL API
   ↓
SQLite
   ↓
本地数据库文件

它允许前端通过 SQL 直接操作本地数据。

资料归纳了三个核心 API。

15.1 `openDatabase()`

打开或创建数据库：

var db = openDatabase(
  'wucai',
  '1.0',
  '本地数据库',
  1024 * 1024
);

15.2 `transaction()`

执行事务：

1
2
3

db.transaction(function (tx) {
  // SQL operations
});

15.3 `executeSql()`

执行具体 SQL：

tx.executeSql(
  'SELECT * FROM heros WHERE name LIKE ?',
  ['%夏侯%'],
  successCallback,
  errorCallback
);

注意这里同样出现了：

参数占位符。

这与前面的 SQL 注入防御其实是同一个原则：

不要把用户输入直接拼进 SQL。

这就是不同章节之间非常漂亮的一次知识闭环。

十六、WebSQL 为什么今天更多是“历史知识”？

资料本身的后续讨论已经指出：

WebSQL 标准后来被废弃。

所以现在理解 WebSQL 的意义，更多是：

理解浏览器本地关系型数据库曾经的设计；
维护历史系统；
理解 WebSQL 与 SQLite 的关系；
对比 IndexedDB 的设计。

对于新的 Web 应用，本地结构化存储通常应该优先考虑：

1	`IndexedDB`

因此不要因为 WebSQL 能写 SQL，就把它当成现代浏览器存储的默认选择。

十七、SQLite：为什么它特别适合嵌入式和本地应用？

SQLite 与 MySQL 最大的差异之一，是部署模型。

MySQL 通常是：

Application
    │
 network
    ↓
MySQL Server

SQLite 则更像：

Application
    │
    ↓
SQLite Library
    │
    ↓
database.db

也就是说：

数据库引擎直接嵌入应用进程，数据存储在本地文件中。

不需要单独启动数据库服务器。

17.1 SQLite 的优势

资料中总结的特点包括：

轻量；
无需独立安装数据库服务；
容易嵌入应用；
数据库本质上是文件，迁移方便；
适合本地和中小规模数据；
可以降低频繁访问远程服务器的压力。

因此它非常适合：

桌面应用
移动应用
离线应用
浏览器内嵌场景
本地缓存
测试工具
轻量客户端

17.2 SQLite 为什么不适合大型高并发数据库服务？

关键原因是：

它的设计重点不是高并发服务器吞吐。

SQLite 可以非常快，但它的并发模型和传统数据库服务器不同。

如果系统需求是：

数千连接
大量并发写
分布式访问
高可用集群
复杂权限体系

那么显然应该选择 MySQL、PostgreSQL 等服务器型数据库。

这说明一个非常重要的架构原则：

不存在“最好的数据库”，只有与场景匹配的数据库。

十八、SQLite 也有自己的 SQL 方言

SQL 是标准，但不同数据库都有自己的实现差异。

资料中举了几个 SQLite 的例子。

18.1 字符串拼接

MySQL 常见：

1	`CONCAT(a, b)`

SQLite 可以使用：

a || b

例如：

1 2	`SELECT MesLocalID \|\| Message FROM Chat_1234;`

18.2 RIGHT JOIN

资料中的 SQLite 环境不支持 RIGHT JOIN，因此通常要重新调整查询方向，改写成 LEFT JOIN。

这提醒我们：

“会 SQL”不等于“所有数据库上的 SQL 都完全一样”。

跨数据库迁移时，除了表结构，还应该检查：

函数
JOIN 类型
日期处理
字符串函数
分页语法
JSON 支持
自增主键
类型系统

十九、Python 操作 SQLite：依然是 Connection + Cursor

Python 标准库自带：

1	`import sqlite3`

创建数据库连接：

1	`conn = sqlite3.connect("wucai.db")`

创建游标：

1	`cur = conn.cursor()`

执行 SQL：

cur.execute("""
CREATE TABLE IF NOT EXISTS heros (
    id INTEGER PRIMARY KEY,
    name TEXT
)
""")

参数化插入：

cur.execute(
    "INSERT INTO heros(id, name) VALUES (?, ?)",
    (10000, "夏侯惇")
)

批量执行：

cur.executemany(
    "INSERT INTO heros(id, name) VALUES (?, ?)",
    [
        (10001, "钟无艳"),
        (10002, "张飞"),
    ]
)

查询：

1 2	`cur.execute("SELECT id, name FROM heros") rows = cur.fetchall()`

最后：

1
2
3

conn.commit()
cur.close()
conn.close()

这个模式和访问其他关系型数据库非常接近：

Connection
    ↓
Cursor
    ↓
Execute
    ↓
Fetch
    ↓
Commit / Rollback

所以学会数据库 API 以后，切换数据库产品的学习成本会明显降低。

二十、`sqlite_master`：数据库也会保存自己的元数据

SQLite 中有系统元数据，可以用来发现数据库里有哪些对象。

例如资料中通过系统表寻找符合某种命名规则的聊天表：

1
2
3

SELECT name
FROM sqlite_master
WHERE type = 'table';

这个知识点本质上和 MySQL 的：

1	`information_schema`

非常相似。

也就是说：

1 2	`MySQL → information_schema SQLite → sqlite_master`

它们都在回答一个问题：

“数据库中有哪些数据库对象？”

这是理解数据库元数据体系的很好入口。

二十一、把五部分知识串起来：其实都在讨论“数据生命周期”

现在重新看这几类技术：

SQL
 ↓
写入数据
 ↓
Binlog
 ↓
复制
 ↓
副本
 ↓
备份
 ↓
恢复

另一边：

用户输入
 ↓
应用程序
 ↓
参数化查询
 ↓
数据库

还有：

服务端数据
      ↘
       MySQL

本地数据
      ↘
       SQLite / IndexedDB

它们共同组成一个完整的数据生命周期：

数据产生
  ↓
数据写入
  ↓
数据传输
  ↓
数据复制
  ↓
数据读取
  ↓
数据保护
  ↓
数据恢复
  ↓
数据归档 / 本地化

只学 CRUD，相当于只学习了这条链路中间很小的一段。

二十二、几个最值得留下来的工程原则

原则一：先优化，再扩容

SQL
→ 索引
→ 缓存
→ 读写分离
→ 集群

架构应该逐级演进，而不是一开始就把系统复杂化。

原则二：复制不是备份

误操作
↓
主库
↓ replication
从库

错误同样可以被完美复制。

因此必须有独立备份和恢复能力。

原则三：任何复制都会面对一致性与延迟问题

系统必须明确：

1
2
3

哪些读允许旧数据？
哪些读必须强一致？
写后读如何处理？

这应该是业务语义，而不是数据库中间件拍脑袋决定。

原则四：备份必须经过恢复验证

真正的目标不是：

1	`“每天都有 backup 文件”`

而是：

1	`“发生事故时，能够在目标时间内恢复”`

原则五：SQL 与参数必须分离

永远优先：

1	`Prepared Statement / Parameterized Query`

而不是：

1	`String Concatenation`

这是防 SQL 注入最重要的一道边界。

原则六：数据库选型首先看场景

服务端高并发：

1	`MySQL / PostgreSQL`

应用本地嵌入：

SQLite

浏览器本地结构化存储：

1	`IndexedDB`

不要因为大家都在用某个数据库，就把它塞进所有场景。

二十三、生产环境数据库检查清单

最后把这些知识压缩成一份可以实际使用的 checklist。

性能

慢 SQL 是否已经定位？
查询是否使用正确索引？
是否存在不必要的全表扫描？
热点数据是否适合缓存？
是否真的已经需要读写分离？

主从复制

Binlog 是否开启？
是否监控复制延迟？
写后立即读是否可能访问从库？
主从故障切换流程是否明确？
是否做过主库故障演练？

数据恢复

是否存在全量备份？
是否可以进行时间点恢复？
是否有 Binlog 保留策略？
是否定期验证备份文件？
是否真正演练过 Restore？
是否需要延迟从库防止误操作？

SQL 安全

是否存在字符串拼接 SQL？
是否统一使用参数化查询？
服务端是否做参数校验？
数据库账号是否最小权限？
生产环境是否隐藏数据库详细错误？
是否做过自动化安全扫描？

本地存储

数据是否真的需要放服务器？
Web 端是否应该使用 IndexedDB？
桌面或移动客户端是否适合 SQLite？
本地数据库是否包含敏感信息？
本地数据是否需要加密、备份或迁移策略？

总结

把主从复制、数据恢复、SQL 注入、WebSQL 和 SQLite 放在一起学习以后，会发现数据库真正困难的地方，从来都不是 SELECT、JOIN 或 GROUP BY 本身。

真正进入工程以后，我们面对的是：

数据怎么更快地读？
数据怎么安全地写？
节点挂了怎么办？
写完马上读为什么不一致？
误删以后怎么恢复？
攻击者能不能改变 SQL 的语义？
哪些数据应该留在服务端？
哪些数据应该放到本地？

这些问题最终都指向一个更完整的数据库观：

数据库不是一个“存数据的容器”，而是一套围绕数据一致性、可用性、安全性和生命周期建立起来的工程系统。

如果只记住一条主线，可以记成：

性能：SQL / 索引 → 缓存 → 复制
可靠：复制 → 备份 → Binlog → 恢复演练
安全：输入 → 参数化 → 最小权限
架构：服务端 RDBMS ↔ 本地 SQLite / IndexedDB

当这些知识能够连成一张图时，SQL 才真正从“查询语言”升级成了“数据工程能力”。

数据库

#MySQL #InnoDB #Binlog #主从复制 #SQL注入 #WebSQL #SQLite

从主从复制到 SQLite：数据库可靠性、安全性与本地存储的完整知识图谱

https://allendericdalexander.github.io/2026/08/11/db/53sql/06database-engineering-reliability-security-local-storage/

作者

AtLuoFu

发布于

2026年8月11日

许可协议

Redis 从入门到实战：高性能原理、数据结构、事务、Lua 与排行榜上一篇

从锁、MVCC到查询优化器：一篇文章串起 MySQL SQL 执行与性能优化下一篇

从主从复制到 SQLite：数据库可靠性、安全性与本地存储的完整知识图谱

一、先建立整体视角：数据库工程不只是 CRUD

二、MySQL 主从复制：解决的并不只是“读多写少”

2.1 优化数据库，不要一上来就做主从

2.2 主从复制的三个主要价值

1. 读写分离

2. 热备份

3. 高可用

三、MySQL 主从同步的核心：Binlog

3.1 Binlog 是什么

3.2 经典复制链路

主库：Binlog Dump Thread

从库：I/O Thread

从库：SQL Thread

四、为什么会出现“刚写完却读不到”？

4.1 复制存在时间差

4.2 一个非常实用的原则：不是所有读请求都应该读从库

五、复制模式：性能和一致性之间的取舍

5.1 异步复制

5.2 半同步复制

5.3 MGR：从“复制日志”走向“组一致性”

六、复制解决不了一切：真正的数据安全还需要“可恢复性”

七、没有备份、没有 Binlog，只剩 .ibd 文件怎么办？

7.1 InnoDB 表空间

共享表空间

独立表空间

八、为什么误删以后还有机会恢复？

九、innodb_force_recovery：目标不是“修好”，而是“先把数据抢出来”

9.1 数据恢复的典型思路

十、真正正确的恢复策略：不要等事故发生以后才学习恢复

十一、SQL 注入：本质是“数据越过了代码边界”

11.1 危险写法

十二、防 SQL 注入最重要的方法：参数化查询

12.1 一个非常重要的误区

12.2 SQL 注入的防御链

十三、为什么生产环境不应该直接显示数据库错误？

十四、数据库不一定都应该放在服务器：本地存储的另一条路线

十五、WebSQL：在浏览器里操作一个关系型数据库

15.1 openDatabase()

15.2 transaction()

15.3 executeSql()

十六、WebSQL 为什么今天更多是“历史知识”？

十七、SQLite：为什么它特别适合嵌入式和本地应用？

17.1 SQLite 的优势

17.2 SQLite 为什么不适合大型高并发数据库服务？

十八、SQLite 也有自己的 SQL 方言

18.1 字符串拼接

18.2 RIGHT JOIN

十九、Python 操作 SQLite：依然是 Connection + Cursor

二十、sqlite_master：数据库也会保存自己的元数据

二十一、把五部分知识串起来：其实都在讨论“数据生命周期”

二十二、几个最值得留下来的工程原则

原则一：先优化，再扩容

原则二：复制不是备份

原则三：任何复制都会面对一致性与延迟问题

原则四：备份必须经过恢复验证

原则五：SQL 与参数必须分离

原则六：数据库选型首先看场景

二十三、生产环境数据库检查清单

性能

主从复制

数据恢复

SQL 安全

本地存储

总结

七、没有备份、没有 Binlog，只剩 `.ibd` 文件怎么办？

九、`innodb_force_recovery`：目标不是“修好”，而是“先把数据抢出来”

15.1 `openDatabase()`

15.2 `transaction()`

15.3 `executeSql()`

二十、`sqlite_master`：数据库也会保存自己的元数据