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<User>()
.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<User>()
.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 了。
