mysql 인덱스 및 트랜잭션에 대한 자세한 해석

이 기사는 mysql 인덱스 및 트랜잭션에 대한 자세한 해석을 제공합니다. 이는 특정 참조 가치가 있으므로 도움이 될 수 있습니다.

1. 인덱스의 기능은 무엇인가요?

애플리케이션이 SQL 쿼리를 매우 느리게 수행할 때 인덱스를 작성할 수 있는지 생각해 봐야 합니다.

대부분의 MySQL 인덱스(PRIMARY KEY, UNIQUE, INDEX 및 FULLTEXT)는 B-트리에 저장됩니다. 공간 컬럼형 인덱스만 R-tree를 사용하며, MEMORY 테이블도 해시 인덱스를 지원합니다.

인덱스는 인덱스 값과 데이터가 포함된 행의 물리적 주소를 저장하는 정렬된 목록입니다. 데이터가 매우 클 경우 인덱스를 사용하면 쿼리 속도가 크게 향상될 수 있기 때문입니다. , 특정 행의 데이터를 찾기 위해 전체 테이블을 스캔할 필요 없이 먼저 인덱스 테이블을 통해 데이터 행에 해당하는 물리적 주소를 찾은 다음 해당 데이터에 액세스합니다.

2. 인덱스의 장점과 단점

장점: 빠른 검색이 가능하고 I/O 수를 줄이며 검색 속도를 높일 수 있습니다. 인덱스에 따라 그룹화 및 정렬 속도를 높일 수 있습니다.

단점: 인덱스 자체도 테이블이므로 저장 공간을 차지합니다. 일반적으로 인덱스 테이블이 차지하는 공간은 데이터 테이블의 1.5배입니다. 데이터 양이 증가하면 비용도 증가하므로 데이터 테이블 수정 작업(삭제, 추가, 수정)의 효율성이 떨어집니다. 데이터 테이블을 수정할 때 인덱스 테이블도 수정해야 하기 때문입니다.

3. 인덱스 분류

일반적인 인덱스 유형은 다음과 같습니다:

기본 키 인덱스, 고유 인덱스, 일반 인덱스, 전체 텍스트 인덱스, 결합 인덱스

1,

기본 키 인덱스: 즉, 기본 index, 기본 키 pk_clolum(길이) 기반 인덱스, 중복 금지, null 값 허용 안 됨

ALTER TABLE 'table_name' ADD PRIMARY KEY('id')；

2,

Unique Index: 인덱스를 구축하는 데 사용되는 열의 값은 고유해야 합니다. 및 null 값도 허용됩니다

ALTER TABLE 'table_name' ADD UNIQUE('email')；

3,

Ordinary index: 아무런 제한 없이 테이블의 일반 열로 작성된 인덱스

ALTER TABLE 'table_name' ADD INDEX index_name('description')；

4,

Full-text index : 큰 텍스트의 열을 사용하여 작성된 인덱스 객체(다음 부분에서 설명)

ALTER TABLE 'table_name' ADD FULLTEXT('content')；

5.

결합 인덱스: 여러 열의 조합을 사용하여 작성된 인덱스입니다. 이러한 여러 열의 값은 null 값을 허용하지 않습니다.

ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3')；

"가장 왼쪽 접두사" 원칙을 따르며 검색 또는 정렬에 가장 일반적으로 사용되는 열을 가장 왼쪽에 내림차순으로 배치합니다. 결합된 인덱스는 col1, col1col2, col1col2col3 및 col2 또는 col3의 세 가지 인덱스를 설정하는 것과 같습니다.

결합 인덱스를 사용할 경우 컬럼 이름 길이가 너무 길어 인덱스 키가 너무 커져 효율성이 저하될 수 있습니다. 허용하는 경우 col1과 col2의 처음 몇 글자만 인덱스로 사용할 수 있습니다.

ALTER TABLE 'table_name' ADD INDEX index_name(col1(4),col2（3))；

col1의 처음 4글자와 col2의 처음 3글자를 인덱스로 사용한다는 뜻

4. 인덱스의 구현 원리

MySQL은 많은 스토리지 엔진을 지원하며, 스토리지 엔진마다 인덱스에 대한 지원이 다르기 때문에 MySQL 데이터베이스는 BTree 인덱스, B+Tree 인덱스, 해시 인덱스, 전체 텍스트 인덱스 등 다양한 인덱스 유형

1. 해시 인덱스:

