Interprétation détaillée des index et des transactions MySQL

Cet article vous apporte une interprétation détaillée des index et des transactions MySQL. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

1. Que fait un index ?

Souvent, lorsque votre application exécute des requêtes SQL très lentement, vous devriez vous demander si elle peut créer un index. .

La plupart des index MySQL (PRIMARY KEY, UNIQUE, INDEX et FULLTEXT) sont stockés dans des B-trees. Seuls les index de type colonne spatiale utilisent R-tree et les tables MEMORY prennent également en charge les index de hachage.

L'index est une liste triée, qui stocke la valeur de l'index et l'adresse physique de la ligne contenant les données. Lorsque les données sont très volumineuses, l'index peut considérablement accélérer la requête. En utilisant l'index, vous n'avez pas besoin de parcourir la table entière pour localiser les données d'une certaine ligne. Au lieu de cela, vous recherchez d'abord l'adresse physique correspondant à la ligne de données via la table d'index, puis accédez aux données correspondantes.

2. Avantages et inconvénients de l'index

Avantages : Récupération rapide, temps d'E/S réduits, regroupement et indexation plus rapides basés sur ; Le tri d'index peut accélérer le regroupement et le tri ;

Inconvénients : L'index lui-même est également une table, il occupera donc de l'espace de stockage. De manière générale, l'espace occupé par la table d'index est de 1,5. fois celui de la table de données ; la maintenance et la création de la table d'index nécessitent des coûts de temps, qui augmentent à mesure que la quantité de données augmente, réduira l'efficacité des opérations de modification (suppression, ajout, modification) de la table de données, car les modifications apportées à la table de données ; La table de données est requise en même temps. Table d'index ;

3. Classification des index

Les types d'index courants sont : Index de clé primaire, index unique, index ordinaire, index de texte intégral, index combiné

1. Index de clé primaire  : c'est-à-dire l'index primaire. Un index est établi en fonction de la clé primaire pk_clolum (longueur. ). La duplication n'est pas autorisée et les valeurs nulles ne sont pas autorisées

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

2. Index unique : La valeur de la colonne utilisée pour créer l'index doit être unique, et les valeurs nulles sont autorisées

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

3. Index ordinaire  : utilisez la table Il n'y a aucune restriction sur l'index construit avec des colonnes ordinaires

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

4 . Index de texte intégral : Index construit avec des colonnes de gros objets texte (sera expliqué dans la partie suivante)

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

Index combiné : Un. index construit en combinant plusieurs colonnes. Les valeurs dans ces multiples colonnes n'autorisent pas les valeurs nulles

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

Suivez le principe du "préfixe le plus à gauche", placez les colonnes les plus couramment utilisées pour la récupération ou le tri sur le à l'extrême gauche, par ordre décroissant. L'index combiné équivaut à établir trois index : col1, col1col2, col1col2col3, et les index ne peuvent pas être utilisés sur col2 ou col3.

Lors de l'utilisation d'un index combiné, la clé d'index peut être trop grande car la longueur du nom de colonne est trop longue, ce qui entraîne une efficacité réduite. Si cela est autorisé, vous ne pouvez prendre que les premiers caractères de col1 et col2 comme valeurs. index

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

signifie utiliser les 4 premiers caractères de col1 et les 3 premiers caractères de col2 comme index

4. Principe de mise en œuvre de l'index

MySQL prend en charge de nombreux moteurs de stockage, et divers moteurs de stockage prennent en charge différemment les index. Par conséquent, la base de données MySQL prend en charge plusieurs types d'index, tels que l'index BTree, l'index B+Tree, l'index de hachage, l'index de texte intégral, etc.,

1. Index de hachage :

Seul le moteur de stockage en mémoire prend en charge l'index de hachage. L'index de hachage utilise la valeur de la colonne d'index pour calculer le hashCode de la valeur, puis stocke le hashCode correspondant. location.L'emplacement physique des données de ligne où se trouve la valeur est très rapide car il utilise un algorithme de hachage. Cependant, une valeur ne peut correspondre qu'à un seul hashCode, et il s'agit d'une méthode de distribution de hachage, donc l'index de hachage ne prend pas en charge. fonctions de recherche et de tri par plage.

2. Index de texte intégral :

