视图里能直接调用自定义函数吗？
可以，但要注意权限和确定性。MySQL 要求被视图引用的函数必须是
DETERMINISTIC（或声明为
READS SQL DATA），否则创建视图会报错：
ERROR 1351 (HY000): View's SELECT contains a function that is not allowed。
常见踩坑点：
忘记在CREATE FUNCTION语句中显式指定特性，哪怕函数逻辑确实是确定性的 用了
NOW()、
RAND()、
UUID()这类非确定性函数，却没加
NOT DETERMINISTIC声明（注意：即使加了，视图仍可能因安全限制拒绝使用） 函数体里执行了写操作（如
INSERT），这直接违反视图只读语义，MySQL 会拦截
用视图封装函数逻辑时，性能怎么保障？
视图本身不存储数据，每次查询都重跑底层 SQL —— 如果里面嵌套了计算密集型函数（比如字符串分词、JSON 解析、地理距离计算），性能会明显下降。
实操建议：
对高频调用的函数结果做冗余字段 + 索引，比如把get_user_level(user_id)的返回值存到
users.level_cache并定期更新 避免在视图
WHERE条件里用函数包裹字段，例如
WHERE UPPER(name) = 'JOHN'会导致索引失效；应改用
name = 'john'配合大小写敏感校对集 用
EXPLAIN FORMAT=TREE查看视图展开后的执行计划，确认函数是否被下推或提前过滤
视图 + 内置函数组合的典型安全陷阱
内置函数如
USER()、
CURRENT_USER()、
CONNECTION_ID()在视图中行为容易误判。它们在视图里取的是「调用者上下文」，不是「定义者上下文」。
举例：管理员创建了如下视图
CREATE VIEW my_orders AS SELECT *, USER() as caller FROM orders WHERE user_id = SUBSTRING_INDEX(USER(), '@', 1);
问题在于：
SUBSTRING_INDEX(USER(), '@', 1)每次都取当前查询用户的用户名，但如果视图被另一个用户通过
SQL SECURITY DEFINER方式调用，实际匹配的
user_id就可能错乱。
更稳妥的做法：
显式传参：不用隐式函数，改由应用层传入user_id作为视图参数（MySQL 8.0+ 可配合 CTE 或预处理语句模拟） 严格限定
SQL SECURITY类型，默认是
DEFINER，但若定义者权限过高，可能引发越权；生产环境建议统一用
INVOKER禁用高危函数：在数据库配置中设置
disabled_storage_engines不够，还需靠规范审查禁止在视图中使用
LOAD_FILE()、
UNHEX()等可被利用的函数
函数返回 NULL 时，视图里怎么避免空值传播失控？
MySQL 函数返回
NULL是合法的，但一旦进入视图的
SELECT列或
WHERE条件，容易引发意外过滤或聚合中断。比如：
CREATE FUNCTION safe_divide(a DOUBLE, b DOUBLE) RETURNS DOUBLE RETURN a / b;
当
b = 0时返回
NULL，如果这个函数用在视图的
WHERE中：
WHERE safe_divide(x, y) > 10，整行会被静默排除——连
IS NULL都捕获不到，因为
NULL > 10结果就是
UNKNOWN。
应对方式很实际：
函数内部主动防御：用IFNULL()或
COALESCE()包裹关键返回值，比如
RETURN COALESCE(a / NULLIF(b, 0), 0);视图字段命名带提示：如将
safe_divide(x,y)命名为
ratio_safe，并在注释里标明 “可能为 0 或 NULL” 应用层不依赖视图字段做非空断言：需要判断是否有效时，额外查一次
safe_divide(x,y) IS NOT NULL，别省这一句
函数和视图的耦合越深，调试路径就越长。上线前务必用真实数据集跑一遍
SELECT * FROM view_name WHERE ...，重点看边界值和异常输入下的输出是否符合预期。
