视图适合只读数据抽象，不适合业务逻辑封装；其本质是保存的SELECT语句，不支持变量、流程控制、事务或DML操作，仅能返回结果集，无法实现分支判断或状态变更逻辑。
视图适合只读数据抽象，不适合业务逻辑封装
视图本质是保存的 SELECT 语句，它不支持变量、流程控制、事务或 DML 操作（如 INSERT/UPDATE），只能返回结果集。你无法在视图里做“根据用户等级计算折扣”这类带分支或状态变更的逻辑。
常见错误现象：试图在视图中用 CASE WHEN 模拟业务规则后，又想通过 UPDATE 修改该字段——这会失败，因为多数复杂视图（含聚合、DISTINCT、多表 JOIN）默认不可更新。
- 适用场景：权限隔离（如给客服只暴露
v_customer_basic）、简化高频查询（如v_order_summary封装订单+用户+商品联查） - 性能影响：每次查询视图，MySQL 都要重写并优化其底层
SELECT，嵌套视图（如基于另一个视图创建）会让优化器更难生成高效执行计划 - 可维护风险：视图定义里若用了列别名或函数（如
DATE(created_at)），下游应用依赖这些字段名时，一旦基表结构变更，SHOW CREATE VIEW查到的定义可能已和实际行为脱节
存储过程能封装完整业务逻辑，但必须承担耦合代价
存储过程支持 DECLARE 变量、IF/WHILE、临时表、事务控制和多语句组合，真正适合封装“扣库存+写日志+发通知”这类原子操作。但它把逻辑锁死在数据库层，调试困难、版本难追踪、跨库迁移几乎不可能。
典型踩坑点：CALL proc_update_stock(1001, 5) 执行成功，但没检查返回的 OUT 参数是否为 -1（表示库存不足），导致应用层误判为更新成功；或者过程里用了 SELECT ... INTO @var，却忘了 @var 是会话级变量，高并发下值被覆盖。
- 参数差异：
IN参数传入值，OUT参数传出结果，INOUT可双向传递——但调用时必须显式声明变量接收OUT，比如CALL proc_calc_tax(1000, @tax); SELECT @tax; - 安全边界：存储过程中若拼接字符串构造动态 SQL（如
CONCAT('SELECT * FROM ', table_name)），且table_name来自输入参数，就会触发 SQL 注入——必须用白名单校验或QUOTE()处理 - 性能真实收益：只有涉及多轮查询+中间结果复用（如先查出一批 ID，再用
IN批量更新）时，才比应用层循环调用快；单条INSERT包一层存储过程反而增加解析开销
别混淆“能用”和“该用”：简单过滤走视图，状态变更走存储过程
判断依据不是技术能力，而是职责边界。视图负责“怎么看数据”，存储过程负责“怎么改数据”。比如用户资料页展示需要头像、昵称、会员等级、最近订单数——全用视图；但“升级会员”操作必须包含检查余额、扣款、更新等级、记录流水四步，就必须用存储过程保证原子性。
容易被忽略的细节：MySQL 的视图默认不校验基表是否存在（CREATE VIEW 成功不代表能查），而存储过程创建时会校验所有引用对象——但运行时若表被删，错误直到 CALL 才抛出，不是定义时。
