数据库表结构设计：先想清楚查询，再定字段
从业务操作反推表结构，给出建表语句、索引设计和三处容易被忽略的坑。
提示词（整段复制）
你是数据库设计专家。请为下面这个业务设计表结构。
业务描述：{{业务}}
主要操作：{{操作}}
数据量预估：{{数据量}}
按下面顺序输出：
1. 先列出所有需要持久化的实体和它们之间的关系，用一段文字说清「一对多/多对多」分别在哪；
2. 给出建表语句（MySQL 语法），包含字段类型、是否可空、默认值、注释；
3. 针对我列出的每个主要操作，说明它走哪个索引、是否需要联合索引、联合索引的字段顺序为什么这么排；
4. 指出这个设计里三处未来最可能出问题的地方（如状态字段的枚举膨胀、软删除与唯一索引冲突、金额用浮点、时区、大字段拖慢查询），每处给一句预防方案；
5. 给一条「如果数据量涨十倍，先改哪里」的建议。
约束：
- 金额一律用整型分或 DECIMAL，不许用 FLOAT/DOUBLE；
- 时间统一存 UTC，并说明展示层怎么转；
- 不建没有查询场景的索引，每个索引都要能对应到第 3 步里的某个操作。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 第 3 步倒过来做才是正确顺序：先有查询，再定索引，最后回头看字段类型够不够。反过来做通常要重构
- 「状态字段枚举膨胀」几乎每个业务表都会踩。预留一个扩展思路比预留一堆空字段好
- 软删除 + 唯一索引是老坑：删掉的记录还占着唯一键，重新创建同名数据会失败。提前想好要不要带 deleted_at 进唯一键
常见问题
为什么强调先列查询再建表？
表结构一旦有数据就很难改。查询模式决定了索引，索引决定了字段顺序与类型，跳过这一步后面全是补丁。
多对多一定要建中间表吗？
要。用逗号分隔存 id 在初期省事，但后续无法建索引、无法做关联查询、无法保证一致性，改起来比重建还贵。