留言表必须包含哪些字段才够用又不冗余
最小可用的留言表只需要
id、
content、
created_at三个字段。加
ip或
user_agent属于可选追踪字段，上线初期没必要；
nickname可以留空，但建议设为
VARCHAR(32)而非
TEXT，避免索引失效。
常见错误是过早加入
status（如“审核中/已发布”），结果发现全站都走未审核流程，反而让查询多一层判断。真要加审核状态，等日均留言超 50 条再考虑。
推荐建表语句关键部分：
CREATE TABLE `message` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `content` TEXT NOT NULL, `nickname` VARCHAR(32) DEFAULT '', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_created_at` (`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
为什么不能用 INT 当主键而要用 BIGINT
留言系统一旦跑起来，ID 增长比想象中快：单日 100 条，一年就 3.6 万；若被爬虫或误触发刷到每秒 1 条，不到 5 年就撞上
INT UNSIGNED的上限（42.9 亿）。实际线上见过第 3 年因主键溢出导致插入失败的案例。
BIGINT UNSIGNED支持到 1844 亿亿，对留言板足够安全。别信“我这小项目用不到”，主键换类型要锁表重建，上线后再改成本远高于初始化时定好。
顺带提醒：
AUTO_INCREMENT必须配
NOT NULL，否则 MySQL 8.0+ 会报错；
DEFAULT CURRENT_TIMESTAMP比应用层写时间更可靠，避免服务器时钟不同步导致排序错乱。
分页查最新 20 条留言，LIMIT OFFSET 为什么慢
当留言总数达 10 万条，
SELECT * FROM message ORDER BY created_at DESC LIMIT 20 OFFSET 10000会先扫描前 10020 行再丢弃 10000 行——磁盘 I/O 和 CPU 都在白忙。
真实可行的优化只有两种：
用游标分页（cursor-based pagination）：记录上一页最后一条的created_at和
id，下一页查
WHERE created_at加覆盖索引：如果只显示内容和时间，建联合索引
KEY idx_created_id_content (created_at, id, content)，让查询能走索引不回表
别碰
SQL_CALC_FOUND_ROWS，它在分页场景下性能更差，且 MySQL 8.0.17 已弃用。
用户提交空内容或超长文本怎么拦在数据库层
应用层校验可能被绕过，MySQL 层需兜底。用
CHECK约束最直接：
ALTER TABLE `message` ADD CONSTRAINT `chk_content_length` CHECK (CHAR_LENGTH(content) BETWEEN 1 AND 2000);
注意两点：
MySQL 5.7 不支持CHECK（语法通过但不生效），必须用 8.0.16+ 或 MariaDB 10.2+
CHAR_LENGTH算字符数，不是字节数；
utf8mb4下一个 emoji 占 4 字节但只算 1 字符，刚好符合“最多 2000 字”的业务需求
如果旧版本 MySQL 无法用 CHECK，就只能靠触发器（
BEFORE INSERT）抛异常，但触发器调试麻烦，优先升级 MySQL 版本。
