SQLAlchemy 关联查询报 child.id 不存在，表里明明有这列

多对多关系已经正确建表，使用 selectinload(Parent.children.of_type(Sub)) 查询时却报：

sqlalchemy.exc.OperationalError: no such column: child.id

先看实际 SQL：如果目标表写成 child AS child_1，连接条件却仍引用 child.id，问题是别名没有完整适配，不是数据库真的少了一列。不同数据库也可能把它报成无效表引用或未知标识符。

SQLAlchemy 2.1.0b3 引入的多对多 omit_join 优化存在这条回归，正式 2.1.6 仍保留相应路径。触发条件包括多对多关系、select-in 预加载，以及 of_type() 或 aliased() 产生的别名目标；不能把所有关系查询报列不存在都归到这里。

在受影响关系上关闭 omit_join 优化

对已有的多对多映射，可以保留关联表和目标筛选，在这条关系上设置 omit_join=False：

children: Mapped[list["Child"]] = relationship(
    secondary=link,
    omit_join=False,
)

这里的 Mapped、relationship、Child 与关联表 link 属于应用原有映射。修改后按原流程重新初始化映射和会话，再检查生成的关联 SELECT。这个选项改变加载 SQL 的组织方式，不需要给数据库增加一个重复的 child 表，也不需要删除 of_type() 的子类条件。

受影响优化分支直接把原关系的 secondaryjoin 拼到别名目标上，遗漏目标侧表达式适配。非优化路径会保留用于正确适配连接的完整关系上下文，因此关系级关闭该优化是有针对性的规避；它不代表可以任意关闭其他 ORM 保护。

区分映射错误、旧对象和这条回归

如果 SQL 中根本没有别名，或错误来自手写 primaryjoin、secondaryjoin，应按实际映射继续排查。也不要把 session.get() 命中已有对象、没有重新应用加载选项的问题混进来；那通常表现为关系没有加载，而不是这里的无效连接 SQL。

2.0 系列和 2.1.0b2 不受这次新优化回归影响。需要回退时，还要考虑整个项目的依赖与其他修补；更新到后续版本后，则先确认原来的别名关联查询已经正确，再决定是否恢复 omit_join 优化。

在隔离数据上覆盖普通子对象、子类对象、空关联及项目实际的复合外键。既要检查 SQL 能执行，也要比较子类筛选、关联数量和集合内容；只把异常隐藏掉，可能悄悄扩大返回范围。保留原映射和锁文件，回退该选项时先确认目标版本已解决同一别名路径。