MySQL事务是InnoDB引擎支持的ACID特性操作单元，需显式开启并提交，确保数据一致性，但不保证业务逻辑正确且受长事务和跨库限制。
MySQL事务是一组逻辑上关联的SQL操作，作为一个不可分割的整体来执行。它的核心目标是确保数据在并发环境下的完整性与一致性——要么全部成功，要么全部失败，不存在中间状态。
事务必须满足ACID四大特性
原子性（Atomicity）：事务是最小执行单元，内部所有操作不可拆分。比如转账时扣款和入账必须同时生效或同时撤销，不能只完成一半。
一致性（Consistency）：事务前后，数据库始终处于合法状态。例如A、B账户总余额在转账前后必须保持不变，这是由业务规则定义的“一致”。
隔离性（Isolation）：多个事务并发执行时互不干扰。MySQL通过隔离级别控制可见性，避免脏读、不可重复读和幻读等问题。
持久性（Durability）：一旦事务提交，修改就永久保存到磁盘，即使系统崩溃也不会丢失。
事务依赖InnoDB存储引擎
MySQL默认的MyISAM引擎不支持事务，只有InnoDB引擎完整支持ACID特性。可通过SHOW ENGINES命令确认当前引擎是否支持transaction。
建表时需显式指定：
CREATE TABLE t1 (...) ENGINE=InnoDB;
事务的基本操作流程
MySQL默认开启自动提交（autocommit=1），每条SQL语句单独成一个事务。如需多语句协同，需手动控制：
- 用START TRANSACTION或BEGIN显式开启事务
- 执行一组相关DML语句（如UPDATE、INSERT、DELETE）
- 全部成功则执行COMMIT提交；任一出错可执行ROLLBACK回滚到初始状态
- 也可用SAVEPOINT设置中间保存点，实现部分回滚
事务不是万能的，有使用前提
事务无法解决所有问题：
- 它不保证业务逻辑正确（比如转错人、输错金额），只保证SQL执行层面的原子与一致
- 长事务会占用锁资源、影响并发性能，应尽量缩短执行时间
- DDL语句（如ALTER TABLE）在多数版本中会隐式提交当前事务，需注意顺序
- 跨库、跨服务的操作超出单机事务能力，需借助分布式事务方案
