Scribd
Upload
40 views2 pages

Lock Purge Reset Mysql

LOCK TABLES and UNLOCK TABLES allow client sessions to explicitly acquire and release table locks to control access to tables by other sessions. LOCK TABLES locks tables for the current session for read or write operations, while UNLOCK TABLES releases any locks held by the current session.

Uploaded by

Irwan Fath
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
40 views2 pages

Lock Purge Reset Mysql

LOCK TABLES and UNLOCK TABLES allow client sessions to explicitly acquire and release table locks to control access to tables by other sessions. LOCK TABLES locks tables for the current session for read or write operations, while UNLOCK TABLES releases any locks held by the current session.

Uploaded by

Irwan Fath
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

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
http://dev.mysql.com/doc/refman/5.5/en/lock-tables-and-triggers.html.

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: http://dev.mysql.com/doc/refman/5.5/en/lock-tables.html

Syntax:
PREPARE stmt_name FROM preparable_stmt

The PREPARE statement prepares a SQL statement and assigns it a name,


stmt_name, by which to refer to the statement later. The prepared
statement is executed with EXECUTE and released with DEALLOCATE
PREPARE. For examples, see
http://dev.mysql.com/doc/refman/5.5/en/sql-syntax-prepared-statements.h
tml.

Statement names are not case sensitive. preparable_stmt is either a


string literal or a user variable that contains the text of the SQL
statement. The text must represent a single statement, not multiple
statements. Within the statement, ? characters can be used as parameter
markers to indicate where data values are to be bound to the query
later when you execute it. The ? characters should not be enclosed
within quotation marks, even if you intend to bind them to string
values. Parameter markers can be used only where data values should
appear, not for SQL keywords, identifiers, and so forth.

If a prepared statement with the given name already exists, it is


deallocated implicitly before the new statement is prepared. This means
that if the new statement contains an error and cannot be prepared, an
error is returned and no statement with the given name exists.

The scope of a prepared statement is the session within which it is


created, which as several implications:

o A prepared statement created in one session is not available to other


sessions.

o When a session ends, whether normally or abnormally, its prepared


statements no longer exist. If auto-reconnect is enabled, the client
is not notified that the connection was lost. For this reason,
clients may wish to disable auto-reconnect. See
http://dev.mysql.com/doc/refman/5.5/en/auto-reconnect.html.

o A prepared statement created within a stored program continues to


exist after the program finishes executing and can be executed
outside the program later.

o A statement prepared in stored program context cannot refer to stored


procedure or function parameters or local variables because they go
out of scope when the program ends and would be unavailable were the
statement to be executed later outside the program. As a workaround,
refer instead to user-defined variables, which also have session
scope; see
http://dev.mysql.com/doc/refman/5.5/en/user-variables.html.

URL: http://dev.mysql.com/doc/refman/5.5/en/prepare.html

Syntax:
PURGE { BINARY | MASTER } LOGS
{ TO 'log_name' | BEFORE datetime_expr }

The binary log is a set of files that contain information about data
modifications made by the MySQL server. The log consists of a set of
binary log files, plus an index file (see
http://dev.mysql.com/doc/refman/5.5/en/binary-log.html).

The PURGE BINARY LOGS statement deletes all the binary log files listed
in the log index file prior to the specified log file name or date.
BINARY and MASTER are synonyms. Deleted log files also are removed from
the list recorded in the index file, so that the given log file becomes
the first in the list.

This statement has no effect if the server was not started with the
--log-bin option to enable binary logging.

URL: http://dev.mysql.com/doc/refman/5.5/en/purge-binary-logs.html

You might also like