TiDB中单纯应用层参数化无法防御SQL注入，因其分布式特性使恶意输入在分片路由、异步补偿、多语句执行等环节绕过防护；PREPARE语句对动态表名、ORDER BY字段、分库键等场景无效，必须下沉至驱动层AST校验并配合白名单硬校验。
单纯在应用层做参数化，无法防御TiDB中跨节点的SQL注入。 因为TiDB的分布式特性会让恶意输入在分片路由、异步补偿、多语句执行等环节绕过常规防护点——尤其是当攻击者控制了排序字段、表名、UNION子句或事务内嵌查询时。
为什么TiDB的PREPARE语句不能覆盖所有注入路径
TiDB支持PREPARE和EXECUTE，但以下场景它完全失效：
- 动态表名（如
SELECT * FROM ?）在TiDB中直接报错ERROR: syntax error at or near "?"，迫使业务改用字符串拼接 - ORDER BY / GROUP BY 后的字段名无法参数化，
ORDER BY ?非法，只能拼接；攻击者传sort=created_at, (SELECT password FROM mysql.user LIMIT 1)即可触发子查询泄露 - ShardingSphere-Proxy或TiDB Binlog同步链路中，
INSERT INTO order_2024这类带年份后缀的表名，若路由逻辑未参数化shard_key，恶意值会透传到物理TiKV节点 - Seata AT模式下的全局事务补偿SQL、MQ消费端直连TiDB执行的清理语句，往往跳过HTTP层参数化拦截
必须下沉到驱动层做AST级校验
在数据库驱动封装层拦截原始SQL字符串，而非依赖中间件或WAF规则匹配：
- Go场景：重写
database/sql.Conn.QueryContext，对query参数做AST解析，拒绝含${}、fmt.Sprintf、+拼接痕迹的调用 - Java场景：用Byte Buddy在类加载期hook
PreparedStatement.execute，检查this.sql字段是否含运行时变量插值（如"WHERE id = " + id） - Python场景：monkey patch
psycopg2.cursor.execute，用ast.parse()检测f-string或%格式化结构 - 关键点：CLI脚本、定时任务、K8s Job中的TiDB连接必须复用同一套驱动hook，否则就是盲区
动态语法位置必须白名单硬校验
表名、排序字段、分库键这些无法参数化的部分，没有“可选”一说，只有白名单：
- 表名：从配置中心读取
sharding-tables=["order_2024", "order_2025"]，用in_array(table_name, valid_tables)校验，不匹配直接返回HTTP 400 - 排序字段：建立映射表
map[string]string{"created": "created_at", "amount": "total_amount"}，用户只传key，代码查表转义value - 分库键值：若
shard_key = ?未参数化，恶意值会穿透到TiKV；必须确保所有WHERE条件中shard_key字段都走PreparedStatement绑定 - 注意：
allowMultiQueries=true必须禁用——它让SELECT 1; DROP TABLE users;逃逸参数化保护
最常被忽略的是连接池初始化SQL和事务补偿逻辑。比如Druid的initConnectionSqls若配了SET tidb_opt_agg_push_down=1，一旦该语句被注入篡改，就可能影响后续所有查询的执行计划；而Seata的undo_log回滚SQL若没走驱动层hook，就是天然注入通道。
