视图在 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或视图名）
视图和存储过程本身不提升性能，它们只是封装。真正影响执行效率的，永远是底层表结构、索引、数据分布和查询写法。
