一、 事务：数据库的“原子操作”

想象一个场景：你要给朋友转账500元。在你的银行账户扣款成功的那一刻，银行的服务器突然宕机了，朋友的账户没能加上这500元。

你的钱没了，朋友没收到钱，这500元“凭空蒸发”了。这显然是不允许的。

事务（Transaction），就是为了解决这种问题而生的。它把一组操作（比如“扣款”和“加款”）捆绑成一个逻辑单元，要么全部成功，要么全部失败，绝不会出现“扣了钱没到账”这种中间状态。

1. 事务的四大特性（ACID）

• 原子性（Atomicity）：这是事务最直观的特性。
• 理解：事务是一个不可分割的最小工作单位。就像化学中的原子一样，不可再分。
• 例子：转账操作中，“张三扣500”和“李四加500”必须同时成功。如果其中一个失败，整个事务就会回滚，数据库回到转账前的状态。资料中的例子很形象：要么张三500、李四1500；要么两人都保持原样1000。
• 一致性（Consistency）：这是事务的最终目标。
• 理解：事务执行前后，数据库的完整性约束没有被破坏。换句话说，事务必须让数据库从一个“正确的状态”变到另一个“正确的状态”。
• 例子：转账前后，两个人的总金额必须保持不变（2000元）。如果出现张三500、李四1000（总金额1500），就违反了“金额守恒”这一业务一致性规则，数据库会拒绝这个结果。
• 隔离性（Isolation）：这是并发操作的保障。
• 理解：当多个事务同时执行时，它们应该感觉不到彼此的存在。一个事务的中间状态对其他事务是不可见的。
• 例子：张三同时给李四转账500，王五也给李四转账500。这两个操作在数据库层面应该是并发执行的，但它们的结果不会互相干扰。最终的余额计算，应该基于正确的顺序和锁机制，而不是混乱地叠加。
• 持久性（Durability）：这是对结果的承诺。
• 理解：一旦事务被提交，它对数据库的改变就是永久性的。即使系统随后崩溃、断电、重启，数据也不会丢失。
• 例子：转账成功的提示出现了，就意味着银行已经将这个结果写入到了硬盘的日志文件中。哪怕下一秒服务器断电，重启后，你的账户余额依然是变动后的状态。

2. 事务的开启、提交与回滚

在MySQL中，操作事务的方式很灵活，分为自动提交模式和手动提交模式。

• 自动提交模式（默认）
  MySQL默认情况下，每一条单独的SQL语句都被视为一个独立的事务。执行成功则自动提交，执行失败则自动回滚。这对于简单的操作很方便，但对于需要多步操作的业务逻辑（如转账）就存在风险。
• 手动提交模式
  对于转账这种关键业务，我们需要手动控制事务的边界。
• sql
• -- 方式1：关闭自动提交（针对当前会话） SET autocommit = 0; -- 或 SET autocommit = false; -- 现在，后续的所有SQL都需要手动提交才能生效 UPDATE t_employee SET salary = 15000 WHERE ename = '孙红雷'; -- 如果发现错了，可以回滚 ROLLBACK; -- 确认无误后，提交 COMMIT; -- 方式2：使用 START TRANSACTION 或 BEGIN（推荐） START TRANSACTION; -- 手动开始一个事务，即使 autocommit 是开启状态 UPDATE t_employee SET salary = 0 WHERE ename = '李冰冰'; -- 检查无误后提交 COMMIT; -- 或者发现有误，回滚 ROLLBACK;
• 重要提示：DDL语句（CREATE、DROP、ALTER、TRUNCATE等）是不支持事务的。它们一旦执行，就会立即生效并自动提交，无法回滚。这一点在日常开发中要特别注意，避免误操作。

二、 深入隔离级别：破解并发难题

当多个事务同时运行时，如果没有有效的隔离机制，就会引发各种问题。三个经典的并发问题：

1. 脏读（Dirty Read）：一个事务读到了另一个未提交事务修改的数据。这是最严重的问题，因为你读到的可能是最终会被回滚的“脏数据”。
2. 不可重复读（Non-repeatable Read）：一个事务内，两次读取同一行数据，得到的结果不同。这是因为在两次读取之间，另一个事务提交了修改。
3. 幻读（Phantom Read）：一个事务内，两次执行同样的查询，返回的结果集行数不同。这是因为另一个事务在此期间插入或删除了新的行。

