MySQL 表结构设计要匹配 CMS 的发布状态流转
CMS 中文章不是“写完就发”，而是存在草稿、待审、已发布、已撤回等状态，
status字段不能只用
TINYINT硬编码 0/1/2——后期加个“定时发布”或“审核中（二级）”就会改表、改代码、改所有查询条件。 推荐用
VARCHAR(20)存语义化状态值，如
'draft'、
'pending_review'、
'published'、
'archived'
created_at和
updated_at必须都有，且
updated_at要在每次状态变更时更新（别依赖 MySQL 的
ON UPDATE CURRENT_TIMESTAMP自动触发，CMS 后台可能批量修改多条，需显式控制） 如果支持定时发布，加一个
scheduled_at
DATETIME NULL字段，查“待发布”时用
WHERE status = 'scheduled' AND scheduled_at ，避免轮询或事件调度器
文章正文字段必须用 TEXT 或 MEDIUMTEXT，别用 VARCHAR
用户粘贴带格式的富文本（如 TinyMCE、Quill 输出的 HTML）、插入图片 base64、甚至嵌入代码块后，内容轻松超 65535 字节。用
VARCHAR(65535)不仅会截断，还可能因字符集（如 utf8mb4）导致实际存储上限缩到约 16383 字符。
content字段类型选
MEDIUMTEXT（最大约 16MB），足够容纳带图、带样式的长文 如果 CMS 支持多语言或 SEO 元信息，别把
title、
meta_description塞进主表一起加索引——它们更新频次低、长度固定，可拆到
articles_meta表，主表只留
article_id外键 全文搜索需求强？别直接
LIKE '%关键词%'，先确认是否真需要 MySQL 内置
FULLTEXT：它不支持前缀模糊（
LIKE '关键词%'可走索引，
FULLTEXT不行），且对短词、停用词处理弱；更常见的是导出到 Elasticsearch 或使用 Meilisearch
发布操作本质是事务性状态更新，不是 INSERT
很多新手以为“发布文章”就是往
articles表里
INSERT一条新记录，其实绝大多数 CMS 是复用同一条记录，只改
status和时间戳。漏掉事务会导致状态错乱，比如审核通过时更新了
status却没更新
published_at，前端展示发布时间为
0000-00-00 00:00:00。
START TRANSACTION;
UPDATE articles
SET status = 'published',
published_at = NOW(),
updated_at = NOW()
WHERE id = 123
AND status IN ('draft', 'pending_review');
-- 检查影响行数是否为 1，否则说明状态非法或已被并发修改
COMMIT;
WHERE 条件中限定合法前驱状态（如只允许从 'draft'或
'pending_review'发布），防止重复点击或越权操作 应用层必须检查
mysql_affected_rows()（PHP）或
cursor.rowcount（Python）是否为 1，否则抛异常并记录日志，而不是静默成功 避免在事务里做 HTTP 请求（如通知订阅者）、写文件、调用外部 API——这些失败会导致事务卡住或回滚逻辑失控
管理后台列表页的分页查询容易拖垮数据库
CMS 后台文章管理页常按状态、分类、作者、时间范围筛选，再分页。用
LIMIT 10000, 20查第 501 页时，MySQL 仍要扫描前 10020 行，尤其当
status区分度低（比如 90% 都是
'published'）时，索引失效风险极高。 强制给高频查询字段建联合索引，例如：
INDEX idx_status_author_time (status, author_id, created_at)，让
WHERE status = ? AND author_id = ? ORDER BY created_at DESC LIMIT 20走索引覆盖 别用 OFFSET 分页，改用“游标分页（cursor-based pagination）”：记录上一页最后一条的
(status, author_id, created_at, id)，下一页查
WHERE (status, author_id, created_at, id)统计总数（如“共 1284 篇”）别用
COUNT(*)全表扫，可缓存到 Redis，或用近似值（
SHOW TABLE STATUS LIKE 'articles'的
Rows字段误差较大但够用）
状态字段的语义化、正文字段的容量预估、发布动作的事务边界、列表查询的索引策略——这四点漏掉任一，上线后都会在高并发或数据量上升时暴露出来，而且往往不是报错，而是表现诡异：某篇文章显示发布时间是 1970 年，后台搜不到刚发布的文章，或者编辑保存后状态倒退成草稿。
