MySQL函数和视图是两种完全独立的数据库对象：函数是返回单值的可调用计算单元，视图是封装SELECT查询的命名结果集，二者目的、能力与机制均不同。

MySQL 函数和视图没有直接依赖关系，它们是两种完全独立的数据库对象，解决的问题不同、使用方式不同、底层机制也不同。

函数和视图根本不是一个东西

函数（FUNCTION）是可调用的计算单元，必须有返回值，能接收参数、执行逻辑、返回标量（如一个数字、字符串或日期），常用于 SELECT 表达式中参与计算；而视图（VIEW）是封装好的 SELECT 查询语句，本质是“命名的查询结果集”，不接受参数，不能执行写操作（除非是可更新视图且满足严格条件），也不做任何计算——它只是把一堆表连接 + 过滤 + 投影逻辑“存起来”，下次查就 SELECT * FROM view_name。

• 函数示例：SELECT add_numbers(5, 3) AS result; → 返回 8
• 视图示例：SELECT * FROM high_value_users; → 返回一组行，每行来自 users JOIN orders 的动态结果

为什么有人觉得它们“有关”？——常见混淆点

表面上看，两者都“封装了 SQL 逻辑”，容易被当成同类工具，但封装目的和能力边界完全不同：

• 函数不能替代视图：你无法用函数返回多行多列的结果集（MySQL 不支持表值函数）；RETURN 只能返回单个值。
• 视图不能替代函数：视图里不能写 IF、WHILE、变量赋值等过程式逻辑；它只是静态 SQL 查询定义。
• 可以一起用，但不是“组合关系”：你可以在视图的 SELECT 里调用函数，比如 SELECT id, UPPER(name), get_status(id) FROM users —— 这属于“视图引用函数”，而非函数依赖视图。

数据封装场景下，选函数还是视图？

判断依据很简单：你要封装的是「一行一结果」的计算逻辑，还是「一批结构化数据」的查询逻辑？

• 需要按用户 ID 计算积分等级？→ 写 FUNCTION get_level(user_id INT)
• 需要反复查“近 30 天下单且未发货的订单列表”？→ 建 VIEW pending_shipments
• 需要隐藏薪资字段只暴露脱敏后的等级？→ 视图 + 函数配合：SELECT name, department, get_level(user_id) AS level FROM employees 封装进视图

CREATE VIEW employee_summary AS
SELECT 
  name,
  department,
  get_level(id) AS level
FROM employees
WHERE status = 'active';

容易踩的坑：别强行混用

实际开发中常见误用：

• 想用函数返回一个“用户+订单汇总表”，结果只能返回第一个用户的汇总值（函数强制单值返回）
• 在视图里写 SET @var := 1; 或调用存储过程——MySQL 视图定义中禁止过程式语句，会报错 ERROR 1351 (HY000): View's SELECT contains a variable or parameter
• 以为给视图加个函数就能“参数化”，比如 CREATE VIEW v AS SELECT * FROM t WHERE id = my_func() —— 这样写看似灵活，实则每次查都执行函数，且无法利用索引，性能极差，还失去视图本意（逻辑复用）

真正需要参数化查询时，应该用存储过程（PROCEDURE）或应用层拼接，而不是硬塞进视图或函数里。