为了解决这些问题，SQL标准定义了四种隔离级别，它们像一道道锁，层层加码，但同时也影响着数据库的并发性能。

如何查看和修改隔离级别？

-- 查看当前会话的隔离级别SELECT @@transaction_isolation;-- 或SHOW VARIABLES LIKE 'transaction_isolation';-- 设置当前会话的隔离级别为可重复读SET SESSION transaction_isolation = 'REPEATABLE-READ';-- 设置全局的隔离级别SET GLOBAL transaction_isolation = 'READ-COMMITTED';

注意：隔离级别的设置通常需要在事务开始之前完成。

三、 用户管理：数据安全的“第一道防线”

谈完了数据本身，我们再来聊聊谁能动这些数据。MySQL的用户管理核心目标是两个：登录验证 和 权限管理。

1. 登录验证：三重身份认证

MySQL的登录验证不仅仅是“用户名+密码”，它还包括客户端主机地址。一个完整的MySQL用户是由 '用户名'@'主机' 组成的。

• 'root'@'localhost'：只允许从MySQL服务器本机连接。
• 'zhangsan'@'192.168.1.%'：允许来自 192.168.1 网段的任何主机连接。
• 'lisi'@'%'：允许从任何主机连接（不推荐，除非是公共应用）。
• 'wangwu'@'192.168.1.100'：只允许从IP为 192.168.1.100 的特定主机连接。

这种“主机+用户+密码”的组合方式，极大地增强了数据库的安全性，即使密码泄露，如果主机限制严格，攻击者也无法轻易登录。

2. 权限管理：最小化原则

权限管理遵循“最小化原则”，即只给用户完成其工作所必需的最小权限。MySQL的权限体系非常精细，从大到小分为：

1. 全局权限：对整个MySQL服务器的所有数据库和表有操作权限，如CREATE USER、SHUTDOWN、SUPER等。通常只有DBA拥有。
2. 数据库权限：对某个特定数据库内的所有对象有操作权限。
3. 数据表权限：对某个特定数据库中的某张表有操作权限，如SELECT、INSERT、UPDATE、DELETE。
4. 字段权限：对某张表中的特定字段有操作权限，例如只允许UPDATE员工的salary字段，而不能修改ename。
5. 存储过程/函数权限：对特定子程序的执行权限。

实际操作（使用Navicat等工具）：

1. 创建用户：在“用户”面板中，点击“新建用户”。需要填写“用户名”和“主机”，并设置密码。这里有一个关键点是选择Plugin，MySQL 8.0默认使用caching_sha2_password，但很多旧版客户端或工具（如部分Navicat版本）可能不支持，需要手动改为mysql_native_password以确保兼容性。
2. 授予权限：在“权限”选项卡中，你可以非常直观地勾选或取消勾选各个权限。权限列表会清晰地分为“全局权限”、“数据库权限”等。当你为一个用户勾选某张表（如t_employee）的SELECT权限时，该用户就只能查询这张表，无法进行修改。

总结

今天，我们从“银行转账”这个经典场景出发，深入探讨了MySQL中保障数据完整性的事务机制：

• 我们理解了ACID（原子性、一致性、隔离性、持久性）是如何作为基石，确保每一次数据操作都是安全、可靠、可追溯的。
• 我们剖析了并发问题（脏读、不可重复读、幻读）的成因，并了解了MySQL如何通过不同的隔离级别在“数据一致性”和“系统并发性”之间找到平衡点。特别是MySQL默认的可重复读级别，通过MVCC和间隙锁，已经能很好地应对大部分场景。

随后，我们转移视线，聚焦在数据安全的“守门人”——用户管理上：

• 我们明白了MySQL登录的“主机+用户+密码”三重验证机制，这不仅仅是用户名密码那么简单，更是对网络来源的严格限制。
• 我们理清了MySQL精细的权限层级（全局、数据库、表、字段），并强调了“最小权限”原则，这是构建安全数据库架构的关键一步。

掌握事务和用户管理，意味着你不再仅仅是一个会写SQL的开发者，而是一个能够理解数据内在逻辑、并能构筑安全防线的数据管理者。这不仅仅是技术能力的提升，更是构建稳定、可靠应用系统的核心保障。

希望这篇文章能帮你建立起关于数据库核心概念的清晰认知。如果有任何疑问或想深入探讨的技术点，欢迎在评论区留言交流！