Index FULLTEXT (texte intégral), qui ne peut être utilisé que pour MyISAM et InnoDB. Pour des données plus volumineuses, générer un index de texte intégral prend beaucoup de temps. -consommateur et consommateur d'espace. Pour les objets texte volumineux ou les données de type CHAR plus volumineuses, si vous utilisez un index normal, il est toujours possible de faire correspondre les premiers caractères du texte, mais si vous souhaitez faire correspondre quelques mots au milieu du texte, vous devez utiliser LIKE %word% Pour faire la correspondance, le traitement prendra beaucoup de temps et le temps de réponse sera considérablement augmenté. Dans ce cas, vous pouvez utiliser l'index FULLTEXT. Lors de la génération de l'index FULLTEXT, une liste de mots sera générée pour. le texte, et il sera indexé dans le temps en fonction de cette liste de mots. FULLTEXT peut être créé lors de la création de la table, ou ajouté si nécessaire en utilisant ALTER ou 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);

Pour des ensembles de données plus volumineux, ajoutez des données à une table sans index FULLTEXT, puis l'ajout d'un index FULLTEXT est plus rapide. que d'ajouter des données à une table qui possède déjà un index FULLTEXT.

L'index de texte intégral fourni avec MySQL ne peut être utilisé qu'avec le moteur de stockage MyISAM. S'il s'agit d'autres moteurs de données, l'index de texte intégral ne prendra pas effet.

Dans MySQL, le détachement d'index de texte intégral est disponible en anglais, mais n'est actuellement pas pris en charge en chinois.

Dans MySQL, si la chaîne récupérée est trop courte, les résultats attendus ne peuvent pas être récupérés. La longueur de la chaîne récupérée doit être d'au moins 4 octets. De plus, si les caractères récupérés incluent des mots vides, les mots vides le seront. Ignoré.

3. Index BTree et index B+Tree

Indice BTree

BTree est un multi-arbre de recherche équilibré Laissez le degré de l'arbre être d (d>1. ), et la hauteur est h, alors BTree doit satisfaire les conditions suivantes :

La hauteur de chaque nœud feuille est la même, égale à h ;

Chaque nœud non-feuille se compose de n-1 clés et n pointeurs, où d

les pointeurs des nœuds feuilles sont nuls

les clés des nœuds non-feuilles sont toutes des tuples [clé, données] ; key représente la clé comme index, et data sont les données de la ligne où se trouve la valeur clé ; la structure de

BTree est la suivante :

Dans la structure de BTree, vous pouvez utiliser la méthode de recherche binaire. La complexité de la recherche est h*log(n) De manière générale, la hauteur de l'arbre est très petite, généralement d'environ 3, BTree est donc une structure de recherche très efficace.

Indice B+Tree

B+Tree est une variante de BTree Soit d le degré de l'arbre et h la hauteur de l'arbre. Les BTree sont :

Les nœuds non-feuilles de B+Tree ne stockent pas de données, seules les valeurs clés

Les nœuds feuilles de B+Tree n'ont pas de pointeurs et toutes les valeurs clés le seront ; apparaître sur les nœuds feuilles, et L'adresse physique des données correspondant à la valeur clé stockée dans la clé

La structure de B+Tree est la suivante :

De manière générale, B +Tree est plus approprié que BTree pour implémenter la structure d'index de la mémoire externe, car les experts en conception du moteur de stockage utilisent intelligemment la structure de stockage de la mémoire externe (disque), qui c'est-à-dire qu'un secteur du disque est un multiple entier de page (page), et la page est l'unité de stockage A, la valeur par défaut est généralement 4K, de sorte que les nœuds de la structure d'index sont conçus pour avoir la taille d'une page, puis utilisez le principe de « pré-lecture » de la mémoire externe pour lire les données de l'ensemble du nœud à chaque fois qu'elles sont lues dans la mémoire, puis recherchez dans la mémoire. On sait que la vitesse de lecture de la mémoire est des centaines de fois. la vitesse de lecture des E/S de la mémoire externe, donc la clé pour améliorer la vitesse de recherche est d'utiliser le moins d'E/S disque possible, alors vous pouvez savoir, plus il y a de clés dans chaque nœud, plus la hauteur de l'arborescence est petite et moins d'E/S sont nécessaires. Par conséquent, d'une manière générale, B+Tree est plus rapide que BTree car il n'y a pas de nœuds non-feuilles dans B+Tree. En stockant des données, vous pouvez stocker plus de clés.

B+TREE avec index séquentiel

De nombreux moteurs de stockage ont été optimisés sur la base de B+Tree, ajoutant des pointeurs vers les nœuds feuilles adjacents, formant un pointeur d'accès séquentiel B+Tree, c'est fait pour améliorer l'efficacité de la recherche d'intervalle. Tant que la première valeur est trouvée, les valeurs suivantes peuvent être recherchées séquentiellement.

