ThinkPHP项目必须遵守1NF/2NF/3NF规范：违反1NF导致查询失效与索引不可用，违反2NF引发更新异常，违反3NF造成数据不一致；表名须小写蛇形、主键统一为id、时间字段固定为created_at/updated_at、软删除字段必须为delete_time；数据库外键官方禁用，依赖validate+relation+事务保障一致性；索引需结合EXPLAIN验证，避免链式调用掩盖性能隐患。
不推荐在 ThinkPHP 项目里跳过规范化直接建表——这不是“快”，是给后续埋雷。规范化不是教条，而是用最小代价守住数据一致性、查询可维护性和扩展底线。
为什么 ThinkPHP 项目也得遵守 1NF/2NF/3NF
ThinkPHP 的 Model 类和关联查询（如 hasOne、hasMany）依赖清晰的主外键语义；如果字段本身可拆分（比如把完整地址存进 address 字符串）、或存在部分依赖（如订单表里同时存了商品名和价格，但价格其实只依赖商品 ID），ORM 就没法自动推导关系，你只能手写冗余 SQL 或硬编码逻辑。
- 违反 1NF（非原子字段）→
where查询失效、无法索引、JSON 字段后期难统计 - 违反 2NF（主键部分依赖）→ 更新异常：改一次商品价格要扫全表订单
- 违反 3NF（传递依赖）→ 数据不一致：用户所在城市信息散落在多个表，改错一个就脱节
ThinkPHP 表命名与字段设计的实际约束
ThinkPHP 默认按小写蛇形映射模型，比如 users 表对应 User 模型；但命名不是纯风格问题，它直接影响迁移、关联、缓存键生成等底层行为。
- 表名必须全小写 + 下划线，如
user_profiles，不能是UserProfile或userprofile - 主键统一用
id（INT 自增），ThinkPHP 的save()、find()默认认这个，改用uid要显式配置pk - 时间字段固定用
created_at/updated_at，否则autoWriteTimestamp不生效 - 软删除字段必须叫
delete_time，且类型为datetime NULL，否则delete(true)无效
外键要不要在数据库层加？ThinkPHP 的取舍逻辑
官方文档和多数生产项目都禁用 MySQL 外键（FOREIGN KEY 约束），原因很实际：ThinkPHP 的事务控制、分库分表适配、迁移回滚、以及线上 DDL 变更风险，都比数据库级约束更重要。
立即学习“PHP免费学习笔记（深入）”；
- 外键会锁表，
ALTER TABLE加约束可能卡住线上业务 - 水平分表后，跨分片外键无意义，应用层做校验反而更灵活
- ThinkPHP 的
validate+relation+ 事务封装已能覆盖 95% 的一致性场景 - 真要加，只在核心强一致性场景（如资金流水）用，且必须配套写好降级方案
索引不是越多越好，ThinkPHP 查询构造器怎么暴露隐患
where()、order()、join() 写得随意，很容易让索引失效——而 ThinkPHP 默认不打印慢查询日志，你根本看不到。
-
where('email', 'like', '%@qq.com')→ 左模糊，索引失效；应改用全文索引或前置字段分离 -
where(['status' => 1, 'created_at' => ['>', '2025-01-01']])→ 复合索引顺序错（status 在前，created_at 在后），created_at条件用不上 -
select('id,name,email')->where(...)→ 覆盖索引没建全，仍要回表查email - 用
Db::getLastSql()抓出真实 SQL，再用EXPLAIN验证，别信链式调用的“看起来很优雅”
规范化不是一步到位的设计动作，而是每次加字段、改关联、写新查询时的条件反射：这个值会不会变？是不是唯一确定的？有没有别的表已经存过？漏掉一次，后面就得靠 JOIN 补、靠缓存扛、靠人工对账救。
