MySQL 本身不提供“用户反馈系统”这种现成功能，它只是存储数据的工具；真正实现反馈系统，关键在于表结构设计、写入逻辑控制和查询策略——而不是靠某个 MySQL 特性自动完成。
feedback 表怎么建才不容易翻车
很多项目一开始只建
feedback(id, content, created_at)，结果上线后发现没法查是谁提的、没法分类、没法回访。必须从第一版就考虑扩展性：
user_id字段不能省，即使初期是匿名提交，也建议用临时 token 或 session_id 填充，否则后续无法关联行为 加
type枚举字段（如
'bug'、
'suggestion'、
'question'），避免后期用字符串模糊匹配，查得慢还容易漏 加
status字段（
'pending'、
'replied'、
'closed'），别等运营手动 Excel 跟踪 如果要支持附件（截图、日志），不要存二进制到 MySQL，而是存路径（如
/uploads/feedback_12345.png），文件走对象存储
INSERT 时怎么防刷、防乱码、防超长
前端限制不等于后端安全，MySQL 层面要兜底：
对content字段用
TEXT类型（不是
VARCHAR(255)），但插入前在应用层截断到 10000 字符以内，防止 OOM 或拖慢慢查询 用
SET NAMES utf8mb4确保 emoji 和生僻字不变成
???，建表时也要指定
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci加唯一索引防机器人短时间重复提交：
UNIQUE KEY `uid_type_time` (`user_id`, `type`, `created_at`) USING BTREE，配合 5 分钟时间窗口 别直接拼接 SQL 插入，务必用预处理（
INSERT INTO feedback (...) VALUES (?, ?, ?)），否则 SQL 注入风险真实存在
查反馈时为什么 COUNT(*) 变慢、LIKE 失效
随着反馈量过万，简单查询就开始卡，问题常出在索引和查询写法上：
SELECT * FROM feedback WHERE type = 'bug' ORDER BY created_at DESC LIMIT 20必须有联合索引：
INDEX idx_type_time (type, created_at)，单列
type索引效果差 避免
WHERE content LIKE '%崩溃%'—— 全表扫描不可避免；真要搜内容，上
FULLTEXT索引或同步到 Elasticsearch
COUNT(*)在大表上变慢？别用它实时统计未读数；改用单独计数表（
feedback_stats(status, cnt)），每次 INSERT/UPDATE 后用
INSERT ... ON DUPLICATE KEY UPDATE cnt = cnt + 1维护 分页超过 1000 条后
LIMIT 10000, 20极慢？改用游标分页：
WHERE id ，靠主键定位
最容易被忽略的是「反馈闭环」：存进去只是第一步，没人看、没状态更新、没通知机制，那这个表就只是个数据坟墓。MySQL 能做的很有限，真正的系统性，藏在你怎么把
INSERT、
UPDATE status、
SELECT for admin dashboard这几件事串成一条可监控、可告警、可追溯的链路里。
