zoukankan      html  css  js  c++  java

  • Mysql：语法：事务管理

    mysql的存储引擎有：事务型、非事务型 之分。

    mysql支持本地事务——即 各个连接会话 可以自由控制事务的处理，mysql默认是事务自动提交模式。

    不同的事务型引擎能够支持的事务功能 也不相同。

    基本上mysql的innodb引擎是功能全面，支持事务特性最多的引擎！

    set autocommit = {1 | 0} ：1为默认值——自动提交

    start transaction | begin 开始事务

    commit 提交事务

    rollback 回滚事务

    xa事务

    保存点

    SET TRANSACTION Syntax

    SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
      {
           READ UNCOMMITTED
         | READ COMMITTED
         | REPEATABLE READ
         | SERIALIZABLE
       }

    This statement sets the transaction isolation level globally, for the current session, or for the next transaction:

    • With the GLOBAL keyword, the statement sets the default transaction level globally for all subsequent sessions. Existing sessions are unaffected.

    • With the SESSION keyword, the statement sets the default transaction level for all subsequent transactions performed within the current session.

    • Without any SESSION or GLOBAL keyword, the statement sets the isolation level for the next (not started) transaction performed within the current session.

    A change to the global default isolation level requires the SUPER privilege. Any session is free to change its session isolation level (even in the middle of a transaction), or the isolation level for its next transaction.

    To set the global default isolation level at server startup, use the --transaction-isolation=level option to mysqld on the command line or in an option file. Values of level for this option use dashes rather than spaces, so the allowable values are READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, or SERIALIZABLE. For example, to set the default isolation level to REPEATABLE READ, use these lines in the [mysqld] section of an option file: 

    [mysqld]
    transaction-isolation = REPEATABLE-READ

    To determine the global and session transaction isolation levels at runtime, check the value of the tx_isolation system variable: 

    SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

    InnoDB supports each of the translation isolation levels described here using different locking strategies. The default level is REPEATABLE READ. For additional information about InnoDB record-level locks and how it uses them to execute various types of statements, see Section 13.6.8.4, “InnoDB Record, Gap, and Next-Key Locks”, and Section 13.6.8.6, “Locks Set by Different SQL Statements in InnoDB”.

    The following list describes how MySQL supports the different transaction levels:

    • READ UNCOMMITTED

      SELECT statements are performed in a nonlocking fashion, but a possible earlier version of a row might be used. Thus, using this isolation level, such reads are not consistent. This is also called a “dirty read.” Otherwise, this isolation level works like READ COMMITTED.

    • READ COMMITTED

      A somewhat Oracle-like isolation level with respect to consistent (nonlocking) reads: Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. See Section 13.6.8.2, “Consistent Nonlocking Reads”.

      For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), InnoDB locks only index records, not the gaps before them, and thus allows the free insertion of new records next to locked records. For UPDATE and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition (such as WHERE id = 100), or a range-type search condition (such as WHERE id > 100). For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For range-type searches, InnoDB locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range. This is necessary because “phantom rows” must be blocked for MySQL replication and recovery to work.

      Note

      In MySQL 5.1, if the READ COMMITTED isolation level is used or the innodb_locks_unsafe_for_binlog system variable is enabled, there is no InnoDB gap locking except for foreign-key constraint checking and duplicate-key checking. Also, record locks for nonmatching rows are released after MySQL has evaluated the WHERE condition.

      As of MySQL 5.1, if you use READ COMMITTED or enable innodb_locks_unsafe_for_binlog, you must use row-based binary logging.

    • REPEATABLE READ

      This is the default isolation level for InnoDB. For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other. See Section 13.6.8.2, “Consistent Nonlocking Reads”.

      For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range.

    • SERIALIZABLE

      This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... LOCK IN SHARE MODE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (This means that to force a plain SELECT to block if other transactions have modified the selected rows, you should disable autocommit.)

    不能被事务回滚的语句 ：一般DDL语句不能被事务回滚，你不应该在事务中包含此类语句

    隐式提交的语句：一句话，如果没有什么特特殊的地方，mysql总是隐式提交，除非你想自行控制事务

    The statements listed in this section (and any synonyms for them) implicitly end a transaction, as if you had done a COMMIT before executing the statement.

  • 相关阅读:
    chapter02“良/恶性乳腺癌肿瘤预测”的问题
    ASCII编码和Unicode编码的区别
    Spring AOP概述
    Spring 基于注解的配置
    Spring Bean作用域&FactoryBean
    Spring <bean> 之间的关系&整合多个配置文件
    Spring 方法注入
    Spring 简化装配Bean的配置方式
    Spring 注入参数详解
    vue-router 导航守卫
  • 原文地址：https://www.cnblogs.com/jinzhenshui/p/1629659.html
Copyright © 2011-2022 走看看