Table Splitting是同一实体类的属性映射到共享主键的多个物理表，EF Core自动JOIN与同步写入；不同于一对多，它无独立子实体类，也不含外键约束，仅用于逻辑拆分宽表。
EF Core 中 Table Splitting 是什么，和普通一对多有什么区别
Table Splitting（表拆分）不是把一个实体拆成多个一对多关系，而是让 同一个实体类 的不同属性分别映射到 同一主键的多个物理表 上。数据库里这些表必须共享主键（且类型、约束完全一致），EF Core 会在查询时自动 JOIN，保存时同步写入。它和 Owned Entity 或 One-to-One 的关键区别在于：没有独立的子实体类，所有字段都属于同一个 CLR 类型。
典型场景是把大宽表按访问频率或安全策略拆分成主表（如 Users）和扩展表（如 UserProfiles），但业务代码仍只操作一个 User 对象。
如何用 Fluent API 配置 Table Splitting
必须在 OnModelCreating 中显式配置，不能靠约定。核心是调用 OwnsOne + ToTable，但注意：目标不是新建子实体，而是告诉 EF Core “这个导航属性对应另一个表，且主键复用”。
- 主实体类里需定义一个只读或可读写的
public导航属性（类型为自身或另一个类），EF Core 会把它当作“拆分部分” - 该导航属性的类型可以是另一个类（推荐），也可以是同一类（不常见，易混淆）
-
OwnsOne后必须链式调用ToTable("TableName")指定第二张表名 - 两张表的主键列名必须完全一致（如都是
Id），且不能在子表中重复声明主键 —— EF Core 会自动复用主表的主键作为外键约束
示例（User 主表 + UserProfile 扩展表）：
modelBuilder.Entity() .OwnsOne(u => u.Profile, nav => { nav.ToTable("UserProfiles"); nav.WithOwner(); // 表明 Profile 不拥有独立主键，复用 User.Id });
实体类怎么写才不会出错
导航属性不能为 null（除非你手动处理空值逻辑），否则插入时会抛 InvalidOperationException：“The navigation property 'Profile' cannot be null.”
- 在构造函数中 new 出导航对象（最稳妥）：
public User() { Profile = new UserProfile(); } - 使用 C# 8+ 可空引用类型时，避免给导航属性加
?后缀（如public UserProfile? Profile { get; set; }），否则 EF Core 会认为它可为空，导致生成的迁移包含外键约束，破坏 Table Splitting 语义 - 两个表中相同名称的列（如
Id）不能在两个实体类中都标记为[Key]；只在主实体类中标记，子类中去掉所有 Key/ForeignKey 特性 - 如果子表有非空字段，确保构造时初始化，否则 SaveChanges 会因数据库 NOT NULL 约束失败
查询和更新时要注意哪些隐含行为
EF Core 默认采用 INNER JOIN 加载拆分表，这意味着如果子表某行缺失，整个主实体查不到 —— 这和预期不符。解决方法是显式启用 IsRequired(false)：
modelBuilder.Entity() .OwnsOne(u => u.Profile, nav => { nav.ToTable("UserProfiles"); nav.WithOwner().IsRequired(false); // 关键：允许子表记录不存在 });
- 更新时，EF Core 会同时发两条 SQL（UPDATE 主表 + UPDATE 子表），即使只改了其中一个部分
- 若子表数据被外部程序直接删掉，下次加载该 User 会得到
Profile == null（前提是上面配了IsRequired(false)） - 无法对子表单独做 LINQ 查询（如
ctx.UserProfiles.Where(...)），因为UserProfile不是独立 DbSet - 迁移脚本里不会生成外键约束（EF Core 认为这是“同一实体的延伸”，而非关联关系），所以数据库层面要靠设计保证一致性
真正容易被忽略的是：Table Splitting 的“表”必须共用主键且无额外关联字段 —— 一旦你在子表里加了个 CreatedById 外键，它就不再是 Table Splitting，而该用 One-to-One 了。
