MySQL事务的ACID特性及并发问题分析
一、事务的概念一个事务是由一条或多条对数据库操作的SQL语句所组成的一个不可分割的单元，只有当事务中所有操作都正常执行完了，整个事务才会被提交给数据库，如果有部分事务处理失败，那么事务就要回滚到最初的状态，因此，事务要么全部执行成功，要么全部失败。所以要记住事务几个基本概念，如下：事务是一组SQL语句的执行，要么全部成功，要么全部失败，不能出现部分成功，部分失败的结果，保证事务执行的原子操作。事务的所有SQL语句全部执行成功，才能提交（commit）事务，把结果写会磁盘上。事务执行过程中，有的SQL出现错
一、事务的概念
一个事务是由一条或多条对数据库操作的SQL语句所组成的一个不可分割的单元，只有当事务中所有操作都正常执行完了，整个事务才会被提交给数据库，如果有部分事务处理失败，那么事务就要回滚到最初的状态，因此，事务要么全部执行成功，要么全部失败。
所以要记住事务几个基本概念，如下：
事务是一组SQL语句的执行，要么全部成功，要么全部失败，不能出现部分成功，部分失败的结果，保证事务执行的原子操作。事务的所有SQL语句全部执行成功，才能提交（commit）事务，把结果写会磁盘上。事务执行过程中，有的SQL出现错误，那么事务必须要回滚（rollback）到最初的状态。
比如转账业务需要多条SQL语句共同完成，只有这些SQL都执行成功才算业务成功了。
事务处理有三个状态：
begin：开启一个事务要执行的全部sql语句都成功了，然后commit提交一个事务如果其中任何一条SQL语句由于停电、或者服务器出错，导致SQL执行异常，那事务就没有提交，事务会回滚（rollback），数据将恢复到事务开始前的状态
这是存储引擎来保证的（redo log和undo log保证的）
MyISAM存储引擎不支持事务，InnoDB存储引擎支持事务、支持行锁。
用show engines\G查看当前数据库支持哪些存储引擎。
select @@autocommit;查看对事务提交状态的设置
数据库引擎可以通过命令临时修改，或者通过配置文件永久修改。
如果说我们业务上涉及了事务，我们一般会在代码上控制这个变量，一般来说，我们的事务由多条SQL组成，要满足事务的原子性操作，所以我们设置为手动提交。业务都成功，则提交这个事务；如果业务中间出现失败，就回滚1个事务。
二、ACID特性
每一个事务必须满足下面的4个特性：
事务的原子性(Atomic)：事务是一个不可分割的整体，事务必须具有原子特性，及当事务修改时，要么全执行，要么全不执行，即不允许事务部分的完成。事务的一致性(Consistency)：一个事务执行之前和执行之后，数据库数据必须保持一致性状态。数据库的一致性状态必须由用户来负责，由并发控制机制实现。就拿网上购物来说，你只有让商品出库，又让商品进入顾客的购物车才能构成一个完整的事务。（一致性不仅仅体现在事务里面，包括存储层引入MySQL为了提高热点数据的访问效率一般都会加一个缓存层Redis或者Memery cache对热点数据做缓存，这就涉及了缓存层和数据库DB层的数据一致性问题）事务的隔离性(Isolution)：当两个或多个事务并发执行时，为了保证数据的安全性，将一个事务内部的操作与其他事务的操作隔离起来，不被其他正在执行的事务所看到，使得并发执行的各个事务之间不能互相影响。隔离级别：数据的安全性和事务的并发性。隔离越严格，安全性越高，并发性越低（就是并发控制，保证数据安全）事务的持久性(Durability)：事务完成以后(事务commit成功)，DBMS保证它对数据库中的数据的修改时永久性的，即使数据库因为故障出错，也应该能够恢复数据。
MySQL最重要的是日志，不是数据！
事务的ACD特性是由MySQL的redo log和undo log机制来保证的；I隔离性是由mysql事务的锁机制来实现保证的。
三、事务并发存在的问题
事务处理不经隔离，并发执行事务时通常会发生以下问题：
脏读(Dirty Read)：一个事务读取了另一个事务未提交的数据。例如当事务A和事务B并发执行时，当事务A更新后，事务B查询读取到A尚未提交的数据，此时事务A回滚，则事务B读到的数据就是无效的脏数据（事务B读取了事务A尚未提交的数据）不可重复读(NonRepeatable Read)：一个事务的操作导致另一个事务前后两次读到不同的数据。例如当事务A和事务B并发执行时，当事务B查询读取数据后，事务A更新操作更改事务B查询到的数据，此时事务B再去读该数据，发现前后两次读的数据不一样。（事务B读取了事务A已提交的数据）虚读(Phantom Read)幻读：一个事务的操作导致另一个事务前后两次查询的结果数据量不同。例如当事务A和事务B并发执行时，当事务B查询读取数据后，事务A新增或者删除了一条满足事务B查询条件的记录，此时事务B再去查询，发现查询到前一次不存在的记录，或者前一次查询的一些记录不见了。（事务B读取了事务A新增加的数据或者读不到事务A删除的数据）
脏读必须杜绝，因为事务没有commit。在有些场景下，不可重复读和幻读是可以允许的(事务已经commit)，不一定非要杜绝（通过设置不同的隔离级别解决），由应用场景需求决定。
四、事务相关命令
select @@autocommit;查看MySQL是否自动提交事务
0表示手动提交事务，1表示自动提交事务，设置事务提交方式为手动提交（只影响当前session）：
详解Navicat导入数据库的标准步骤，涵盖SQL脚本执行与CSV数据导入两种核心场景。针对导入过程中常见的字符集乱码、主键冲突及外键约束错误，提供具体的设置方法与修复建议，确保数据迁移准确无误。
深入理解SQL PRIMARY KEY与UNIQUE约束的区别。文章从行标识与重复限制的目标出发，详解主键的非空特性、外键引用角色以及多数据库对NULL值的处理差异。结合users表实战示例，指导开发者如何根据字段稳定性与业务语义合理选择约束类型，避免设计误区。
刚开始设计关系型数据库？了解PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK、DEFAULT等约束的作用、语法和排错方法。本文以PostgreSQL语法为主，结合用户订单场景，清晰展示如何防止脏数据并处理常见约束冲突。
深入解析SQL游标导致的死锁与资源未释放问题。通过PostgreSQL与MySQL语法对比，展示如何识别长事务持锁、分析锁等待链，并提供短事务提交、异常清理及批量处理的最佳实践，确保数据库连接与锁资源及时释放。
后端开发者在维护数据库时，常需对现有表添加主键、唯一或外键约束。若直接执行ADD CONSTRAINT，往往因存量数据不合规导致报错。本文详解操作前的数据清洗步骤、标准SQL语法及MySQL等特殊写法，帮助你在生产环境安全完成结构变更。
针对 SQL 初学者的分组统计实战指南。深入解析 GROUP BY 分组机制、WHERE 与 HAVING 的执行时机差异，以及 COUNT 函数对 NULL 值的处理逻辑。通过具体代码示例演示如何正确筛选聚合结果，并排查因 JOIN 连接导致的统计数据异常，提升报表准确性。
本文详细对比SQL Server和MySQL中游标的基本用法。从DECLARE声明到FETCH遍历，再到CLOSE关闭与DEALLOCATE/Handler清理，解析两者在语法结构、变量接收及异常处理上的核心差异。通过标准代码示例展示如何安全使用游标，避免资源泄漏，适用于需要进行数据库存储过程开发或跨平台迁移的开发者。
深入解析SQL中INNER JOIN与LEFT JOIN的核心区别。通过users和orders表实例，展示匹配行保留与NULL补位机制，重点讲解ON与WHERE子句中放置右表过滤条件的不同后果，提供防止LEFT JOIN退化的实战技巧及行数异常排查步骤。
深入理解 SQL CHECK 约束在 PostgreSQL、MySQL 等数据库中的实现差异。文章通过订单业务场景，讲解如何定义单列范围与多列逻辑约束，分析 NULL 值对布尔条件的影响，并提供修改已有表结构时的安全操作建议，帮助开发者构建更健壮的数据完整性防线。
后端开发中，如何正确使用 SQL 外键约束来维护订单与明细表的关系？本文通过 PostgreSQL 示例，深入讲解外键的创建语法、插入顺序要求，以及 ON DELETE CASCADE、RESTRICT、SET NULL 等策略的实际影响与风险控制，助你构建健壮的数据库结构。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
