mysql에서 산이란 무엇입니까?

이 글에서는 mysql의 acid에 대해 소개하겠습니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.

1. 트랜잭션의 기본 요소(ACID)

1. 원자성: 트랜잭션이 시작된 후 모든 작업이 완료되거나 완료되지 않으며 중간에 정체가 불가능합니다. 트랜잭션 실행 중 오류가 발생하면 트랜잭션이 시작되기 전 상태로 롤백되어 모든 작업이 발생하지 않은 것처럼 처리됩니다. 즉, 물질의 기본 단위인 화학에서 배운 원자와 마찬가지로 사물은 분할할 수 없는 전체입니다.

　 2. 일관성: 트랜잭션 시작 및 종료 전후에 데이터베이스의 무결성 제약 조건이 파괴되지 않습니다. 예를 들어, A가 B에게 돈을 이체하면 A는 돈을 공제할 수 없지만 B는 돈을 받지 못합니다. 사실 일관성은 원자성의 표현이기도 합니다

　 3. 격리: 동시에 하나의 트랜잭션만 동일한 데이터를 요청할 수 있으며 서로 다른 트랜잭션 간에 간섭이 없습니다. 예를 들어, A는 은행 카드에서 돈을 인출하고 있습니다. B는 A의 인출 절차가 완료되기 전에는 이 카드로 돈을 이체할 수 없습니다. 직렬화

　 4. 내구성: 트랜잭션이 완료된 후 트랜잭션으로 인해 데이터베이스에 대한 모든 업데이트가 데이터베이스에 저장되며 롤백할 수 없습니다.

2. 트랜잭션 동시성 문제

1. 더티 읽기: 트랜잭션 A가 트랜잭션 B가 업데이트한 데이터를 읽은 후 B가 작업을 롤백합니다. 그런 다음 A가 읽은 데이터는 더티 데이터이며 최종 데이터와 다릅니다. 테이블의 실제 데이터는 일관성이 없습니다

　2. 반복 불가능한 읽기: 트랜잭션 A는 동일한 데이터를 여러 번 읽고 트랜잭션 B는 트랜잭션 A를 여러 번 읽는 동안 데이터를 업데이트하고 제출하므로 트랜잭션 A가 동일한 데이터를 읽습니다. 데이터가 여러 번 발생하면 결과가 일치하지 않습니다. 읽기 결과가 이전 결과와 일치하지 않습니다

　3. 환상 읽기: 시스템 관리자 A가 데이터베이스 내 모든 학생의 성적을 특정 점수에서 ABCDE 등급으로 변경했지만 시스템 관리자 B는 이때 특정 점수 기록을 삽입했습니다. 시스템 관리자 A가 변경을 완료했는데 아직 변경되지 않은 기록이 하나 남아 있는 것을 발견했는데, 이는 마치 환각처럼 보였습니다. 수정했다가 변경해서 예상과 다른 결과가 나왔습니다

요약: 비반복 읽기는 수정에 중점을 두고, 팬텀 읽기는 추가 또는 삭제에 중점을 두기 때문에 혼동하기 쉽습니다. 반복 불가능한 읽기 문제를 해결하려면 조건에 맞는 행만 잠그면 됩니다. 3. MySQL 트랜잭션 격리 수준 팬텀 읽기

read. -uncommitted

yesyesyesread-committednoyesyes반복 읽기(repeatable-read)no 아니요예직렬화 가능(직렬화 가능)nonono

MySQL의 기본 트랜잭션 격리 수준은 반복 읽기입니다

IV. 예제를 사용하여 각 격리 수준 설명

　1. 커밋되지 않은 읽기:

　　　 (1) 클라이언트 A를 열고 현재 트랜잭션 모드를 설정합니다. read uncommitted(read uncommitted), 쿼리 테이블 계정의 초기 값은

　입니다. (2) 클라이언트 A의 트랜잭션이 제출되기 전에 다른 클라이언트 B를 열고 테이블 계정을 업데이트합니다.

(3) 이때 클라이언트 B의 트랜잭션이 아직 제출되지 않았더라도 클라이언트 A는 B의 업데이트된 데이터를 쿼리할 수 있습니다.

　　 (4) 클라이언트 B의 트랜잭션이 어떤 이유로 중단되면 롤백하면 모든 작업이 취소됩니다. , 클라이언트 A가 쿼리한 데이터는 실제로 더티 데이터입니다.

　　　　 (5) 클라이언트 A에서 업데이트 문을 실행합니다. 업데이트 계정에서 잔액 = 잔액 - 50을 설정합니다. 여기서 id =1, lilei의 잔액은 350이 되지 않았지만 실제로는 400. 이상하지 않습니까? 그렇게 생각한다면 너무 순진한 생각입니다. 다른 세션에서는 롤백됩니다. 이 문제는 읽기 커밋 격리 수준

