重庆购物狂论坛,360优化大师旧版,网站建设包含什么,长春小程序 开发事务处理与ACID特性
事务是数据库操作的基本单元#xff0c;它确保一组操作要么全部成功#xff0c;要么全部失败#xff0c;以此来维护数据库的一致性。这四个字母缩写ACID代表了事务的四大特性#xff1a;
原子性#xff08;Atomicity#xff09;**#xff1a;事务被… 事务处理与ACID特性
事务是数据库操作的基本单元它确保一组操作要么全部成功要么全部失败以此来维护数据库的一致性。这四个字母缩写ACID代表了事务的四大特性
原子性Atomicity**事务被视为不可分割的最小工作单元事务中的所有操作要么全部执行要么全部不执行。 一致性Consistency**事务执行前后数据库的状态保持合法即符合所有的预定义规则。 隔离性Isolation**并发执行的事务之间互不影响仿佛是在一个个独立的环境中执行。 持久性Durability**一旦事务被提交其效果就会永久保存在数据库中即使系统发生故障也不会丢失。
下面通过几个案例来展示如何在MySQL中使用事务处理及不同隔离级别的影响。
# 基础事务处理案例
假设我们要从一个账户转账到另一个账户需要两个操作从账户A减去金额向账户B增加相同的金额。这两个操作必须在一个事务中执行以确保数据的一致性。
sql
START TRANSACTION;
-- 从账户A扣款
UPDATE accounts SET balance balance - 100 WHERE account_id 1;
-- 向账户B加款
UPDATE accounts SET balance balance 100 WHERE account_id 2;
-- 提交事务
COMMIT; 如果在执行完第一个UPDATE后程序崩溃或遇到错误由于没有执行COMMIT事务中的所有操作都会被回滚从而保证了数据的一致性。
# 隔离级别的演示
MySQL支持四种事务隔离级别读未提交READ UNCOMMITTED、读已提交READ COMMITTED、可重复读REPEATABLE READInnoDB的默认级别和串行化SERIALIZABLE。不同的隔离级别会影响事务并发执行时的行为。
## 读未提交READ UNCOMMITTED
这种隔离级别下一个事务可以看到其他事务未提交的更改。
sql
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- 在一个事务中更改但未提交
START TRANSACTION;
UPDATE accounts SET balance balance - 100 WHERE account_id 1;
-- 在另一个事务中读取未提交的更改
START TRANSACTION;
SELECT balance FROM accounts WHERE account_id 1; ## 读已提交READ COMMITTED
在此隔离级别下事务只能看到已提交的更改。
sql
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 事务1提交更改
START TRANSACTION;
UPDATE accounts SET balance balance - 100 WHERE account_id 1;
COMMIT;
-- 事务2能看到已提交的更改
START TRANSACTION;
SELECT balance FROM accounts WHERE account_id 1; ## 可重复读REPEATABLE READ
这是InnoDB的默认隔离级别保证了在同一个事务中多次读取同一数据的结果是一致的即使其他事务已经修改并提交了该数据。
sql
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 事务1读取余额
START TRANSACTION;
SELECT balance FROM accounts WHERE account_id 1;
-- 事务2更改余额并提交
START TRANSACTION;
UPDATE accounts SET balance balance - 100 WHERE account_id 1;
COMMIT;
-- 事务1再次读取余额结果不变
SELECT balance FROM accounts WHERE account_id 1; ## 串行化SERIALIZABLE
最高隔离级别通过锁定读取的行来避免并发冲突相当于顺序执行事务。
sql
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 事务1读取余额
START TRANSACTION;
SELECT balance FROM accounts WHERE account_id 1;
-- 事务2尝试更新但会被阻塞直到事务1结束
START TRANSACTION;
UPDATE accounts SET balance balance - 100 WHERE account_id 1; 通过这些案例我们可以直观地看到不同隔离级别下事务行为的差异以及它们如何影响数据库的一致性和并发性能。在实际应用中应根据业务需求选择最合适的隔离级别。 Demo1银行转账
想象一下你正在使用手机银行应用给朋友转账。这个过程涉及两个关键操作从你的账户扣除一定金额同时在你朋友的账户上增加相同金额。为了确保整个过程的准确无误银行系统就需要使用事务来处理这笔转账操作。
#### 场景设定
- 你的账户Account A余额为500元。 - 你朋友的账户Account B余额为300元。 - 你想转账200元给朋友。
#### 无事务处理的情况想象中的灾难
如果银行系统没有使用事务转账可能这样进行 1. 银行系统从Account A中减去了200元此时你的账户余额变为300元。 2. 就在这个时候突然停电了或者系统出现了故障导致给Account B增加200元的操作没有完成。
结果你的钱减少了而你朋友并没有收到钱这就是一个典型的不一致状态显然不符合我们的预期。
#### 使用事务处理的情况安全可靠
现在让我们看看事务是如何确保操作的完整性的
1. **开始事务**银行系统启动一个事务准备执行转账操作。 sql START TRANSACTION; 2. **扣款操作**从你的账户减去200元。 sql UPDATE accounts SET balance balance - 200 WHERE account_id A; 3. **加款操作**增加你朋友账户的金额。 sql UPDATE accounts SET balance balance 200 WHERE account_id B; 4. **提交事务**如果上述两步都成功完成银行系统提交事务所有更改永久保存。 sql COMMIT; 5. **异常处理**但如果在执行上述操作的过程中发生了任何错误比如系统故障事务管理器会检测到这一情况并执行 sql ROLLBACK; 这样之前对Account A的扣款操作会被撤销账户余额回到500元就像转账从未发生过一样保证了数据的完整性。
通过这个例子我们可以清晰地理解事务如何确保数据的一致性即使在复杂的操作序列中也能保证“要么全做要么全不做”的原则这对于涉及金钱交易、库存管理等敏感操作的系统至关重要。 Demo2图书馆借阅系统中的事务处理
设想一个图书馆管理系统其中涉及图书的借出和归还操作。这个过程同样需要事务来确保数据的准确性和一致性。
# 场景描述
- 图书馆有《编程珠玑》这本书当前库存为1本。 - 用户小王想要借阅这本书。
# 借书过程的事务处理
1. 开始事务系统启动事务准备记录借书操作。 sql
START TRANSACTION; 2. 检查库存确认《编程珠玑》是否有可供借阅的副本。 sql SELECT stock FROM books WHERE title 编程珠玑 AND available true; 3. 更新库存如果书籍可用则减少书籍的可用库存并记录小王借阅的信息。 sql UPDATE books SET available false WHERE title 编程珠玑;INSERT INTO borrow_records (book_title, borrower, borrow_date) VALUES (编程珠玑, 小王, NOW()); 4. 提交事务如果上述操作都成功事务提交借书操作完成。 sql COMMIT; 5. 异常处理如果在借书过程中出现任何问题比如网络中断、数据库错误等事务会自动回滚确保数据的一致性。 sql
ROLLBACK; # 归还过程的事务处理
当小王归还《编程珠玑》时也需要通过事务确保操作的原子性和一致性
1. 开始事务同借书操作一样先启动事务。
2. 更新记录标记书籍为可借状态并记录归还时间。 sql
UPDATE books SET available true WHERE title 编程珠玑;
UPDATE borrow_records SET return_date NOW() WHERE book_title 编程珠玑 AND borrower 小王 AND return_date IS NULL; 3. 提交事务操作成功后提交事务完成归还流程。
4. 异常处理遇到错误时回滚事务确保书籍状态和借阅记录的准确性。
通过这些例子我们可以看到无论是银行转账还是图书馆借阅系统事务处理都是确保数据一致性和完整性的关键机制。在涉及多个数据库操作的情境下事务能够保证数据的一致性和业务逻辑的正确执行即使在复杂的系统交互中也能保持数据的准确无误。 更多实例在线购物车结算过程中的事务处理
设想一个电商平台用户将商品加入购物车后决定一次性结算多个商品。这个过程中涉及到从库存中减少已购买商品的数量并更新订单信息同样需要事务来确保操作的原子性和一致性。
# 场景描述
- 用户张三的购物车中有三件商品商品A库存10、商品B库存5、商品C库存2。 - 张三决定购买商品A 2件商品B 3件商品C 1件。
# 结算过程的事务处理
1. 开始事务系统启动事务准备处理订单创建及库存更新。 sql
START TRANSACTION; 2. 检查库存验证购物车中每种商品的购买数量是否小于等于现有库存。 sql
SELECT stock FROM products WHERE product_id IN (A, B, C) AND stock (SELECT quantity FROM cart WHERE user_id 张三 AND product_id products.product_id); 3. 更新库存如果所有商品的库存都满足购买需求减少相应商品的库存数量。 sql
UPDATE products SET stock stock - (SELECT quantity FROM cart WHERE user_id 张三 AND product_id A) WHERE product_id A;
UPDATE products SET stock stock - (SELECT quantity FROM cart WHERE user_id 张三 AND product_id B) WHERE product_id B;
UPDATE products SET stock stock - (SELECT quantity FROM cart WHERE user_id 张三 AND product_id C) WHERE product_id C; 4. 创建订单记录订单信息包括用户信息、商品详情、购买数量等。 sql
INSERT INTO orders (user_id, product_id, quantity, order_date) VALUES (张三, A, (SELECT quantity FROM cart WHERE user_id 张三 AND product_id A), NOW()), (张三, B, (SELECT quantity FROM cart WHERE user_id 张三 AND product_id B), NOW()), (张三, C, (SELECT quantity FROM cart WHERE user_id 张三 AND product_id C), NOW()); 5. 清空购物车完成购买后清空用户购物车中已结算的商品。 sql
DELETE FROM cart WHERE user_id 张三 AND product_id IN (A, B, C); 6. 提交事务所有操作成功后提交事务完成结算流程。 sql COMMIT; 7. 异常处理如果在结算过程中有任何问题比如某个商品库存不足系统会捕获错误并回滚事务保证数据库状态不变避免了部分商品被错误减少库存而订单未创建的情况。
通过这个例子我们可以看到事务在电子商务平台中的重要作用它确保了库存的精确管理、订单的准确生成以及购物车状态的一致性即便在面对复杂且并发的用户操作时也能维持系统的稳定和数据的准确。
