mysql和postgresql存储过程中无法用变量拼接表名，必须通过prepare+execute动态构建完整sql；需预建表、严格校验租户标识符、值用占位符绑定；postgresql还需动态拼接schema并重置search_path。
存储过程里不能用变量拼表名，这是硬限制
MySQL 和 PostgreSQL 的存储过程中，INSERT INTO table_name 这类语句的 table_name 必须是字面量，不接受变量或表达式。你写 INSERT INTO CONCAT('orders_', tenant_id) 会直接报错 ERROR 1064。这不是语法糖缺失，而是 SQL 解析器在预编译阶段就要求表名可确定——动态路由必须绕过这个限制。
唯一可行路径：用 PREPARE + EXECUTE 动态构建完整语句
必须把整个 DML 语句（含目标表名）拼成字符串，再通过 PREPARE 编译、EXECUTE 执行。关键点不是“能不能”，而是“怎么拼得安全、可控”：
- 所有租户表必须**提前建好**，结构一致，主键策略错开（如 auto_increment offset）
- 拼接时严格校验
tenant_id是否为合法标识符（只含字母、数字、下划线，且不以数字开头），避免 SQL 注入 - 不要在拼接中混入用户输入字段值；值一律用
?占位符，由EXECUTE ... USING绑定 - 示例片段（MySQL）：
SET @tenant_table = CONCAT('orders_', tenant_id); SET @sql = 'INSERT INTO ?? (user_id, amount) VALUES (?, ?)'; -- 注意：?? 不被原生支持，需手动替换或用白名单校验后拼接 SET @sql = CONCAT('INSERT INTO ', @tenant_table, ' (user_id, amount) VALUES (?, ?)'); PREPARE stmt FROM @sql; EXECUTE stmt USING user_id_val, amount_val; DEALLOCATE PREPARE stmt;
PostgreSQL 要用 format() + EXECUTE，且 schema 名也得动态
PG 比 MySQL 更严格：表名必须带 schema，而 search_path 不可靠（连接复用会导致串租户）。所以不能只拼表名，还得拼 schema：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 假设租户
tenant_123对应 schematenant_123，表名统一为orders - 用
format()构造带双引号的标识符，防关键字冲突：EXECUTE format('INSERT INTO %I.%I (user_id, amount) VALUES ($1, $2)', tenant_schema, 'orders') USING user_id_val, amount_val; - 务必确保
tenant_schema来自可信元数据表（如tenant_metadata），而非直接来自请求参数 - 禁止在
EXECUTE中拼接任何非 schema/表名的业务字段值
比存储过程更稳的选择：应用层路由 + 预建表
真正上线系统几乎不用存储过程做租户路由，原因很实际：
- 存储过程调试难、版本管理难、跨数据库迁移成本高
- 每个租户一张物理表 → 表数量随租户增长线性上升，MySQL 单实例扛不住几千张表
- DDL 变更（如加字段）要遍历所有租户表，容易漏、容易失败
- 更主流的做法是：应用层根据
tenant_id查元数据（tenant_id → db_instance + schema_or_database），拿到连接后执行普通 SQL —— 把路由逻辑从数据库移到 Go/Java 服务里，可控性、可观测性、弹性伸缩都更好
如果非要用存储过程，记住最易忽略的一点：**每次 EXECUTE 前必须重置连接状态（如 PG 的 search_path），否则上一个租户的上下文可能污染下一个**。这比拼表名还容易出问题。
