用户表和帖子表怎么设计才支持高效查询
论坛系统里，
user和
post表必须建立清晰的外键关系，否则后续按用户查帖、按帖查作者都会变慢甚至出错。
user表主键用
id（INT 或 BIGINT，自增），别用邮箱或用户名当主键——它们可能变更，且索引效率低
post表必须有
user_id字段，类型和
user.id严格一致，并加外键约束：
ALTER TABLE post ADD CONSTRAINT fk_post_user FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE CASCADE;高频查询如「某用户所有帖子」或「某帖子作者信息」，需在
post.user_id和
user.id上分别建索引；如果常查
post.created_at，也得给它加索引 别把用户昵称、头像等字段冗余到
post表里——更新用户资料时容易不同步，用 JOIN 查更安全
怎么安全地插入新帖子并防止 SQL 注入
直接拼接字符串构造
INSERT语句是高危操作，尤其当标题、内容来自用户输入时。必须用预处理语句。 PHP 示例（PDO）：
$stmt = $pdo->prepare("INSERT INTO post (user_id, title, content, created_at) VALUES (?, ?, ?, NOW())");<br>$stmt->execute([$userId, $title, $content]);
Python（PyMySQL）：cursor.execute("INSERT INTO post (user_id, title, content, created_at) VALUES (%s, %s, %s, NOW())", (user_id, title, content))
关键点：所有用户输入字段（$title、
$content、
$userId）都必须走参数占位符，不能拼进 SQL 字符串里 额外建议：对
title字段设
VARCHAR(200)限制长度，避免超长标题拖慢查询；
content用
TEXT类型，别用
MEDIUMTEXT除非真要存几 MB 内容
删除用户时，他的帖子要不要一起删
这取决于业务规则，但多数论坛选择「级联删除」或「软删除」，硬留着无主帖子会引发权限和展示问题。
如果用外键 +ON DELETE CASCADE（见第一个副标题），删
user行会自动删掉其所有
post行——简单但不可逆 更稳妥的做法是软删除：在
user表加
is_deleted TINYINT(1) DEFAULT 0，查帖时加
WHERE u.is_deleted = 0；同时
post表保留
user_id，但前端显示作者时先校验用户是否有效 注意：如果用了软删除，
post表的
user_id外键就不能再设
ON DELETE CASCADE，否则删用户时仍会触发级联——得手动控制逻辑 千万别用
DELETE FROM post WHERE user_id = ?手动删帖再删用户，容易漏执行或事务中断导致数据不一致
分页查某个用户的帖子为什么越往后越慢
用
LIMIT offset, size做深分页时，MySQL 要扫描前
offset + size行，比如第 1000 页（每页 20 条）就得扫 20020 行，性能断崖式下跌。 改用游标分页（cursor-based pagination）：按
created_at DESC, id DESC排序，下一页请求带上上一页最后一条的
created_at和
id：
SELECT * FROM post WHERE user_id = ? AND (created_at, id) < (?, ?) ORDER BY created_at DESC, id DESC LIMIT 20;确保复合索引存在：
CREATE INDEX idx_user_time_id ON post (user_id, created_at DESC, id DESC);如果必须用传统分页（比如后台管理），至少限制最大页码，比如只允许查前 200 页，超出就返回空或提示「已到底」 注意：
created_at可能重复，所以必须联合
id做唯一排序依据，否则分页结果可能跳行或重复
实际部署时，
post表一旦超过百万行，
user_id索引的选择性下降会导致 JOIN 效率明显变差，这时就得考虑归档老帖或按月分表——但那是另一个量级的问题了。
