innodb是mysql中唯一默认支持acid事务的存储引擎，myisam不支持事务；需显式指定engine=innodb建表，并通过start transaction开启事务、显式commit或rollback结束；默认隔离级别为repeatable read，存在幻读风险；长事务会加剧锁竞争与主从延迟，须监控并限制其时长。
事务只在 InnoDB 中真正生效
MySQL 的 MyISAM 存储引擎不支持事务，START TRANSACTION、COMMIT、ROLLBACK 对它完全无效，执行后不会报错但也不会回滚——这是最常被忽略的前提。InnoDB 是唯一默认支持 ACID 事务的内置引擎，且必须确保表创建时显式指定 ENGINE=InnoDB，否则即使数据库默认引擎是 InnoDB，CREATE TABLE 不带 ENGINE 子句时仍可能因旧配置或 SQL 模式导致意外使用 MyISAM。
检查方式：
SHOW CREATE TABLE `your_table`;确认输出中包含
ENGINE=InnoDB；若不是，用 ALTER TABLE `your_table` ENGINE=InnoDB; 转换（注意：该操作会锁表并重建数据）。
手动开启事务后必须显式提交或回滚
InnoDB 默认是自动提交模式（autocommit=1），每条 INSERT/UPDATE/DELETE 都立即持久化。要启用事务控制，需先关闭自动提交：
SET autocommit = 0;或更推荐的方式：
START TRANSACTION;后者会隐式设置
autocommit=0 并开始新事务。
- 忘记
COMMIT：连接断开或超时后事务自动回滚，看似“没保存”，实则是未提交导致 - 误用
ROLLBACK：在已COMMIT后再执行，不会报错但无任何效果 - 嵌套事务不被支持：InnoDB 不支持真正的嵌套事务，
SAVEPOINT是唯一可回滚到的中间点，例如：SAVEPOINT sp1;<br>UPDATE accounts SET balance = balance - 100 WHERE id = 1;<br>ROLLBACK TO SAVEPOINT sp1;
事务隔离级别影响并发行为和一致性保障
MySQL 默认隔离级别是 REPEATABLE READ，但它在可重复读下仍可能发生“幻读”（新插入行被后续 SELECT 看到）。如果业务需要严格避免幻读，应改用 SERIALIZABLE，但会显著降低并发性能。
查看当前会话级别：
SELECT @@transaction_isolation;修改方式：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;常见组合与风险：
启科网络商城系统由启科网络技术开发团队完全自主开发，使用国内最流行高效的PHP程序语言，并用小巧的MySql作为数据库服务器，并且使用Smarty引擎来分离网站程序与前端设计代码，让建立的网站可以自由制作个性化的页面。 系统使用标签作为数据调用格式，网站前台开发人员只要简单学习系统标签功能和使用方法，将标签设置在制作的HTML模板中进行对网站数据、内容、信息等的调用，即可建设出美观、个性的网站。
-
READ UNCOMMITTED：能读到未提交变更，脏读风险高，极少用于生产 -
READ COMMITTED：每次SELECT都读最新已提交快照，避免脏读，但不可重复读（两次查同一行结果可能不同） -
REPEATABLE READ（默认）：事务内多次SELECT结果一致，但范围查询可能受新插入影响（幻读） -
SERIALIZABLE：强制串行执行，加锁粒度最大，吞吐最低
长事务是锁竞争和主从延迟的隐形推手
一个未结束的事务会持续持有行锁、间隙锁甚至表级元数据锁（MDL），阻塞其他 DDL（如 ALTER TABLE）和 DML。更隐蔽的问题是：主库上长时间运行的事务，会导致从库复制线程卡在等待相同事务提交，表现为 Seconds_Behind_Master 持续增长。
排查方法：
SELECT * FROM information_schema.INNODB_TRX\G重点关注
TRX_STARTED 和 TRX_STATE 字段；若发现 TRX_STATE = 'RUNNING' 且 TRX_STARTED 是几分钟前，基本可判定为长事务。
预防建议：
- 应用层控制事务边界：DML 操作尽量靠近业务逻辑起点，避免在事务中调用外部 HTTP 请求或文件读写
- 设置超时：在连接初始化时加上
SET innodb_lock_wait_timeout = 30;（单位秒），避免无限等待 - 监控告警：定期查
INNODB_TRX表，对运行超过 10 秒的事务触发告警
事务不是万能保险，它解决的是单次原子操作的一致性，而非长期数据状态保护；备份、binlog、主从架构才是应对误删、硬件故障的真正防线。