La structure de B+Tree est la suivante :

Le principe de mise en œuvre de la structure d'index de MySQL est analysé, puis nous jetez un œil aux détails Comment les moteurs de stockage implémentent-ils les structures d'index ? Les deux moteurs de stockage les plus courants dans MySQL sont MyISAM et InnoDB, qui implémentent respectivement des index non clusterisés et des index clusterisés.

Tout d'abord, nous devons introduire quelques concepts dans la classification des index, nous pouvons le diviser en « index primaire » et « index auxiliaire » selon que la clé de l'index est la clé primaire. . L'index établi à partir de la valeur de la clé primaire est appelé « Index primaire », les autres sont appelés « index auxiliaires ». Par conséquent, il ne peut y avoir qu’un seul index primaire et il peut y avoir plusieurs index auxiliaires.

MyISAM - index non clusterisé

Le moteur de stockage MyISAM utilise un index non clusterisé. L'index principal et l'index auxiliaire de l'index non clusterisé sont presque les mêmes, sauf que le principal. index ne peut pas être répété, les valeurs nulles ne sont pas autorisées et les clés de leurs nœuds feuilles stockent l'adresse physique pointant vers les données correspondant à la valeur de la clé.

La table de données et la table d'index de l'index non clusterisé sont stockées séparément.

Les données de l'index non clusterisé sont enregistrées selon l'ordre d'insertion des données. Par conséquent, les index non clusterisés sont plus adaptés aux requêtes de données uniques. L’ordre d’insertion n’est pas affecté par les valeurs clés.

Les index FULLTEXT ne sont disponibles que dans MyISAM.

Au début, je n'ai jamais compris pourquoi l'index auxiliaire est nécessaire puisque l'index primaire et l'index auxiliaire de l'index non clusterisé pointent vers le même contenu. Plus tard, j'ai réalisé que l'index n'est pas utilisé pour la requête. à ces endroits, n'est-ce pas juste après les instructions WHERE et ORDER BY ? Alors, que se passe-t-il si la condition de requête n'est pas la clé primaire ? À ce stade, un index auxiliaire est nécessaire.

InnoDB - Clustered Index

Les nœuds feuilles de l'index primaire de l'index clusterisé stockent les données correspondant à la valeur clé, et les nœuds feuilles de l'index auxiliaire stockent la valeur clé correspondante. La valeur de clé primaire des données. Par conséquent, plus la longueur de la valeur de la clé primaire est petite, mieux c'est, et plus le type est simple, mieux c'est.

Les données de l'index clusterisé et de l'index de clé primaire sont stockées ensemble.

Les données de l'index clusterisé sont enregistrées dans l'ordre de la clé primaire. Par conséquent, il convient à la recherche par intervalles par index de clé primaire, ce qui peut nécessiter moins d'E/S disque et accélérer la requête. Mais c'est aussi pour cette raison qu'il est préférable d'insérer l'ordre d'insertion de l'index clusterisé dans l'ordre monotone de la clé primaire, sinon cela provoquera fréquemment des fractionnements de pages, affectant sérieusement les performances.

Dans InnoDB, si vous avez uniquement besoin de rechercher des colonnes indexées, essayez de ne pas ajouter d'autres colonnes, ce qui améliorera l'efficacité des requêtes.

使用主索引的时候，更适合使用聚簇索引，因为聚簇索引只需要查找一次，而非聚簇索引在查到数据的地址后，还要进行一次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 数据库引擎的数据库或表才支持事务。

• Le traitement des transactions peut être utilisé pour maintenir l'intégrité de la base de données et garantir que les lots d'instructions SQL sont tous exécutés ou pas exécutés du tout.

• Les transactions permettent de gérer les instructions d'insertion, de mise à jour, de suppression.

De manière générale, les transactions doivent remplir 4 conditions (ACID) : Atomicité (Atomicité ), Cohérence (stabilité), Isolement (isolement), Durabilité (fiabilité)

• 1. Atomicité des transactions : un ensemble de transactions, soit réussies, soit retirées.

• 2. Stabilité : S'il y a des données illégales (contraintes de clé étrangère et autres), la transaction sera retirée.

• 3. Isolement : les transactions s'exécutent de manière indépendante. Si le résultat d'une transaction affecte d'autres transactions, les autres transactions seront retirées. L’isolation à 100 % des transactions nécessite de sacrifier la vitesse.

