多数业务场景下不应优先使用存储过程——它将逻辑锁死在数据库中，导致调试、测试、上线困难且协作成本高；仅高频复用、稳定不变、强一致性的原子操作（如库存扣减）才适合封装。
SQL 复杂逻辑该不该写成存储过程？
多数业务场景下，存储过程不是首选——它把逻辑锁死在数据库里，调试难、测试难、上线难，团队协作成本陡增。真正适合封装的，是那些「高频复用 + 稳定不变 + 涉及多表强一致性」的原子操作，比如库存扣减、订单状态机跃迁、分账结算流水生成。
常见错误现象：ORA-04068: existing state of packages has been discarded（Oracle）、ERROR 1449: The user specified as a definer does not exist（MySQL），本质都是权限/上下文漂移导致的运行时崩塌。
- 优先用应用层函数封装 SQL 片段，配合参数化查询，保留调试入口和链路追踪能力
- 若必须用
存储过程，定义时显式指定DEFINER = 'app_user'@'%'（MySQL）或使用AUTHID CURRENT_USER（Oracle），避免权限继承陷阱 - 禁止在存储过程中调用外部 API 或写文件——它不该承担非数据职责
WHERE 条件里用函数导致全表扫描怎么办？
WHERE YEAR(create_time) = 2024 这类写法，几乎必然让 create_time 上的索引失效。优化核心不是“怎么写对”，而是“怎么让优化器能用上索引”。
使用场景：时间范围查询、状态码模糊匹配、多字段组合筛选。
- 把函数移到右边：
WHERE create_time >= '2024-01-01' AND create_time - 状态字段别用
LIKE '%paid%'，改用枚举值或单独加status_code字段，索引才有效 - MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_year ON orders ((YEAR(create_time)))，但注意仅限确定性函数
JOIN 太多查得慢，又不能拆成多次查询？
5 张表以上 JOIN，性能拐点通常出现在执行计划出现 Using temporary; Using filesort 或 rows_examined 暴涨时。这不是语法问题，是数据访问模式和统计信息失准的综合结果。
性能影响：单次查询耗时可能从 20ms 增至 2s，且并发一高就卡住连接池。
- 先看
EXPLAIN FORMAT=JSON，重点盯filtered字段——低于 10% 就说明条件没走好索引 - 把大表放
JOIN左侧，小表放右侧（MySQL 基于嵌套循环），避免中间结果集爆炸 - 临时表不是万能解：用
CREATE TEMPORARY TABLE缓存中间结果前，确认其生命周期可控，且不会被长事务阻塞
UPDATE 多行时锁表还是锁行？
MySQL InnoDB 下，UPDATE 默认走行级锁，但前提是你用了索引条件。一旦 WHERE 不走索引，就会升级为表级锁——尤其在 UPDATE ... ORDER BY ... LIMIT 场景下极易中招。
容易踩的坑：UPDATE user SET status = 1 WHERE name LIKE 'zhang%'，如果 name 没索引，整张表被锁死。
- 执行前必跑
EXPLAIN确认type是ref或range，不是ALL - 批量更新分页做：
UPDATE orders SET paid = 1 WHERE id BETWEEN 10000 AND 10100 AND paid = 0，避免LIMIT配合无主键条件 - 业务允许时，用
SELECT ... FOR UPDATE显式加锁并校验再更新，比盲目UPDATE更可控
复杂点在于：同一业务逻辑里，读、写、删可能各自触发不同锁策略，而事务隔离级别（READ-COMMITTED vs REPEATABLE-READ）会让表现完全不同。不测执行计划，光看 SQL 写法根本没法预判实际行为。