을 사용할 수 있습니다. 2. 커밋된 읽기

　 ​​(1) 클라이언트 A를 열고 현재 트랜잭션 모드를 커밋된 읽기(아직(Submit read))로 설정하고 초기 값을 쿼리합니다. 테이블 계정:

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 커밋 읽기 >> ââ'¬Å“ 클라이언트 B의 트랜잭션이 아직 제출되지 않았습니다. 클라이언트 A는 B의 업데이트된 데이터를 쿼리할 수 없으므로 더티 읽기 문제가 해결됩니다.

　　　　　 (4) 클라이언트 B의 트랜잭션이 제출됨

　　　 (5) 클라이언트 A가 이전 단계와 동일한 쿼리를 실행했지만 결과가 이전 단계와 일치하지 않아 반복 불가능 읽기 문제가 발생함 3. 반복 읽기 (1) 클라이언트 A를 열고 현재 트랜잭션 모드를 설정합니다. 반복 읽기를 위해 테이블 ​​계정을 쿼리합니다.　　　　　　　　　　　　　　　　　　　　　　　　bone Up over in 클라이언트 A ââ'¬â€ (1) 쿼리:

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　유력한 .50에서 id = 1이면 잔액은 400-50=350이 되지 않으며, (2)단계에서 350을 사용하여 lilei의 잔액 값을 계산하므로 300이 됩니다. 데이터는 파괴되지 않습니다. 이것은 약간 마술적입니다. 아마도 그것은 mysql의 기능일 것입니다. dml을 수행할 때 테이블의 실제 데이터에 따라 데이터를 반복해서 읽을 수 있습니다

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |     400 |
|    2 | hanmei |   16000 |
|    3 | lucy   |    2400 |
+------+--------+---------+
3 rows in set (0.00 sec)

mysql> update account set balance = balance - 50 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |     300 |
|    2 | hanmei |   16000 |
|    3 | lucy   |    2400 |
+------+--------+---------+
3 rows in set (0.00 sec)

　　　　(5) 클라이언트 A에서 트랜잭션을 제출합니다. 클라이언트 B에서 테이블 계정의 초기 값 (6)의 초기 값은 트랜잭션을 시작하고, 새로운 데이터를 추가하여 밸런스 필드 값이 600이고,이를 제출합니다. > 계산해보니 A고객님이 제출하신 후 잔액합계를 계산해보니 19300이 나왔습니다. B고객님의 600이 계산에 포함되었기 때문입니다

，站在客户的角度，客户是看不到客户端B的，它会觉得是天下掉馅饼了，多了600块，这就是幻读，站在开发者的角度，数据的 一致性并没有破坏。但是在应用程序中，我们得代码可能会把18700提交给用户了，如果你一定要避免这情况小概率状况的发生，那么就要采取下面要介绍的事务隔离级别“串行化”

mysql> select sum(balance) from account;
+--------------+ 
| sum(balance) | 
+--------------+ 
| 18700 |
+--------------+
1 row in set (0.00 sec)
mysql> commit;
 Query OK, 0 rows affected (0.00 sec)
mysql> select sum(balance) from account;
 +--------------+ 
 | sum(balance) | 
 +--------------+
 | 19300 |
 +--------------+ 
 1 row in set (0.00 sec)

　　4.串行化

　　　　（1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |   10000 |
|    2 | hanmei |   10000 |
|    3 | lucy   |   10000 |
|    4 | lily   |   10000 |
+------+--------+---------+
4 rows in set (0.00 sec)

　　　　（2）打开一个客户端B，并设置当前事务模式为serializable，插入一条记录报错，表被锁了插入失败，mysql中事务隔离级别为serializable时会锁表，因此不会出现幻读的情况，这种隔离级别并发性极低，开发中很少会用到。

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into account values(5,'tom',0);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

补充：

　　1、SQL规范所规定的标准，不同的数据库具体的实现可能会有些差异

　　2、mysql中默认事务隔离级别是可重复读时并不会锁住读取到的行

　　3、事务隔离级别为读提交时，写数据只会锁住相应的行

　　4、事务隔离级别为可重复读时，如果有索引（包括主键索引）的时候，以索引列为条件更新数据，会存在间隙锁间隙锁、行锁、下一键锁的问题，从而锁住一些行；如果没有索引，更新数据时会锁住整张表。

　　5、事务隔离级别为串行化时，读写数据都会锁住整张表

　　 6、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大，鱼和熊掌不可兼得啊。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

相关推荐：《mysql教程》

위 내용은 mysql에서 산이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!