mysql事务不生效的根本原因是innodb引擎未启用或配置不当：myisam引擎不支持事务，即使执行start transaction和commit也无法回滚；innodb_flush_log_at_trx_commit非1值会破坏持久性；隔离级别与sql写法不匹配导致锁失效；业务一致性需应用层校验，acid无法兜底逻辑正确性。
因为没它，订单扣了库存但没生成、转账扣了钱但没到账、并发修改导致数据错乱——这些不是“可能出问题”，而是必然发生。
事务不生效：InnoDB 引擎没开，ACID 就是空谈
MySQL 默认引擎可能是 MyISAM，它压根不支持事务。START TRANSACTION 和 COMMIT 语法能执行，但实际不会回滚、不加锁、不写 undo log。
- 确认当前表引擎：
SHOW CREATE TABLE your_table;，必须看到ENGINE=InnoDB - 建表时显式指定：
CREATE TABLE t (...) ENGINE=InnoDB;，别依赖默认值 - ALTER TABLE 切换引擎会锁表且耗时，线上慎用；批量迁移建议用
mysqldump --no-create-info+ 新表重建
COMMIT 后数据丢了：持久性（Durability）被配置悄悄关掉了
innodb_flush_log_at_trx_commit=0 或 =2 是性能陷阱，断电或崩溃就丢事务——尤其在主从复制中，binlog 和 redo log 不一致还会引发主从数据漂移。
- 生产环境必须为
1：SET GLOBAL innodb_flush_log_at_trx_commit = 1;（需重启生效或确认已持久化到 my.cnf） - 搭配检查磁盘写缓存：
hdparm -I /dev/sdX | grep "Write cache"，若显示 enabled，且innodb_flush_log_at_trx_commit=1，仍存在小概率丢日志风险 -
sync_binlog=1要同步开启，否则主从复制可能丢事务
SELECT 不加锁也阻塞：隔离性（Isolation）不是“不锁就安全”
在 REPEATABLE READ 下，普通 SELECT 是快照读，不加锁；但一旦涉及当前读（如 UPDATE、SELECT ... FOR UPDATE），InnoDB 就会加 next-key lock —— 即使你只查一个主键，也会锁住前后间隙，防止幻读。
-
SELECT * FROM orders WHERE user_id = 123;若user_id无索引，会全表扫描并给所有行加 S 锁（READ COMMITTED）或临键锁（REPEATABLE READ） - 高并发扣库存场景，仅靠
UPDATE stock = stock - 1 WHERE id = ?不够，必须配合SELECT ... FOR UPDATE先加 X 锁，否则超卖 - 避免隐式转换导致索引失效，比如
WHERE phone = 13800138000（phone 是 VARCHAR），会全表扫+全表锁
一致性（Consistency）根本不是数据库自动兜底的
外键、CHECK、主键冲突这些约束由 InnoDB 执行，但“账户余额不能为负”“订单状态流转必须合规”这类业务规则，ACID 一概不管——它只保证 SQL 执行过程不崩，不保证逻辑正确。
- DDL（如
ALTER TABLE）会触发隐式提交，后面跟的ROLLBACK无效，事务边界被切碎 - 大事务（如百万行
UPDATE）撑爆 undo log，rollback 可能卡死，应拆成WHERE id BETWEEN ? AND ?分批 - 转账类操作必须显式校验余额：
UPDATE account SET balance = balance - 100 WHERE id = 1 AND balance >= 100;，靠影响行数判断是否执行成功
ACID 不是开关，是引擎、配置、SQL 写法、业务逻辑四者咬合的结果。漏掉任意一环，事务就只剩个壳子。
