应建独立activity表管理活动生命周期，含status（枚举）、start_time/end_time（datetime）、capacity、is_deleted；报名表activity_registration须分离user_id与activity_id，设联合唯一索引uk_user_activity，并用insert...select或select...for update防并发超限；status字段用varchar支持灵活扩展，审核留痕另建registration_audit_log表。
活动主表怎么建才支持灵活上下架和多状态
活动本身需要独立生命周期管理，不能和报名数据耦合。必须拆出 activity 表，而不是把活动字段直接塞进报名表里。
关键字段要包含：status（枚举值：draft/published/closed），start_time 和 end_time（用 DATETIME，别用 TIMESTAMP，避免时区隐式转换问题），capacity（总名额，用于后续校验），is_deleted（软删除，别用 DROP）。
常见错误是把 status 设成 TINYINT(1)，后期加状态要改表结构；或者漏掉 updated_at，导致无法判断最后修改时间。
报名记录表为什么必须分离用户ID和活动ID
activity_registration 表核心就是两个外键 + 一个唯一约束，不是为了省字段，而是为了防重复报名、支持取消重报、以及后续统计每个活动的报名人数。
必须设联合唯一索引：UNIQUE KEY `uk_user_activity` (`user_id`, `activity_id`)。否则同一个用户反复提交会插入多条记录，前端防重只是辅助，数据库层才是最终防线。
其他实用字段：created_at（报名时间），status（registered/canceled/checked_in），extra_info（JSON 类型，存手机号、性别等可变字段，别为每个字段单独建列）。
注意：不要在该表里冗余活动名称或用户昵称——查的时候 JOIN，写的时候只存 ID，否则数据不一致风险极高。
怎么处理并发抢名额这种典型场景
光靠应用层判断剩余名额再 INSERT，高并发下必然超限。必须用数据库原生机制兜底。
推荐两种方式：
- 用
INSERT ... SELECT+ 子查询校验：INSERT INTO activity_registration (user_id, activity_id) SELECT ?, ? FROM DUAL WHERE (SELECT capacity - COUNT(*) FROM activity_registration WHERE activity_id = ? AND status = 'registered') > 0;
成功则插入，失败则返回空结果集。 - 更稳妥的是在事务中先
SELECT ... FOR UPDATE锁住活动行，再查剩余名额并 INSERT，但要注意锁粒度和事务时长，避免阻塞。
别依赖 UPDATE activity SET remaining = remaining - 1 这种方式——它不保证原子性，且无法关联到具体报名人。
报名审核、签到这些扩展状态怎么不改表结构就支持
状态字段 status 必须设计成字符串（如 VARCHAR(20)），而不是整数或 ENUM。ENUM 修改成本高，TINYINT 扩展性差，字符串能直接写 'pending_review' / 'approved' / 'rejected' / 'checked_in'，应用层用常量映射，数据库无感。
如果审核需要留痕，加一张 registration_audit_log 表，字段包括：registration_id、operator_id、action（approve/reject）、remark、created_at。不要把审核意见塞进主表的 JSON 字段里，否则无法高效查询“谁被谁拒了”。
容易忽略的一点：所有状态变更操作，都得检查前置条件。比如只有 status = 'registered' 才能审核，只有 status = 'approved' 才能签到——这些逻辑必须在 SQL 或事务里强制，不能只靠代码判断。