메모리(메모리) 스토리지 엔진만 해시 인덱스, 해시 인덱스를 지원합니다. index 컬럼을 이용하여 해당 값의 hashCode를 계산한 후 해당 hashCode 위치에 값이 있는 행 데이터의 물리적인 위치를 저장한다. 해시 알고리즘을 사용하기 때문에 접근 속도는 매우 빠르지만, 값은 하나의 hashCode에만 대응할 수 있으며, 해싱의 분포 방식이므로 해시 인덱스는 범위 검색 및 정렬 기능을 지원하지 않습니다.

2. 전체 텍스트 인덱스:

FULLTEXT(전체 텍스트) 인덱스는 MyISAM 및 InnoDB에만 사용할 수 있습니다. 더 큰 데이터의 경우 전체 텍스트 인덱스를 생성하는 데 시간과 공간이 많이 소요됩니다. 큰 텍스트 개체 또는 더 큰 CHAR 유형 데이터의 경우 일반 인덱스를 사용하면 텍스트의 처음 몇 문자를 일치시키는 것이 여전히 가능하지만 텍스트 중간에 있는 몇 단어를 일치시키려면 다음을 사용해야 합니다. LIKE %word% 일치하려면 처리 시간이 오래 걸리고 응답 시간도 크게 늘어납니다. 이 경우 FULLTEXT 인덱스를 생성할 때 해당 단어의 목록이 생성됩니다. 이 단어 목록을 기반으로 시간에 따라 색인이 생성됩니다. FULLTEXT는 테이블이 생성될 때 생성되거나 필요할 때 ALTER 또는 CREATE INDEX를 사용하여 추가할 수 있습니다.

//创建表的时候添加FULLTEXT索引
CTREATE TABLE my_table(
id INT(10) PRIMARY KEY,
name VARCHAR(10) NOT NULL,
my_text text CHARACTER SET utf8 COLLATE utf8_general_ci NULL,
FULLTEXT(my_text));

//创建表以后，在需要的时候添加FULLTEXT索引
ALTER my_table ADD FULLTEXT ft_index(my_text);
CREATE INDEX ft_index ON my_table(my_text);

더 큰 데이터 세트의 경우 FULLTEXT 인덱스 없이 테이블에 데이터를 추가한 다음 FULLTEXT 인덱스를 추가하면 속도가 더 빨라집니다. 이미 FULLTEXT 인덱스가 있는 테이블에 데이터를 추가합니다.

MySQL과 함께 제공되는 전체 텍스트 인덱스는 MyISAM 스토리지 엔진에서만 사용할 수 있습니다. 다른 데이터 엔진인 경우 전체 텍스트 인덱스가 적용되지 않습니다.

MySQL에서는 전체 텍스트 인덱스 분리가 영어로 제공되지만, 현재 중국어에서는 지원되지 않습니다.

MySQL에서는 검색된 문자열이 너무 짧으면 예상된 결과를 검색할 수 없습니다. 검색된 문자열 길이는 최소 4바이트여야 합니다. 또한 검색된 문자에 불용어가 포함된 경우에는 불용어가 무시됩니다.

3. BTree 인덱스 및 B+Tree 인덱스

BTree 인덱스

BTree는 균형 검색 다중 트리이고, 높이가 h라고 가정하면 BTree는 다음을 충족해야 합니다. 다음 조건:

각 리프 노드의 높이는 h와 같습니다.

각 리프가 아닌 노드는 n-1개의 키와 n개의 포인터로 구성됩니다. 여기서 d

리프 노드 포인터는 모두 null입니다.

리프가 아닌 노드의 키는 모두 [key, data] 튜플입니다. 여기서 key는 키를 인덱스로 나타내고 데이터는

BTree의 구조는 다음과 같습니다.

BTree의 구조에서 검색 복잡도는 h*log( n) 일반적으로 트리의 높이는 매우 작으며 일반적으로 약 3이므로 BTree는 매우 효율적인 검색 구조입니다.

B+Tree index

B+Tree는 BTree의 변형입니다. d는 트리의 차수이고 h는 트리의 높이입니다. B+Tree와 BTree의 주요 차이점은 다음과 같습니다. B+트리 포인트의 리프 노드는 데이터를 저장하지 않으며 키 값만

B+트리 리프 노드에는 포인터가 없으며 모든 키 값은 리프 노드에 표시되며 키에 해당하는 데이터의 물리적 주소가 표시됩니다.

B+ Tree의 구조는 다음과 같습니다.

