sql视图不支持参数和模糊查询，应改用表值函数（sql server）或视图+预编译语句（postgresql/mysql），并注意索引失效与sql注入风险。
SQL 视图本身不支持参数，更不支持直接传入模糊查询值（比如 LIKE '%?%'），所以“参数化视图”是伪命题——你真正需要的，是能安全、高效复用模糊查询逻辑的替代方案。
为什么不能在视图里写 WHERE name LIKE '%@keyword%'
视图定义是静态 SQL，不接受运行时参数。哪怕你用 CREATE VIEW v_users AS SELECT * FROM users WHERE name LIKE '%abc%'，这个 '%abc%' 也是固化死的。试图在视图里引用变量（如 T-SQL 的 @keyword 或 PL/pgSQL 的 $1）会直接报错：Invalid column name '@keyword' 或 ERROR: there is no parameter $1。
根本原因不是语法限制，而是视图本质是“预定义的命名查询”，不是函数。
用表值函数（TVF）替代：SQL Server 示例
SQL Server 中最贴近需求的方案是内联表值函数（Inline TVF），它支持参数、可被优化器展开、性能接近视图，且天然支持 LIKE 模糊匹配。
示例：
CREATE FUNCTION dbo.SearchUsers(@keyword NVARCHAR(50))
RETURNS TABLE
AS
RETURN (
SELECT id, name, email
FROM users
WHERE name LIKE '%' + @keyword + '%'
OR email LIKE '%' + @keyword + '%'
);
调用方式和视图几乎一样：
SELECT * FROM dbo.SearchUsers(N'john');
- 必须用
N''前缀避免隐式转换导致索引失效 - 不要用
CONCAT('%', @keyword, '%')—— 在旧版本 SQL Server 中可能阻止索引 SEEK - 若字段有全文索引，应改用
CONTAINS()而非LIKE，否则无法利用索引
PostgreSQL / MySQL 怎么办？用准备语句 + 视图组合
PostgreSQL 和 MySQL 不支持返回表的标量函数（MySQL 直到 8.0.34 才实验性支持），但可通过“视图 + 应用层准备语句”解耦逻辑与参数：
先建一个不含过滤条件、只封装基础字段和 JOIN 的视图：
CREATE VIEW v_user_search_base AS SELECT u.id, u.name, u.email, p.phone FROM users u LEFT JOIN phones p ON u.id = p.user_id;
然后在应用中使用带参数的准备语句查询该视图：
PREPARE search_stmt AS SELECT * FROM v_user_search_base WHERE name ILIKE $1 OR email ILIKE $1;EXECUTE search_stmt ('%alice%');
- 视图只做结构抽象，不承担过滤责任，避免重复定义复杂 JOIN
- 模糊值由应用拼好（
'%value%'）再传入，确保ILIKE或LIKE可走索引（如果字段有前导通配符索引或表达式索引） - MySQL 注意：必须用
CONCAT('%', ?, '%')在客户端拼接，服务端不支持动态LIKE参数绑定
最容易被忽略的坑：索引失效和注入风险
所有模糊查询方案都绕不开两个硬约束：
- 以
%开头的LIKE（如LIKE '%word'）基本无法使用 B-tree 索引；只有LIKE 'prefix%'才能高效 SEEK。想支持前后模糊，得建pg_trgm（PostgreSQL）或使用FULLTEXT（MySQL） - 任何手动字符串拼接（如
"'%"+keyword+"%'"）都可能引入 SQL 注入，必须依赖数据库驱动的参数绑定，而不是拼 SQL 字符串 - 视图或函数里如果用了
UPPER(name) LIKE UPPER(@k)，即使加了函数索引，也要确认统计信息是否及时更新，否则执行计划可能退化为全表扫描
没有银弹。所谓“参数化视图替代方案”，本质是在安全、可维护、可优化之间做取舍——选对工具只是第一步，后续必须配合索引策略和执行计划验证。
