直接拼接表名做JOIN会失败，因为SQL预编译不支持将表名、字段名作为参数变量，?占位符仅适用于值，标识符拼接易引发语法错误和SQL注入；元数据驱动需将连接逻辑外置为配置，通过白名单校验+动态SQL组装实现安全动态关联。
不能靠写死表名和字段来实现“动态 JOIN”——元数据驱动的关联必须把连接逻辑从 SQL 体外抽离，否则一改结构就得重写查询、重发上线。
为什么直接拼接表名做 JOIN 会失败
数据库在解析 SELECT * FROM :table_a JOIN :table_b ON ... 时，:table_a 不是参数占位符，而是语法错误。预编译不接受表名/字段名作为变量，PreparedStatement 的 ? 只能代入值，不能代入标识符。
常见错误现象：ERROR: relation ":table_a" does not exist（PostgreSQL）或 Unknown table ':table_b'（MySQL）。
使用场景：多租户系统按 tenant_id 切分物理表、历史归档表按月命名（orders_202512, orders_202601）、BI 工具需根据用户选择实时组合表。
- 硬编码表名 → 每次新增租户/新月份都要改代码、走发布流程
- 用字符串拼接 SQL → 极易引入 SQL 注入（尤其当表名来自前端或配置项）
- 试图用视图或 CTE 预定义 → 视图名固定，无法参数化；CTE 不能接收运行时表名
真正可行的元数据驱动方案：三层解耦
核心思路是把“哪两张表要 JOIN”“用什么字段关联”“是否需要过滤”全部存进配置表，SQL 只负责执行已知结构的模板。
示例元数据表 join_mapping 字段：id, left_table, right_table, on_condition, filter_sql, is_active。
实际执行分三步：
- 查
join_mapping获取目标表名和on_condition（如"a.user_id = b.id"） - 用白名单校验
left_table和right_table是否在允许范围内（如只允许["users", "orders", "products"]） - 组装最终 SQL：
SELECT /*+ MAPJOIN(b) */ * FROM users a JOIN orders b ON a.user_id = b.user_id WHERE b.status = 'paid'—— 注意这里ON和WHERE都来自元数据，但必须提前约定好字段别名（a/b）
性能影响：绕过优化器对跨表统计信息的判断，可能选错驱动表；建议在元数据中增加 hint 字段（如 "/*+ USE_INDEX(b, idx_user_id) */"）供人工干预。
SqlSugar 等 ORM 如何安全支持动态 JOIN
SqlSugar 的 Queryable<T1, T2> 泛型签名本身是编译期固定的，无法运行时换实体类。但可通过 Ado.UseConnection 走原生 SQL + 参数化值的方式桥接。
关键点：
- 不调用
db.Queryable<T1,T2>(...)，改用db.Ado.UseConnection(conn => { ... })手动开连接 - 从元数据查出
left_table = "logistics_202604"后，用白名单验证，再拼进 SQL 字符串（非用户输入！） - 关联条件中的值仍走
parameters（如new { status = "shipped" }），保证注入安全
示例片段：
var mapping = db.Adso.UseConnection(conn =>
conn.QuerySingle<JoinMapping>("SELECT * FROM join_mapping WHERE id = @id", new { id = 123 })
);
// 白名单检查
if (!allowedTables.Contains(mapping.LeftTable)) throw new InvalidOperationException();
var sql = $"SELECT * FROM {mapping.LeftTable} a JOIN {mapping.RightTable} b ON {mapping.OnCondition}";
db.Adso.UseConnection(conn => conn.Query<dynamic>(sql, new { status = "done" }));最容易被忽略的兼容性雷区
不同数据库对动态标识符的支持差异极大：
- PostgreSQL 允许
EXECUTE format('SELECT * FROM %I', table_name)，但仅限于DO块或函数内，无法用于普通查询接口 - MySQL 的
PREPARE stmt FROM @sql要求@sql是用户变量，且不能跨连接复用，高并发下易出错 - Spark SQL / Doris 不支持任何服务端动态表名，必须靠调度层（Airflow/DolphinScheduler）生成具体 SQL 再提交
真正的“动态”不在 SQL 引擎里，而在你的应用层——把表名、字段、条件当成数据来管理，而不是当成语法的一部分。一旦开始纠结“怎么让数据库自己认出变量表名”，就已经走偏了。
