Syntax:

LOCK TABLES
tbl_name [[AS] alias] lock_type
[, tbl_name [[AS] alias] lock_type] ...

lock_type:
READ [LOCAL]
| [LOW_PRIORITY] WRITE

UNLOCK TABLES

MySQL enables client sessions to acquire table locks explicitly for the
purpose of cooperating with other sessions for access to tables, or to
prevent other sessions from modifying tables during periods when a
session requires exclusive access to them. A session can acquire or
release locks only for itself. One session cannot acquire locks for
another session or release locks held by another session.

Locks may be used to emulate transactions or to get more speed when

updating tables. This is explained in more detail later in this
section.

LOCK TABLES explicitly acquires table locks for the current client
session. Table locks can be acquired for base tables or views. You must
have the LOCK TABLES privilege, and the SELECT privilege for each
object to be locked.

For view locking, LOCK TABLES adds all base tables used in the view to
the set of tables to be locked and locks them automatically. If you
lock a table explicitly with LOCK TABLES, any tables used in triggers
are also locked implicitly, as described in
https://mariadb.com/kb/en/triggers-and-implicit-locks/.

UNLOCK TABLES explicitly releases any table locks held by the current
session. LOCK TABLES implicitly releases any table locks held by the
current session before acquiring new locks.

Another use for UNLOCK TABLES is to release the global read lock
acquired with the FLUSH TABLES WITH READ LOCK statement, which enables
you to lock all tables in all databases. See [HELP FLUSH]. (This is a
very convenient way to get backups if you have a file system such as
Veritas that can take snapshots in time.)

URL: https://mariadb.com/kb/en/transactions-lock/

Syntax:
{DEALLOCATE | DROP} PREPARE stmt_name

To deallocate a prepared statement produced with PREPARE, use a

DEALLOCATE PREPARE statement that refers to the prepared statement
name. Attempting to execute a prepared statement after deallocating it
results in an error.

URL: https://mariadb.com/kb/en/deallocate-drop-prepared-statement/

Syntax:
START SLAVE [thread_types]

START SLAVE [SQL_THREAD] UNTIL

MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos

START SLAVE [SQL_THREAD] UNTIL

 RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos

thread_types:
[thread_type [, thread_type] ... ]

thread_type: IO_THREAD | SQL_THREAD

START SLAVE with no thread_type options starts both of the slave

threads. The I/O thread reads events from the master server and stores
them in the relay log. The SQL thread reads events from the relay log
and executes them. START SLAVE requires the SUPER privilege.

If START SLAVE succeeds in starting the slave threads, it returns

without any error. However, even in that case, it might be that the
slave threads start and then later stop (for example, because they do
not manage to connect to the master or read its binary log, or some
other problem). START SLAVE does not warn you about this. You must
check the slave's error log for error messages generated by the slave
threads, or check that they are running satisfactorily with SHOW SLAVE
STATUS.

URL: https://mariadb.com/kb/en/start-slave/

Syntax:
START TRANSACTION [WITH CONSISTENT SNAPSHOT]
BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET autocommit = {0 | 1}

These statements provide control over use of transactions:

o START TRANSACTION or BEGIN start a new transaction.

o COMMIT commits the current transaction, making its changes permanent.

o ROLLBACK rolls back the current transaction, canceling its changes.

o SET autocommit disables or enables the default autocommit mode for

the current session.

By default, MySQL runs with autocommit mode enabled. This means that as
soon as you execute a statement that updates (modifies) a table, MySQL
stores the update on disk to make it permanent. The change cannot be
rolled back.

To disable autocommit mode implicitly for a single series of

statements, use the START TRANSACTION statement:

START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;

With START TRANSACTION, autocommit remains disabled until you end the
transaction with COMMIT or ROLLBACK. The autocommit mode then reverts
to its previous state.

You can also begin a transaction like this:

START TRANSACTION WITH CONSISTENT SNAPSHOT;

The WITH CONSISTENT SNAPSHOT option starts a consistent read for

storage engines that are capable of it. This applies only to InnoDB.
The effect is the same as issuing a START TRANSACTION followed by a
SELECT from any InnoDB table. See
http://dev.mysql.com/doc/refman/5.5/en/innodb-consistent-read.html. The
WITH CONSISTENT SNAPSHOT option does not change the current transaction
isolation level, so it provides a consistent snapshot only if the
current isolation level is one that permits consistent read (REPEATABLE
READ or SERIALIZABLE).

*Important*: Many APIs used for writing MySQL client applications (such
as JDBC) provide their own methods for starting transactions that can
(and sometimes should) be used instead of sending a START TRANSACTION
statement from the client. See
http://dev.mysql.com/doc/refman/5.5/en/connectors-apis.html, or the
documentation for your API, for more information.

To disable autocommit mode explicitly, use the following statement:

SET autocommit=0;

After disabling autocommit mode by setting the autocommit variable to

zero, changes to transaction-safe tables (such as those for InnoDB) are not made
permanent immediately. You must use COMMIT to
store your changes to disk or ROLLBACK to ignore the changes.

autocommit is a session variable and must be set for each session. To

disable autocommit mode for each new connection, see the description of
the autocommit system variable at
https://mariadb.com/kb/en/server-system-variables/.

BEGIN and BEGIN WORK are supported as aliases of START TRANSACTION for
initiating a transaction. START TRANSACTION is standard SQL syntax and
is the recommended way to start an ad-hoc transaction.

The BEGIN statement differs from the use of the BEGIN keyword that
starts a BEGIN ... END compound statement. The latter does not begin a
transaction. See [HELP BEGIN END].

*Note*: Within all stored programs (stored procedures and functions,

triggers, and events), the parser treats BEGIN [WORK] as the beginning
of a BEGIN ... END block. Begin a transaction in this context with
START TRANSACTION instead.

The optional WORK keyword is supported for COMMIT and ROLLBACK, as are
the CHAIN and RELEASE clauses. CHAIN and RELEASE can be used for
additional control over transaction completion. The value of the
completion_type system variable determines the default completion
behavior. See
https://mariadb.com/kb/en/server-system-variables/.

The AND CHAIN clause causes a new transaction to begin as soon as the
current one ends, and the new transaction has the same isolation level
as the just-terminated transaction. The RELEASE clause causes the
server to disconnect the current client session after terminating the
current transaction. Including the NO keyword suppresses CHAIN or
RELEASE completion, which can be useful if the completion_type system
variable is set to cause chaining or release completion by default.

URL: https://mariadb.com/kb/en/start-transaction/