일반적으로 B+Tree는 BTree보다 외부 메모리의 인덱스 구조를 구현하는 데 더 적합합니다. 외부 메모리(디스크)의 저장 구조를 활용합니다. 즉, 디스크 섹터는 페이지의 정수 배수입니다. 페이지는 저장 장치의 단위이며 일반적으로 기본적으로 4K입니다. 페이지 크기로 만들고 외부 메모리의 "사전 읽기" 원리를 사용하여 읽을 때마다 전체 노드의 데이터를 메모리로 읽어온 다음 메모리에서 검색합니다. 메모리의 읽기 속도는 외부 메모리에서 읽는 I/O 속도의 수백 배에 달하는 것으로 알려져 있으므로 검색 속도를 향상시킬 수 있습니다. 핵심은 디스크 I/O를 최대한 적게 사용하는 것입니다. 각 노드에 키가 많을수록 트리 높이가 작아지고 I/O가 필요한 횟수가 줄어듭니다. 따라서 일반적으로 B+Tree는 리프가 아닌 노드에 데이터를 저장하지 않고 다음 작업을 수행할 수 있기 때문에 BTree보다 빠릅니다. 더 많은 키를 저장하세요.

순차 인덱스가 있는 B+TREE

많은 스토리지 엔진은 B+트리를 최적화하고 인접한 리프 노드에 포인터를 추가하여 순차 액세스 포인터가 있는 B+트리를 형성합니다. 이는 간격 검색의 효율성을 높이기 위한 것입니다. 첫 번째 값을 찾은 이후부터 순차적으로 다음 값을 검색할 수 있습니다.

B+Tree의 구조는 다음과 같습니다.

MySQL의 인덱스 구조 구현 원리를 분석해 보겠습니다. 그러면 가장 일반적인 두 가지 스토리지 엔진이 인덱스 구조를 어떻게 구현하는지 살펴보겠습니다. MySQL에서는 각각 비클러스터형 인덱스와 클러스터형 인덱스를 구현하는 MyISAM과 InnoDB가 있습니다.

먼저 인덱스의 분류에 있어서 인덱스의 키가 기본키인지 여부에 따라 "기본 인덱스"와 "보조 인덱스"로 나눌 수 있다는 몇 가지 개념을 소개해야 합니다. 기본 키 값을 사용하는 것을 "기본 인덱스"라고 하고, 나머지를 "보조 인덱스"라고 합니다. 따라서 기본 인덱스는 하나만 있을 수 있고, 보조 인덱스는 여러 개가 있을 수 있습니다.

MyISAM——비클러스터형 인덱스

MyISAM 스토리지 엔진은 비클러스터형 인덱스의 기본 인덱스와 보조 인덱스가 거의 동일하지만 기본 인덱스는 중복과 null을 허용하지 않습니다. 리프 노드의 키는 키 값에 해당하는 데이터를 가리키는 물리적 주소를 저장합니다.

비클러스터형 인덱스의 데이터 테이블과 인덱스 테이블은 별도로 저장됩니다.

비클러스터형 인덱스의 데이터는 데이터 삽입 순서에 따라 저장됩니다. 따라서 비클러스터형 인덱스는 단일 데이터 쿼리에 더 적합합니다. 삽입 순서는 키 값의 영향을 받지 않습니다.

FULLTEXT 인덱스는 MyISAM에서만 사용할 수 있습니다.

처음에는 논클러스터형 인덱스의 기본 인덱스와 보조 인덱스가 동일한 내용을 가리키기 때문에 보조 인덱스가 필요한 이유를 이해하지 못했습니다. 나중에 인덱스가 쿼리에 사용되지 않으며 어떤 위치에 있는지 알게 되었습니다. , WHERE 와 ORDER BY 문 바로 뒤가 아닌가요? 그럼 이때, 쿼리 조건이 기본 키가 아닌 경우에는 어떻게 될까요?

InnoDB - Clustered Index

클러스터드 인덱스의 기본 인덱스의 리프 노드에는 키 값에 해당하는 데이터 자체가 저장되고, 보조 인덱스의 리프 노드에는 키 값에 해당하는 데이터의 기본 키 값이 저장됩니다. . 따라서 기본 키의 값 길이가 작을수록 좋고, 유형이 단순할수록 좋습니다.

클러스터형 인덱스와 기본키 인덱스의 데이터가 함께 저장됩니다.

