最常见的原因是handler声明位置错误——必须在begin后、首个可执行语句前，且在变量和游标声明之后；其次为错误类型不匹配、未用get diagnostics提取上下文、混淆sqlexception/sqlwarning/not found触发条件。
MySQL存储过程中DECLARE HANDLER为什么没起作用
最常见的原因是 handler 声明位置不对——它必须放在存储过程体的最开头，且必须在任何 DECLARE 变量、游标之后，但在所有执行语句（如 SELECT、INSERT）之前。一旦顺序错乱，MySQL 会静默忽略 handler，错误照常抛出。
另一个高频问题是 handler 类型和错误不匹配：CONTINUE 和 EXIT 行为差异大，而错误条件写成 SQLSTATE '45000' 却去捕获一个主键冲突（SQLSTATE '23000'），自然失效。
-
DECLARE HANDLER必须紧跟在BEGIN后、首个可执行语句前 - 优先用
SQLSTATE值捕获，比MYSQL_ERRNO更稳定（例如主键冲突是SQLSTATE '23000'，不是1062） - 若 handler 内部再出错（比如写入日志表失败），默认会中断整个过程；加
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION可兜底，但要小心死循环
怎么让DECLARE HANDLER真正记录错误细节
handler 本身不保存错误上下文，GET DIAGNOSTICS 才是关键。光靠 SET error_msg = 'oops' 没用，得主动提取 SQLSTATE、错误码、消息文本。
注意 MySQL 5.6+ 才支持多参数 GET DIAGNOSTICS，低版本只能取第一个错误；且该语句必须紧接在出错语句之后，中间不能有其他 SQL 执行，否则诊断信息被覆盖。
- 标准写法：
GET DIAGNOSTICS CONDITION 1 @sqlstate = RETURNED_SQLSTATE, @errno = MYSQL_ERRNO, @text = MESSAGE_TEXT; - 务必在 handler 内第一条语句就调用
GET DIAGNOSTICS，不要先做INSERT或SELECT - 日志建议写入临时表或已存在的错误日志表，避免 handler 里再触发新错误
SQLEXCEPTION vs SQLWARNING vs NOT FOUND 怎么选
三者触发条件完全不同：SQLEXCEPTION 对应严重错误（如主键冲突、列不存在）；SQLWARNING 是警告级（如截断字符串、隐式类型转换）；NOT FOUND 专用于游标到达末尾。混用会导致预期外的行为。
特别注意：普通 SELECT ... INTO 查不到数据时，不会触发 NOT FOUND，除非它在游标 FETCH 中；而 INSERT ... SELECT 没匹配行，也不算 NOT FOUND，属于正常执行。
- 业务逻辑中需要“查无结果即退出”的场景，只对游标
FETCH有效；单条SELECT INTO应配合DECLARE CONTINUE HANDLER FOR NOT FOUND+ 后续判断变量是否为NULL -
SQLWARNING很容易被忽略，但某些数据质量场景（如INSERT被警告截断）需主动捕获 - 一个 handler 只能声明一次同类型条件，重复声明后者覆盖前者
调试时看不到错误？检查log_warnings和客户端设置
MySQL 默认不把 warning 当错误返回给客户端，所以即使触发了 SQLWARNING handler，命令行或某些驱动可能只显示 “Query OK”，让人误以为没出错。
更隐蔽的是：存储过程内错误被 handler 捕获后，过程状态仍是 “success”，客户端收不到错误信号，调用方可能继续执行后续逻辑，造成数据不一致。
- 临时开启详细日志：
SET SESSION log_warnings = 3;（MySQL 5.7+），可看到 warning 级别细节 - 客户端连接时加
--show-warnings参数，或代码中检查mysql_info()/mysqli->get_warnings() - handler 中务必用
SELECT或INSERT显式暴露错误状态，别依赖返回值或“静默处理”
DECLARE HANDLER。
