Mysql lock table lock row statement sharing (MySQL Transaction Processing)

Copy codeThe Code is as follows:
Mysql_query ("set autocommit = 0 ");
$ List_one = $ db-> fetch_first ("select * from prizes where id =". $ id. "for update ");
$ Db-> query ("DELETE from prizes WHERE id =". $ list_one ['id']);
Mysql_query ("commit ");


Start transaction, COMMIT, and ROLLBACK syntax
Copy codeThe Code is as follows:
Start transaction | BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
Set autocommit = {0 | 1}

The start transaction or BEGIN statement can START a new TRANSACTION. COMMIT can COMMIT the current transaction, which is a permanent change of a change. ROLLBACK can roll back the current transaction and cancel its change. The set autocommit statement can be used to disable or enable the default autocommit mode for the current connection.
The optional WORK keywords are supported for COMMIT and RELEASE, and the CHAIN and RELEASE clauses. CHAIN and RELEASE can be used to perform additional control on Transaction completion. The value of the Completion_type system variable determines the nature of the default completion.
The and chain clause immediately starts a new transaction at the end of the current transaction, AND the new transaction has the same isolation level as the just-concluded transaction. After the RELEASE clause terminates the current transaction, it will disconnect the server from the current client. Keywords containing NO can suppress CHAIN or RELEASE. If the completion_type system variable is set to a certain value, the chain or release can be completed by default. In this case, the NO keyword is useful.
By default, MySQL runs in autocommit mode. This means that after you execute a statement for updating (modifying) The table, MySQL immediately stores the update to the disk.
If you are using a transaction-safe storage engine (such as InnoDB, BDB, or NDB cluster), you can disable the autocommit mode using the following statement:
Set autocommit = 0;
By setting the AUTOCOMMIT variable to zero, after the autocommit mode is disabled, you must use COMMIT to store the changes to the disk, or if you want to ignore the changes made since the beginning of the transaction, use ROLLBACK.
If you want to disable the autocommit mode for a single series of statements, you can use the start transaction statement:
Copy codeThe Code is as follows:
Start transaction;
SELECT @ A: = SUM (salary) FROM table1 WHERE type = 1;
UPDATE table2 SET summary = @ a where type = 1;
COMMIT;

With start transaction, autocommit is still disabled until you end the TRANSACTION with COMMIT or ROLLBACK. Then, the autocommit mode is restored to the original state.
BEGIN and begin work are supported as aliases of start transaction and used to initialize transactions. Start transaction is a standard SQL syntax and a recommended method for starting an ad-hoc TRANSACTION. The use of the BEGIN statement is different from that of the BEGIN keyword. The BEGIN keyword can start a BEGIN... END compound statement. The latter will not start a transaction.
You can also start a transaction as follows:
Start transaction with consistent snapshot;
The with consistent snapshot clause is used to start a CONSISTENT read for a storage engine WITH such features. Currently, this clause only applies to InnoDB. The effect of this clause is the same as that of publishing a start transaction statement, followed by a SELECT statement from any InnoDB table. See section 15.2.10.4, "consistent non-locked read ".
Starting a transaction will cause an implicit unlock tables to be executed.
To obtain the best results, transactions should only be executed using tables managed by a single transaction storage engine. Otherwise, the following problems may occur:
If the table you are using comes from multiple transaction-safe storage engines (such as InnoDB and BDB) and the transaction isolation level is not SERIALIZABLE, it is possible that when a transaction is committed, other ongoing transactions that use the same table will only be changed by the first transaction. That is, the use of hybrid engines cannot guarantee the atomicity of transactions and may cause inconsistency. (If hybrid engine transactions are uncommon, you can use set transaction isolation level to SET the isolation level to SERIALIZABLE as needed .)
If you use a non-transactional Security table in a transaction, any changes to these tables are immediately stored, regardless of the status of the autocommit mode.
If you publish a ROLLBACK statement after updating a transaction table, an ER_WARNING_NOT_COMPLETE_ROLLBACK warning will appear. Changes to the transaction security table are rolled back, but no changes to the non-Transaction Security table.
Each transaction is stored in a binary log in a group block, on the COMMIT. Rollback transactions are not included in logs. (Exception: Changes to non-transaction tables are not rolled back. If a rolled back transaction includes changes to non-transaction tables, the entire transaction uses a ROLLBACK statement at the end of the log to ensure that the changes to these tables are replicated .)
You can use set transaction isolation level to change the transaction isolation level.
Rollback can run slowly. You can also perform rollback (for example, when an error occurs) If you do not have specific requirements ). Therefore, when explicitly Rolling back to an implicit (rollback SQL command), SHOW PROCESSLIST will display Rolling back in the Stage column for connection.