클러스터드 인덱스의 데이터는 기본키 순서대로 저장됩니다. 따라서 디스크 I/O가 덜 필요하고 쿼리 속도를 높일 수 있는 기본 키 인덱스를 통한 간격 검색에 적합합니다. 그러나 이러한 이유로 클러스터형 인덱스의 삽입 순서는 기본 키의 단조로운 순서로 삽입하는 것이 가장 좋습니다. 그렇지 않으면 페이지 분할이 자주 발생하여 성능에 심각한 영향을 미칠 수 있습니다.

InnoDB에서 인덱스 열만 찾으려면 다른 열을 추가하지 마세요. 이렇게 하면 쿼리 효율성이 향상됩니다.

使用主索引的时候，更适合使用聚簇索引，因为聚簇索引只需要查找一次，而非聚簇索引在查到数据的地址后，还要进行一次I/O查找数据。

因为聚簇辅助索引存储的是主键的键值，因此可以在数据行移动或者页分裂的时候降低委会成本，因为这时不用维护辅助索引。但是辅助索引会占用更多的空间。

聚簇索引在插入新数据的时候比非聚簇索引慢很多，因为插入新数据时需要减压主键是否重复，这需要遍历主索引的所有叶节点，而非聚簇索引的叶节点保存的是数据地址，占用空间少，因此分布集中，查询的时候I/O更少，但聚簇索引的主索引中存储的是数据本身，数据占用空间大，分布范围更大，可能占用好多的扇区，因此需要更多次I/O才能遍历完毕。

下图可以形象的说明聚簇索引和非聚簇索引的区别

五、索引的使用策略

什么时候要使用索引？

主键自动建立唯一索引；

经常作为查询条件在WHERE或者ORDER BY 语句中出现的列要建立索引；

作为排序的列要建立索引；

查询中与其他表关联的字段，外键关系建立索引

高并发条件下倾向组合索引；

什么时候不要使用索引？

经常增删改的列不要建立索引；

有大量重复的列不建立索引；

表记录太少不要建立索引；

在组合索引中不能有列的值为NULL，如果有，那么这一列对组合索引就是无效的；

在一个SELECT语句中，索引只能使用一次，如果在WHERE中使用了，那么在ORDER BY中就不要用了；

LIKE操作中，'%aaa%'不会使用索引，也就是索引会失效，但是‘aaa%’可以使用索引；

在索引的列上使用表达式或者函数会使索引失效，例如：select from users where YEAR(adddate) from users where adddate

在查询条件中使用正则表达式时，只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。

在查询条件中使用会导致索引失效。

在查询条件中使用IS NULL会导致索引失效。

在查询条件中使用OR连接多个条件会导致索引失效，这时应该改为两次查询，然后用UNION ALL连接起来。

尽量不要包括多列排序，如果一定要，最好为这队列构建组合索引；

只有当数据库里已经有了足够多的测试数据时，它的性能测试结果才有实际参考价值。如果在测试数据库里只有几百条数据记录，它们往往在执行完第一条查询命令之后就被全部加载到内存里，这将使后续的查询命令都执行得非常快--不管有没有使用索引。只有当数据库里的记录超过了1000条、数据总量也超过了MySQL服务器上的内存总量时，数据库的性能测试结果才有意义。

六、索引的优化

1、最左前缀

索引的最左前缀和和B+Tree中的“最左前缀原理”有关，举例来说就是如果设置了组合索引那么以下3中情况可以使用索引：col1，，，其它的列，比如，，col2，col3等等都是不能使用索引的。

根据最左前缀原则，我们一般把排序分组频率最高的列放在最左边，以此类推。

2、带索引的模糊查询优化

在上面已经提到，使用LIKE进行模糊查询的时候，'%aaa%'不会使用索引，也就是索引会失效。如果是这种情况，只能使用全文索引来进行优化（上文有讲到）。

为检索的条件构建全文索引，然后使用

SELECT * FROM tablename MATCH(index_colum) ANGAINST(‘word’);

事务介绍

首先，什么是事务？事务就是一段sql 语句的批处理，但是这个批处理是一个atom（原子），不可分割，要么都执行，要么回滚（rollback）都不执行。

MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！

• 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。

• 트랜잭션 처리를 사용하여 데이터베이스의 무결성을 유지하고 SQL 문 일괄 처리가 모두 실행되거나 전혀 실행되지 않도록 할 수 있습니다.

• 트랜잭션은 삽입, 업데이트, 삭제 문을 관리하는 데 사용됩니다.

