declare exit handler for sqlexception 必须与 start transaction 配合使用才生效，否则不触发回滚；事务外声明无效，且 continue handler 不适用于事务场景，应统一用 exit handler 并配合 resignal 保证错误透传。
DECLARE EXIT HANDLER FOR SQLEXCEPTION 必须配 START TRANSACTION 才生效
单独写 DECLARE EXIT HANDLER FOR SQLEXCEPTION 不会触发回滚，MySQL 完全不认——它只在当前事务上下文里起作用。如果你没显式开启事务（比如漏了 START TRANSACTION 或 BEGIN），那 handler 就是摆设，报错后照样继续往下跑，甚至可能把部分成功语句提交出去。
常见错误现象：INSERT 报 ERROR 1062 (23000): Duplicate entry，handler 没触发，后续 COMMIT 把前面成功的 UPDATE 一起落库了。
-
START TRANSACTION必须放在DECLARE EXIT HANDLER之后、业务 SQL 之前；顺序反了 handler 就监听不到事务内的错误 - 不能依赖默认 autocommit=1 下的“隐式事务”：每条语句都是独立事务，
ROLLBACK对它无效 - 如果过程里混用了
DROP TABLE、CREATE TABLE等隐式提交语句，事务会在该语句执行时自动提交，后续ROLLBACK只能撤回它之后的操作
用 RESIGNAL 而不是 SIGNAL 或静默吞掉错误
只写 ROLLBACK 不够，调用方（比如 PHP 的 mysqli）收不到原错误，日志里只看到“存储过程执行成功”，根本没法排查。用 RESIGNAL 是最干净的做法：回滚完立刻把原始错误原样抛回去，SQLSTATE、错误码、MESSAGE_TEXT 全保留。
别手写 SIGNAL SQLSTATE '45000' 再拼接消息——MESSAGE_TEXT 超过 128 字符会直接报 Error Code: 1648，且丢失原始错误码。
-
RESIGNAL是 MySQL 5.5+ 原生支持，无需截断或重构造 - 不要在 handler 里插
GET DIAGNOSTICS再SET变量——只要中间有任意一条非GET DIAGNOSTICS语句，诊断信息就清空了 - 如果真要记录日志，必须在
GET DIAGNOSTICS后立刻写入已存在的稳定表，且不能调用COMMIT/ROLLBACK
别用 CONTINUE HANDLER 替代 EXIT 处理事务异常
CONTINUE 的语义是“出错后继续执行下一条”，对事务场景极其危险。比如转账过程里第一笔 UPDATE 成功，第二笔因主键冲突失败，CONTINUE 会让控制流走到 COMMIT，结果前半段扣款已生效，后半段入账没做——钱就丢了。
只有极少数场景适合 CONTINUE：比如批量插入时想跳过单条重复数据，但整个过程不涉及资金/状态变更类强一致性操作。
- 事务体里一律用
DECLARE EXIT HANDLER FOR SQLEXCEPTION -
SQLWARNING和NOT FOUND不会触发SQLEXCEPTION，需要单独声明 handler（例如游标遍历结束） - 主键冲突这种典型错误属于
SQLEXCEPTION，对应 SQLSTATE'23000'或 MySQL 错误码1062，不用额外指定
应用层发起的事务，存储过程里不能替代 COMMIT/ROLLBACK 决策
PHP/Python 代码里用 mysqli->begin_transaction() 开启事务后，再 CALL 存储过程，这个事务生命周期完全由客户端控制。过程内部的 START TRANSACTION 会报错（ERROR 1305），而 COMMIT 或 ROLLBACK 会被忽略——MySQL 认为这是嵌套事务，实际只响应最外层连接发来的指令。
所以：要么让存储过程自己管理完整事务（适用于纯 DB 层逻辑），要么让应用层统一捕获异常并决定回滚（更常见、更可控）。
- 混合使用时，务必确认连接 autocommit 已设为 0：
SET autocommit = 0 - 过程里不要出现
SELECT ... INTO后直接IF判断再COMMIT这种“半手动”流程——容易漏掉分支或误判成功条件 - 真正难的是错误边界：比如
INSERT ... ON DUPLICATE KEY UPDATE不报错但没更新行，这种不算SQLEXCEPTION，得靠ROW_COUNT()判断
