CMS文章状态应使用VARCHAR(20)存储语义化值（如'draft'、'pending_review'等），避免硬编码；必须包含created_at和updated_at，后者需显式更新；支持定时发布时增设scheduled_at DATETIME NULL字段。
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_atDATETIME 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 年，后台搜不到刚发布的文章，或者编辑保存后状态倒退成草稿。