일반적으로 트랜잭션은 네 가지 조건(ACID)을 충족해야 합니다: 원자성(원자성), 일관성(안정성), 격리(격리), 내구성(신뢰성)

• 1. 트랜잭션의 원자성: 일련의 트랜잭션이 성공하거나 철회됩니다.

• 2. 안정성: 불법 데이터(외래 키 제약 조건 등)가 있는 경우 거래가 철회됩니다.

• 3. 격리: 트랜잭션이 독립적으로 실행됩니다. 한 거래의 결과가 다른 거래에 영향을 미치는 경우 다른 거래가 철회됩니다. 트랜잭션을 100% 격리하려면 속도가 희생되어야 합니다.

• 4. 신뢰성: 소프트웨어나 하드웨어가 충돌한 후 InnoDB 데이터 테이블 드라이버는 로그 파일을 사용하여 이를 재구성하고 수정합니다. 신뢰성과 고속은 호환되지 않습니다. innodb_flush_log_at_trx_commit 옵션은 트랜잭션을 로그에 저장할 시기를 결정합니다.

트랜잭션 동시성은 더티 읽기, 팬텀 읽기, 트랜잭션 격리로 인한 반복 불가능한 읽기를 수행하지 않습니다.

• 더티 읽기: 트랜잭션 A는 커밋되지 않은 트랜잭션 B에 의해 수정된 데이터를 읽습니다. 이때 B는 중간에 롤백을 실행하지 못하므로 이때 트랜잭션 A가 읽는 것은 더티 데이터이다. 예를 들어 트랜잭션 A가 돈을 수정하는 경우 트랜잭션 B는 트랜잭션 A의 업데이트 결과를 읽습니다. 그러나 나중에 트랜잭션 A가 롤백되면 트랜잭션 B가 읽는 것은 더티 데이터입니다.

• 비반복 읽기: 동일한 트랜잭션에서 동일한 데이터를 읽은 결과가 일치하지 않습니다. 트랜잭션 B가 데이터를 업데이트하기 전에 트랜잭션 A가 읽은 다음 트랜잭션 B가 업데이트하고 커밋하며, 이때 트랜잭션 A가 다시 읽는 데이터는 다릅니다.

• 환상 읽기: (동일한 트랜잭션에서 동일한 쿼리가 여러 번 다른 결과를 반환합니다. 트랜잭션 B가 테이블의 레코드 수를 쿼리한 다음 트랜잭션 A가 테이블에 레코드를 삽입한 다음 트랜잭션 B가 다시 쿼리하고 이 설명은 틀렸다는 점을 참고하세요. 인터넷에는 전문가들이 더 권위 있다고 생각하는 설명이 많이 있지만 실험을 통해 잘못된 것으로 밝혀졌습니다. 유명한). 이와 같은 실험을 할 수 있습니다. 트랜잭션 A는 레코드 수를 쿼리하고, 트랜잭션 B는 레코드(기본 키 값은 6)를 삽입하고 커밋한 다음 트랜잭션 A가 레코드 수를 쿼리하여 레코드 수가 없음을 찾습니다. 변경되었는데 이때 기본키 값이 6인 레코드가 삽입되었는데, 그 레코드들이 충돌하는 것으로 확인되어 마치 환각을 느꼈습니다.

차이

1. 더티 읽기와 반복 불가능한 읽기: 더티 읽기는 트랜잭션이 커밋되지 않은 트랜잭션의 업데이트된 데이터를 읽는 경우입니다. 반복 불가능 읽기는 동일한 트랜잭션에서 여러 번 읽은 데이터가 다르다는 것을 의미합니다.

2. 비반복 읽기와 팬텀 읽기의 차이점: 둘 다 동일한 트랜잭션에 있습니다. 전자는 데이터를 여러 번 읽는 것이 다르고 후자는 데이터를 읽는 방식이 다릅니다.

격리 수준

• mysql은 위의 항목을 지원합니다. 4 격리 수준, 기본값은 반복 읽기입니다

MySQL에는 페이지 수준, 테이블 수준, 행 수준의 세 가지 잠금 수준이 있습니다. 　MyISAM 및 MEMORY 스토리지 엔진은 테이블 수준 잠금(테이블 수준 잠금)을 사용합니다.

　BDB 스토리지 엔진은 페이지 수준 잠금(페이지 수준 잠금)을 사용하지만 테이블 수준 잠금도 지원합니다.

　InnoDB 스토리지 엔진 모두 행 수준 잠금(행 수준 잠금) 및 테이블 수준 잠금을 지원하지만 기본적으로 행 수준 잠금이 사용됩니다.

