留言板核心表怎么建：message 和 user 两个主表够用
单个留言板功能，不需要过度设计。最简可用结构就是
message表存留言，
user表存用户（哪怕只用于记录昵称和邮箱）。如果支持游客留言，
user表可选，
message表直接存
nickname和
常见错误是提前加
status、
reviewed_at、
ip_location等字段——上线前没明确审核流程或反垃圾需求，这些字段只会增加写入开销和查询复杂度。
推荐字段组合：
idbigint unsigned auto_increment primary key
nicknamevarchar(50) not null —— 不要用
name，语义更准
contenttext not null —— 用
text，别用
varchar(2000)自缚手脚
created_atdatetime default current_timestamp
ipvarchar(45) default null —— 存 IPv4/IPv6 都够用（IPv6 最长 39 字符）
要不要加回复功能：有则必须拆出 reply 表
如果产品确定要支持“对某条留言回复”，就不能把回复内容塞进原
message表加个
parent_id了事。否则查某条留言的所有回复时，得
WHERE parent_id = ? OR id = ?，逻辑绕、索引难优化。
正确做法是独立
reply表：
idbigint unsigned primary key
message_idbigint unsigned not null —— 关联到
message.id
nicknamevarchar(50) not null
contenttext not null
created_atdatetime default current_timestamp 联合索引：
INDEX idx_message_created (message_id, created_at)—— 按时间倒序查回复必备
注意：不要在
reply表里加
user_id外键。留言和回复都面向轻量交互，用户无登录态时，外键约束反而卡住插入。
防刷和基础过滤：靠应用层做，别指望 MySQL 触发器
想用 MySQL 触发器自动过滤敏感词、限制 1 小时内只能发 3 条？别试。触发器无法访问外部词库，也不能读取请求时间戳或 IP，更没法返回友好错误给前端。
真正可行的控制点只有三个：
应用层校验：content长度（比如 >2000 字截断）、
nickname是否含控制字符（
\x00-\x08\x0B\x0C\x0E-\x1F） 数据库层限流：用 Redis 记录
ip:xxx的提交次数，MySQL 只管存 索引加速：在
created_at上建索引，方便后台查“最近 24 小时留言”
有人给
content加全文索引想搜留言——除非你真要做站内搜索，否则纯属浪费 I/O。LIKE '%关键词%' 在
text字段上走不了索引，全文索引对中文支持又弱，先别碰。
上线后第一个要加的字段：is_deleted
运营初期没人删留言，但只要开始人工审核或用户投诉，你就得软删除。硬删（DELETE）会破坏评论数统计、导致 ID 断层、让关联回复丢失上下文。
上线前就该预留：
is_deletedtinyint(1) default 0 —— 别用
enum或
varchar，整型比较快 所有 SELECT 都要加
WHERE is_deleted = 0，别依赖应用层拼条件 加复合索引：
INDEX idx_status_time (is_deleted, created_at)，避免全表扫
这个字段看着小，但等你半夜被运营喊起来删广告留言时，就会发现它省下的不是时间，是重连数据库的耐心。
