动态SQL在多源异构聚合中避不开，因不同数据库、协议及字段定义差异迫使运行时拼接表名、列名等标识符，而参数化仅支持值替换；必须通过白名单校验、类型强转、权限隔离与配置中心统一管理来保障安全与可维护性。

动态SQL在多源异构聚合中为什么避不开

多源异构场景下，你几乎无法完全避免动态SQL：不同数据库（MySQL、PostgreSQL、时序DB如InfluxDB）、不同协议（Modbus解析后转SQL、SCADA日志映射字段）、甚至同一张表在不同数据源里字段名/类型不一致（比如device_id在A系统是VARCHAR，在B系统是BIGINT），都迫使你在运行时拼接表名、列名或WHERE条件。这时候参数化查询的?或%s根本没法覆盖——它们只能替换**值**，不能替换**标识符**（表名、列名、ORDER BY子句等）。

拼接表名/列名时必须做白名单校验

一旦要动态拼接FROM后的表名或SELECT里的字段，就不能靠“过滤单引号”或“转义反斜杠”糊弄过去。攻击者能轻易绕过这些规则，直接注入users; DROP TABLE logs--这种语句。

• 所有可拼接的标识符（如table_name、column_list）必须来自预定义的白名单字典，而不是用户输入原文
• 例如：前端传source=plc_vibration，后端查配置表确认该值映射到真实表名iot_plc_2024_q3，再拼进SQL；绝不允许把source原样插入
• 白名单校验逻辑必须在应用层完成，不能依赖数据库侧的视图或存储过程——因为源头SQL本身已失控
• 若需支持“用户自定义字段”，应改用JSON Schema约束字段名格式（如只允许^[a-zA-Z][a-zA-Z0-9_]{2,31}$），并严格比对白名单枚举值

WHERE条件拼接必须用参数化+上下文感知校验

多源聚合常需根据业务维度动态加WHERE，比如按产线ID、时间范围、设备状态筛选。这类条件看似可参数化，但实际容易踩坑：

• 时间范围拼接BETWEEN ? AND ?安全，但若用户传入start_time=2026-01-01; DROP TABLE alarms，而你没做类型强转就塞进参数，某些驱动（如旧版psycopg2）可能因类型推断失败导致回退到字符串拼接
• 枚举类条件（如status IN ('running', 'stopped')）不能简单用IN %s传元组——Python里cur.execute("... IN %s", (['running','stopped'],))会报错，必须展开为IN (%s, %s)并逐个绑定
• 数值型字段（如sensor_value > ?）务必先用int()或float()强制转换，捕获ValueError，防止传入123 OR 1=1这类字符串
• 特别注意时序数据库（如TimescaleDB）的time_bucket()函数调用——其interval参数（如'1 hour'）不可参数化，必须走白名单（['1 hour', '1 day', '7 days']）

权限隔离必须落到具体数据源实例

多源异构意味着你连的不是“一个数据库”，而是多个独立实例：OT侧的实时库、IT侧的运维日志库、第三方API代理的只读视图。每个实例的账号权限必须单独收敛：

• 连接PLC历史数据表的账号，只授予SELECT权限，且限定到具体schema（如plc_raw.*），禁用information_schema访问
• 聚合层账号不能复用ETL账号——ETL账号可能有CREATE TEMP TABLE权限，而聚合接口只需查结果，不该有建表能力
• 若使用Federated引擎或postgres_fdw跨库查询，确保远端账号也是最小权限，避免通过联邦表间接提权
• 最易被忽略的一点：WAF或网关层的日志记录功能，如果开启SQL语句采样，可能意外记录含敏感字段名的动态SQL——需关闭该采样或脱敏字段名

真正难的不是写对某一条SQL，而是当你的聚合逻辑要同时兼容西门子S7寄存器名、Kafka消息体里的JSON key、以及MySQL里带下划线的旧字段时，如何让白名单校验不变成维护噩梦。建议把所有合法标识符注册进配置中心，每次上线前跑一次校验脚本比对数据库元数据，而不是靠人肉维护字典。