MySQL의 세 가지 잠금 특성은 대략 다음과 같이 요약할 수 있습니다. 1. 테이블 수준 잠금: 낮은 오버헤드, 빠른 잠금, 큰 잠금 세분성, 가장 높은 잠금 충돌 가능성 및 가장 낮은 동시성. 테이블 수준 잠금을 사용하면 여러 스레드가 동시에 데이터 테이블에서 데이터를 읽을 수 있지만 다른 스레드가 데이터를 쓰려면 먼저 배타적 액세스를 얻어야 합니다(기본적으로 배타적 테이블 잠금이 추가됨)(공유 읽기 잠금(테이블) Read Lock) ) 데이터를 업데이트할 때 다른 스레드가 테이블에 액세스(읽기)할 수 있으려면 업데이트가 완료될 때까지 기다려야 합니다. (Exclusive Write Lock(Table Write Lock))

2. 행 수준 잠금: 높은 오버헤드, 느린 잠금 ; 교착 상태가 발생할 수 있습니다. 잠금 세분성은 가장 작고, 잠금 충돌 가능성은 가장 낮으며, 동시성은 가장 높습니다

.

3、页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

原则上数据表有一个读锁时，其它进程无法对此表进行更新操作，但在一定条件下，MyISAM表也支持查询和插入操作的并发进行。

一般MyISAM引擎的表也支持查询和插入操作的并发进行（原则上数据表有一个读锁时，其它进程无法对此表进行更新操作）

MyISAM引擎有一个系统变量concurrent_insert，专门用以控制其并发插入的行为，其值分别可以为0、1或2：

a、concurrent_insert为0，不允许并发插入。 　　　　
b、concurrent_insert为1，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。这也是MySQL的默认设置。 　　　　
c、concurrent_insert为2，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录。

如果有读写请求同时进行的话，MYSQL将会优先执行写操作。这样MyISAM表在进行大量的更新操作时（特别是更新的字段中存在索引的情况下），会造成查询操作很难获得读锁，从而导致查询阻塞。

我们还可以调整MyISAM读写的优先级别：

　　a、通过指定启动参数low-priority-updates，使MyISAM引擎默认给予读请求以优先的权利。
　　b、通过执行命令SET LOW_PRIORITY_UPDATES=1，使该连接发出的更新请求优先级降低。
　　c、通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级。

MyISAM使用的是 flock 类的函数，直接就是对整个文件进行锁定（叫做文件锁定），MyISAM的数据表是按照单个文件存储的，可以针对单个表文件进行锁定；

InnoDB使用的是 fcntl 类的函数，可以对文件中局部数据进行锁定（叫做行锁定），InnoDB是一整个文件，把索引、数据、结构全部保存在 ibdata 文件里，所以必须用行锁定。

事物控制语句：

BEGIN或START TRANSACTION；显式地开启一个事务；     
COMMIT；也可以使用COMMIT WORK，不过二者是等价的。
COMMIT会提交事务，并使已对数据库进行的所有修改称为永久性的；      
ROLLBACK；有可以使用ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改；      
SAVEPOINT identifier；SAVEPOINT允许在事务中创建一个保存点，一个事务中可以有多个SAVEPOINT；     
RELEASE SAVEPOINT identifier；删除一个事务的保存点，当没有指定的保存点时，执行该语句会抛出一个异常；     
ROLLBACK TO identifier；把事务回滚到标记点；     
SET TRANSACTION；用来设置事务的隔离级别。
InnoDB存储引擎提供事务的隔离级别有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。

MYSQL 事务处理主要有两种方法：

1、用 BEGIN, ROLLBACK, COMMIT来实现

BEGIN 开始一个事务     
ROLLBACK 事务回滚    
COMMIT 事务确认

2、直接用 SET 来改变 My

SQL 的自动提交模式:

SET AUTOCOMMIT=0 禁止自动提交     
SET AUTOCOMMIT=1 开启自动提交

注意点

1、如果事务中sql正确运行，后面没有commit，结果是不会更新到数据库的，所以需要手动添加commit。

2、如果事务中部分sql语句出现错误，那么错误语句后面不会执行。而我们可能会认为正确操作会回滚撤销，但是实际上并没有撤销正确的操作，此时如果再无错情况下进行一次commit，之前的正确操作会生效，数据库会进行更新。

위 내용은 mysql 인덱스 및 트랜잭션에 대한 자세한 해석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!