动态SQL在分布式事务中可用但须严格约束：MySQL需复用同一连接并显式绑定xid；SQL Server DTC仅协调四部分命名操作；Oracle必须绑定变量并签名传输xid；所有场景均须前置SQL校验，禁止应用层校验。
动态 SQL 在分布式事务中不是不能用，而是必须在 XA 或 DTC 协议约束下做严格隔离——它本身不参与两阶段提交，一旦脱离连接上下文或参数校验，就会导致 prepare 失败、数据不一致或 SQL 注入。
MySQL XA 场景下动态 SQL 必须复用同一连接并显式绑定 xid
MySQL 的 XA START 只注册事务标识，不自动捕获后续语句。你在 XA START 'abc' 后拼接的动态 SQL（如 CONCAT('UPDATE t SET v = ', @val)），如果没在同一个连接中执行，就根本不会进入该 XA 事务。
- 错误做法：在存储过程中
PREPARE stmt FROM @sql+EXECUTE stmt，但连接已在中间被框架或连接池重置 - 正确做法：整个分支事务生命周期内只用一个
CONNECTION，且所有PREPARE/EXECUTE都在XA START和XA END之间 - 必须检查
@@in_transaction和@@xa_state，避免XA PREPARE报错XAER_RMFAIL
SQL Server DTC 中 EXEC 远程存储过程不等于分布式事务参与
EXEC [srv_link].db.dbo.sp_name 看似跨库，实则只是本地发起一次 RPC 调用，远程 SP 内部的 BEGIN TRAN 对 DTC 完全不可见。DTC 只协调你本地发出的四部分命名操作（如 INSERT INTO [srv_link].db.schema.t）。
- 危险现象：远程 SP 执行了
UPDATE并COMMIT，本地事务却因网络中断回滚，结果远程已提交、本地未写入 - 安全替代方案只有两个：
INSERT INTO [srv_link].db.schema.t ...或INSERT INTO OPENQUERY([srv_link], 'SELECT ...') ... - 绝对禁用
OPENDATASOURCE和OPENROWSET，它们彻底游离于事务上下文之外
Oracle 动态 SQL 必须用绑定变量，且 xid 传递需签名防重放
Oracle 的 EXECUTE IMMEDIATE 若拼接参数，会直接绕过权限校验和 SQL 解析缓存，极易触发注入；更关键的是，当它作为分布式分支调用时，xid 如果通过 HTTP header 明文传给下游服务，可能被日志泄露后重放，导致事务 ID 冲突或越权提交。
- 动态 SQL 中所有变量必须用
:v1,:v2绑定，禁止|| v_val ||拼接 - 跨服务传递 xid 时，不能只传
gtrid,bqual,formatID三元组，而要 HMAC-SHA256 签名后传输 - 下游收到后必须先验签再执行
DBMS_XA.XA_START，否则拒绝加入事务
所有场景下，SQL 内容都必须前置校验，不能依赖回滚兜底
XA 或 DTC 的原子性只保证“全提交或全回滚”，不阻止危险 SQL 进入 prepare 阶段。一条无 WHERE 的 UPDATE users SET status = 0，只要权限允许，就会在 prepare 时写入 undo log，最终可能被提交——此时回滚已无法挽回业务影响。
- 在
XA START或BEGIN DISTRIBUTED TRANSACTION前，必须拦截并解析 SQL AST 或正则匹配：检查是否存在全表更新/删除、敏感字段写入（如password,id_card）、子查询嵌套深度 > 3 - 不要依赖
SET XACT_ABORT ON或autocommit=0当安全开关，它们只控制错误传播，不改变 SQL 语义风险 - 最易被忽略的一点：校验逻辑必须运行在数据库服务端或紧邻的网关层，不能放在应用代码里——因为动态 SQL 可能来自第三方接口或配置中心
