动态sql视图不能用参数化查询，因视图创建属ddl操作，而参数化仅适用于dml执行阶段；标识符（如表名、列名）必须白名单校验，查询时仍需参数化，优先用函数或物化视图替代动态拼接。

动态SQL视图为什么不能用参数化查询

因为视图定义本身是DDL语句（CREATE VIEW），而参数化查询只作用于DML（如SELECT、INSERT）执行阶段。数据库在创建视图时必须立即解析并固化SQL结构，? 或命名占位符在DDL中不被识别——它们不是语法合法的标识符位置。试图把 WHERE user_id = ? 塞进 CREATE VIEW v AS SELECT ... 会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。

表名/列名等标识符无法参数化，必须白名单校验

当视图需要按租户切换表前缀（如 tenant_a_users vs tenant_b_users），或按业务类型拼接列（如 SELECT id, name, status_<env></env>），这些部分属于SQL标识符，不能走参数绑定。此时唯一可靠的做法是：在拼接前强制比对输入值是否落在预设白名单内。

• 用正则严格匹配表前缀：^[a-z][a-z0-9_]{2,31}$，拒绝含点号、反引号、连字符等非法字符
• 所有可选列名硬编码进字典：{"prod": "status_prod", "staging": "status_staging"}，用户输入仅作键查找，查不到就拒掉
• 避免“允许字母数字+下划线”这种宽泛规则——tenant_x`; DROP TABLE users; -- 仍能通过

运行时视图查询仍需参数化，别以为建完就安全了

很多人以为“视图建好了，后面查它就没事”，这是最大误区。视图只是封装了查询逻辑，一旦你在应用层用字符串拼接去调用它，比如：SELECT * FROM v_user_{tenant_id} WHERE id = '123'，那拼接点仍在应用代码里，漏洞照旧。

• 视图查询本身必须走参数化：用 SELECT * FROM v_user WHERE id = ?，而非拼接 id 值
• 如果视图名本身动态（如 v_user_{env}），那这个视图名也属于标识符，同样要白名单校验，不能靠过滤单引号解决
• 特别注意ORM场景：Sequelize的 sequelize.query("SELECT * FROM ?? WHERE id = ?", [viewName, id]) 中，第一个 ?? 是标识符占位符（需驱动支持），第二个 ? 是值占位符——二者机制完全不同，混用会失效

替代方案：优先用函数或物化视图绕过动态拼接

真正需要“按需生成视图逻辑”的场景，往往暴露的是设计缺陷。比起在DDL层硬拼，更健壮的路径是把动态性上移到应用或数据库函数层。

• 用MySQL函数封装逻辑：CREATE FUNCTION get_user_status(env VARCHAR(20)) RETURNS VARCHAR(20) READS SQL DATA ...，视图里直接调用 get_user_status('prod')
• PostgreSQL可用 pg_get_viewdef() 动态检查视图定义，配合行级安全策略（RLS）控制数据可见性，而非靠多个视图隔离
• 若必须多视图，用部署脚本生成（CI/CD阶段），而非运行时拼接——视图名由发布流程决定，不接受用户输入

真正难防的从来不是1' OR '1'='1这种显性payload，而是开发者自己写的format_view_name(tenant_input)函数里，那个没做长度截断、没校验Unicode零宽空格、也没拒绝__双下划线前缀的分支逻辑。