一对一关系是否拆表取决于业务逻辑、数据增长预期和查询需求；若实体语义独立、字段影响主表性能或需差异化治理则建议拆，否则不建议。
一对一关系是否拆表，关键看业务逻辑、数据增长预期和查询需求，不是“该不该”，而是“值不值得”。如果两个实体天然独立、可能扩展、或存在明显读写分离场景，拆表更合理；如果只是单纯为了把字段分开放，反而增加JOIN开销，通常不建议。
如果两张表代表不同领域概念，即使当前是一对一，未来很可能变成一对多，就该拆。比如 user 和 user_profile：用户基本信息（账号、密码、状态）和个性化资料（头像、简介、偏好）语义不同，profile 可能后续支持多版本、多语言，甚至独立服务化。
如果附加字段体积大（如 JSON 配置、富文本、二进制 blob）、访问频次低、或更新不频繁，放在主表会拖慢高频查询（如列表页、登录校验）。这时拆到副表能减少主表宽度，提升缓存命中率和索引效率。
有些字段涉及敏感信息（身份证号、银行卡）、审计要求（操作日志快照）、或合规隔离（GDPR 中的个人数据），物理拆表便于设置不同行级安全策略、备份周期、加密方式或跨库迁移。
如果两个实体强绑定、永不分离、字段都小且高频共用，硬拆反而引入冗余和维护成本。比如 order 和 order_summary（仅含 total_amount、item_count），且每次查 order 必然要 summary —— 这类直接合并更高效。