mysql服务端不支持try-catch语法，错误处理需在应用层实现；存储过程中的declare handler功能有限，无法替代应用级异常处理；正确做法是确保出错时显式执行rollback，避免长事务和隐式提交导致数据不一致。
MySQL事务里try-catch根本不存在
MySQL服务端本身不支持try-catch语法，这是应用层（比如Java、Python、PHP）才有的控制结构。你在MySQL存储过程中看到的DECLARE HANDLER只是有限的错误捕获机制，不能替代应用代码里的异常处理逻辑。
常见错误现象：在SQL脚本里写try { START TRANSACTION; ... } catch { ROLLBACK; }，直接报语法错误——因为MySQL根本不认识try和catch。
- 真正起作用的回滚动作，必须由客户端程序显式调用
ROLLBACK或触发自动回滚 - 如果应用没做异常捕获，或者捕获后忘了调用
ROLLBACK，事务会一直挂起，可能锁表、阻塞其他操作 - MySQL 8.0+ 支持
GET DIAGNOSTICS配合DECLARE CONTINUE HANDLER做简单错误响应，但无法跳出当前执行流，也不适合复杂业务逻辑
应用层怎么正确配对START TRANSACTION和ROLLBACK
关键不是“有没有try-catch”，而是“有没有在出错路径上确保ROLLBACK被执行”。不同语言写法差异大，但核心逻辑一致：开启事务 → 执行业务SQL → 成功则COMMIT，失败则ROLLBACK。
使用场景：转账、库存扣减、多表关联更新等必须原子性的操作。
- Java JDBC中，别依赖
Connection.setAutoCommit(false)后就不管了——必须在catch块里调用connection.rollback()，且要检查connection是否还有效 - Python
pymysql或mysql-connector-python中，cursor.execute()抛异常时连接不会自动回滚，必须手动conn.rollback() - Node.js
mysql2的beginTransaction()之后，一旦query()失败，得立刻rollback()，不能等后续语句再处理 - 所有语言都要注意：
ROLLBACK本身也可能失败（比如连接已断），所以rollback()调用也建议包一层try，至少记个日志
autocommit=0和隐式提交的坑
很多人以为设了autocommit=0就万事大吉，结果发现某些SQL还是“偷偷提交”了——这是因为MySQL有隐式提交规则，跟语句类型强相关。
参数差异：autocommit是会话级变量，每个新连接默认为1；设成0后，只有显式COMMIT/ROLLBACK或遇到隐式提交语句才会结束事务。
- 以下语句会触发隐式提交：
CREATE TABLE、DROP TABLE、ALTER TABLE、TRUNCATE TABLE、LOCK TABLES、SET autocommit = 1 - 哪怕你在事务中间执行了一个
CREATE TEMPORARY TABLE，前面所有修改也会被提交，ROLLBACK无效 -
SELECT不会隐式提交，但SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE会参与当前事务，必须搭配COMMIT/ROLLBACK - 用
SHOW VARIABLES LIKE 'autocommit'确认当前会话状态，别只信配置文件里的全局值
超时导致的自动回滚很难排查
事务长时间没COMMIT或ROLLBACK，MySQL不会一直等。一旦超过innodb_lock_wait_timeout（默认50秒）或wait_timeout（默认8小时），连接可能被KILL，事务强制回滚——但应用层未必知道这事发生了。
性能影响：长事务会拖慢MVCC清理，堆积undo log，甚至让purge线程卡住，最终拖累整个实例。
-
SHOW PROCESSLIST里看到Command为Sleep、Time持续增长，大概率是有事务没关 - 查未提交事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'RUNNING'; - 应用里所有
START TRANSACTION都该配超时控制，比如JDBC URL加sessionVariables=innodb_lock_wait_timeout=10 - 最危险的是：网络抖动导致
COMMIT请求发出去但没收到响应，应用以为失败而重试，实际数据库已经提交了——这类问题必须靠幂等设计兜底，不是靠回滚能解决的
事务真正的难点不在语法，而在你能不能清晰画出每条执行路径上COMMIT和ROLLBACK的触发点，以及当网络、连接、MySQL自身行为不按预期走时，系统是否还处于可预测状态。
