MySQL视图是实时展开的虚拟表，不存储数据；存储过程需显式调用，有独立作用域；二者混用易引发性能与维护陷阱，性能取决于底层表结构与索引。
视图在 MySQL 执行时是实时展开的，不是物化快照
MySQL 视图本身不存储数据，每次查询 SELECT * FROM my_view 时，都会把视图定义中的 SELECT 语句“内联展开”到外层查询中，再优化执行。这意味着：
- 视图里若引用了慢查询或未加索引的表，调用视图也会一样慢
- 不能对大多数视图执行
INSERT/UPDATE（除非满足可更新视图的所有条件，比如无聚合、无DISTINCT、只查单表等） -
EXPLAIN查看视图执行计划时，看到的是展开后的语句，不是视图名本身
CREATE VIEW active_users AS SELECT id, name FROM users WHERE status = 'active';
执行 SELECT * FROM active_users WHERE id > 100，实际等价于：
SELECT id, name FROM users WHERE status = 'active' AND id > 100;
存储过程执行需显式调用，且作用域独立
存储过程不会自动运行，必须用 CALL proc_name() 显式触发。它有自己的变量作用域、错误处理逻辑和执行上下文，与调用它的会话共享临时表、用户变量（@var），但不共享局部变量（DECLARE var INT）。
- 参数类型必须严格匹配：
IN/OUT/INOUT不可混用；传入NULL时注意判空逻辑 - 过程内若含动态 SQL（
PREPARE+EXECUTE），SQL 模式（如sql_mode）以执行时会话为准，不是创建时 - 事务控制需显式写
START TRANSACTION/COMMIT；存储过程本身不开启新事务
DELIMITER $$ CREATE PROCEDURE get_user_count(OUT cnt INT) BEGIN SELECT COUNT(*) INTO cnt FROM users WHERE deleted = 0; END$$ DELIMITER ; CALL get_user_count(@c); SELECT @c;
视图和存储过程混用时的常见陷阱
两者混合使用容易放大隐藏问题：
- 在存储过程中
SELECT ... FROM my_view：视图展开后可能使原本简单的查询变成多表嵌套，优化器误判；尤其当视图含子查询或JOIN时，EXPLAIN输出会变复杂 - 视图依赖的表被存储过程
DROP或ALTER后，视图仍存在但下次查询直接报错Table doesn't exist，不会提前校验 - 存储过程里用
CREATE VIEW动态建视图？MySQL 不允许——语法错误ERROR 1357 (HY000): Can't declare variable or condition inside a stored function or trigger（实际限制更严，多数 DDL 在 SP 中禁止）
调试和性能定位的关键动作
遇到执行异常或变慢，优先确认这两点：
- 查视图定义：
SHOW CREATE VIEW view_name，复制其SELECT部分单独执行并EXPLAIN - 查存储过程逻辑：
SHOW CREATE PROCEDURE proc_name，重点关注是否有隐式类型转换（如字符串字段与数字参数比较）、是否遗漏DECLARE CONTINUE HANDLER导致错误中断 - 开启慢日志并设置
long_query_time = 0，捕获视图/SP 内部真实耗时语句（注意：慢日志记录的是最终展开后的语句，不是CALL或视图名）
视图和存储过程本身不提升性能，它们只是封装。真正影响执行效率的，永远是底层表结构、索引、数据分布和查询写法。