• 4. Fiabilité : après une panne du logiciel ou du matériel, le pilote de la table de données InnoDB utilisera le fichier journal pour le reconstruire et le modifier. La fiabilité et la vitesse élevée sont incompatibles. L'option innodb_flush_log_at_trx_commit détermine quand enregistrer les transactions dans le journal.

La concurrence des transactions n'effectue pas de lectures incorrectes, de lectures fantômes et de lectures non répétables causées par l'isolement des transactions

• Lecture sale : la transaction A lit les données modifiées par la transaction B non validée. Si la transaction B ne parvient pas à revenir en arrière à mi-chemin, alors la transaction A lit les données sales à ce moment-là. Par exemple, la transaction A modifie l'argent et la transaction B lit les résultats de mise à jour de la transaction A. Cependant, si la transaction A est annulée plus tard, la transaction B lit les données sales.

• Lecture non répétable : dans la même transaction, les résultats de la lecture des mêmes données sont incohérents. La transaction A lit avant que la transaction B ne mette à jour les données, puis la transaction B se met à jour et s'engage, et la transaction A lit à nouveau. À ce moment, les données lues deux fois sont différentes.

• Lecture fantôme : (Dans la même transaction, la même requête renvoie plusieurs fois des résultats différents. La transaction B interroge le nombre d'enregistrements dans la table, puis la transaction A insère un enregistrement dans le table, puis la transaction B interroge à nouveau et constate que le nombre d'enregistrements est différent. Notez que cette explication est incorrecte. Il existe de nombreuses explications de ce type sur Internet, y compris des experts qui, à mon avis, font plus autorité, mais elles ne sont pas correctes après des expériences. , il faut donc le noter). Vous pouvez faire une expérience comme celle-ci. La transaction A interroge le nombre d'enregistrements, la transaction B insère un enregistrement (la valeur de la clé primaire est 6), valide, puis la transaction A interroge le nombre d'enregistrements et constate que le nombre d'enregistrements n'a pas été atteint. a changé, mais à ce moment-là, un enregistrement avec une valeur de clé primaire de 6 est inséré. Les enregistrements se sont révélés contradictoires, et cela ressemblait à une hallucination.

Différences

1. Lecture sale et lecture non répétable : une lecture sale se produit lorsqu'une transaction lit les données mises à jour d'une transaction non validée. Une lecture non répétable signifie que les données lues plusieurs fois dans la même transaction sont différentes.

2. La différence entre la lecture non répétable et la lecture fantôme : les deux sont dans la même transaction. La première lit les données plusieurs fois de manière différente, et la seconde lit les données de différentes manières.

Niveau d'isolement

• Les changements de niveau d'isolement affectent le cycle de verrouillage

• mysql prend en charge les 4 niveaux d'isolement ci-dessus, et la valeur par défaut est reproductible lire

MySQL a trois niveaux de verrouillage : niveau , niveau table, niveau ligne.

Les moteurs de stockage MyISAM et MEMORY utilisent le verrouillage au niveau de la table ;

Le moteur de stockage BDB utilise le verrouillage au niveau de la page, mais prend également en charge le verrouillage au niveau de la table ; Le moteur de stockage InnoDB prend en charge à la fois le verrouillage au niveau des lignes et le verrouillage au niveau des tables, mais par défaut

utilise le verrouillage au niveau des lignes.

Les caractéristiques de ces trois verrous dans MySQL peuvent être résumées comme suit : 1. Verrous au niveau de la table : faible surcharge, verrouillage rapide ; pas de blocages importants, probabilité la plus élevée de conflits de verrouillage, concurrence élevée la plus faible ; . Les verrous au niveau de la table permettent à plusieurs threads de lire des données de la table de données en même temps, mais si un autre thread souhaite écrire des données, il doit d'abord obtenir un accès exclusif (un verrou de table exclusif est ajouté par défaut (verrouillage de lecture partagé (table)) ; Read Lock) ) Lors de la mise à jour des données, les autres threads doivent attendre que la mise à jour soit terminée avant que d'autres threads puissent accéder (lire) à la table (Exclusive Write Lock)

2. Verrouillage au niveau de la ligne : surcharge élevée et verrouillage lent . Un blocage se produira ; la granularité du verrouillage est la plus petite, la probabilité de conflit de verrouillage est la plus faible et la concurrence est la plus élevée

.

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，之前的正确操作会生效，数据库会进行更新。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!