数据层与数据库
表结构、扩展字段的存法、索引表,以及换成 MySQL 要注意什么。
主要数据表
| 表 | 存什么 |
|---|---|
contents | 内容主表,自定义字段值在扩展字段里 |
content_models | 内容模型与字段定义 |
content_field_index | 可筛选字段的索引 |
content_media | 图集 |
content_relations | 内容之间的关联 |
content_categories | 副栏目归属 |
categories | 栏目 |
users / roles | 用户与角色权限 |
forms | 自定义表单定义 |
messages | 留言与表单提交记录 |
logs | 操作日志 |
扩展字段怎么存的
自定义字段的值以 JSON 存在 contents.ext_data 里。
好处是加字段不改结构;代价是按字段查询不方便 —— 这正是索引表存在的原因。
索引表的工作方式
保存内容
↓ 遍历该模型的字段定义
↓ 只挑 filter = 1 的字段
↓ 数字存进 num_value,其余存进 str_value
content_field_index
前台按字段查询时走 EXISTS 子查询命中这张表,因此:
数字之间是数值比较(9 < 100 成立),并且查询走索引而不是全表扫描。
删除内容时索引行会一并清理,不会残留。
换成 MySQL
配置里把驱动改成 MySQL 并填好连接信息即可,数据层会自动切换。 但要注意:
- 建表语句目前是按 SQLite 方言写的,迁移到 MySQL 需要把自增主键、类型等做对应调整
- 部分写法(如
INSERT OR IGNORE)是 SQLite 专有语法,MySQL 下需要改写
换句话说,小站直接用 SQLite 最省事;确实需要 MySQL 时建议先在一套测试环境上跑通再迁移。
备份要连 WAL 一起备份。SQLite 开启 WAL 模式后会额外生成
-wal 与 -shm 文件,
只复制 .db 一个文件可能丢掉最近的写入。系统的备份功能已经处理了这一点。