MySQL Architecture

MySQL’s architecture is very different from that of other database servers and makes it useful for a
wide range of purposes. MySQL is not perfect, but it is flexible enough to work well in very demanding
environments, such as web applications. At the same time, MySQL can power embedded applications,
data warehouses, content indexing, and delivery software, highly available redundant systems, online
transaction processing (OLTP), and much more.
To get the most from MySQL, you need to understand its design so that you can work with it, not against
it. MySQL is flexible in many ways. For example, you can configure it to run well on a wide range of
hardware, and it supports a variety of data types. However, MySQL’s most unusual and important
feature is its storage-engine architecture, whose design separates query processing and other server
tasks from data storage and retrieval.
MySQL client/server mode
A MySQL installation has the following required architectural components: the MySQL server, client
programs, and MySQL non-client programs. A central program acts as a server, and the client programs
connect to the server to make data requests.

MySQL client/server communication is not limited to environments where all computers run the same
operating system.
• Client programs can connect to the server running on the same host or on a different host.
• Client/server communication can occur in environments where computers run different
operating systems.
NOTE: Any information in this course that does not apply to all operating systems is identified as
platform-specific. Information that works for Linux generally applies for all UNIX-like operating
systems.
Client Programs
These programs are executed from the prompt of a command interpreter:
shell> mysql [options]
Use these client programs to perform the following actions:
• mysql: Issue queries and view results.
• mysqladmin: Administer the server.
• mysqlcheck: Check the integrity of database tables.
• mysqldump: Create logical backups.
• mysqlimport: Import text data files.
• mysqlshow: Show database, table, and column information.
• mysqlslap: Emulate client load.
The mysql client program is commonly known as the command-line interface (CLI). For more
information about client programs, see the MySQL Reference
Manual: http://dev.mysql.com/doc/mysql/en/programs-client.html.
Administrative and Utility Programs
There are many more programs available. To avoid loss or corruption of data, some of the programs
require that you shut down the server and/or make a back up of your current tables prior to execution.
For more information about administrative and utility programs, see the MySQL Reference
Manual: http://dev.mysql.com/doc/mysql/en/programs-admin-utils.html.
Some of the administrative and utility programs are lusted below:
• innochecksum:Check an InnoDB tablespace file offline.
• mysqldumpslow:Summarize the slow query log files.
• mysqlbinlog:Display the binary log files.
MySQL Server
Note the difference between a server and a host: Server: A software program (mysqld) with a version
number and a list of features. Host: The physical machine on which the server program runs, which
includes the following:
• Its hardware configuration
• The operating system running on the machine
• Its network addresses
Multiple mysqld instances can run simultaneously on one host. The configuration of the MySQL server
evolves from one product version to the next. Always consult the product documentation for the most
up-to-date configuration information.
MySQL Server
• Is the database server program called mysqld
• Is not the same as a “host”
• Is a single process and is multithreaded
• Manages access to databases on disk and in memory
• Supports simultaneous client connections
• Supports multiple storage engines
• Supports both transactional and nontransactional tables
• Uses memory in the form of: Caching and Buffering
Server Process
The mysql (server program) process can be sliced into the following three layers:
• Connection layer: Handles connections. This layer exists on all server software
(Web/mail/LDAP server).
• SQL layer: Processes SQL queries that are sent by connected applications.
• Storage layer: Handles data storage. Data can be stored in different formats and structures on
different physical media.

Connection Layer
The connection layer accepts connections from applications over several communication protocols:
• TCP/IP
• UNIX sockets
• Shared memory
• Named pipes

TCP/IP works across the network. The other protocols listed above support only local connections when
the client and server are running on the same machine. This layer maintains one thread per connection.
This thread handles query execution. Before a connection can begin sending SQL queries, the
connection is authenticated by verification of username + password + client host.
MySQL uses DNS (Domain Naming System) to resolve the names of hosts that connect using TCP/IP
protocol, storing them in a host cache. For large networks that exhibit performance problems during
name resolution, disable DNS with the –skip-name-resolve option, or increase the value of the –host-
cache-size option.
Communication Protocols
Protocols are implemented in the client libraries and drivers. The speed of a connection protocol varies
with the local settings.

Protocol Types of Connections Supported Operating Systems

TCP/IP Local, remote All

UNIX socket file Local only UNIX only

Shared memory Local only Windows only

Named pipes Local only Windows only

• TCP/IP(Transmission Control Protocol/Internet Protocol): The suite of communication

protocols used to connect hosts on the Internet. In the Linux operating system, TCP/IP is built-
in and is used by the Internet, making it the standard for transmitting data over networks. This
is the best connection type for Windows.
• UNIX socket: A form of inter-process communication used to form one end of a bidirectional
communication link between processes on the same machine. A socket requires a physical file
on the local system. This is the best connection type for Linux.
• Shared memory: An efficient means of passing data between programs. One program creates
a memory portion that other processes (if permitted) can access. This Windows explicit
“passive” mode works only within a single (Windows) machine. Shared memory is disabled by
default. To enable shared-memory connections, you must start the server with the –shared-
memory option.
• Named pipes:The use of named pipes is biased toward client/server communication, where
they work much like sockets. Named pipes support read/write operations, along with an explicit
“passive” mode for server applications. This protocol works only within a single (Windows)
 machine. Named pipes are disabled by default. To enable named-pipe connections, you must
start the server with the –enable-named-pipe option.
SQL Layer

After a connection is established, the following processes are handled by the MySQL server:
• Authorization and parser:The parser validates the correct syntax, and then authorization
verifies that the connected user is allowed to run a particular query.
• Optimizer:Creates the execution plan for each query, which is a step-by-step instruction set on
how to execute the query in the most optimal way. Determining which indexes are to be used,
and in which order to process the tables, is the most important part of this step.
• Query execution:Fulfills the execution plan for each query
• Query cache:Optionally configurable query cache that can be used to memorize (and
immediately return) executed queries and results
• Query logging:Can be enabled to track executed queries
Storage Layer

With MySQL, you can use different types of storage called “storage engines.” Data can be stored on
disk, memory, and network. Each table in a database can use any of the available storage engines. Disk
storage is cheap and persistent, whereas memory is much faster.
InnoDB is the default storage engine. It provides transactions, full-text indexing, and foreign key
constraints, and is thus useful for a wide mix of queries. It is multipurpose and supports read-intensive,
read/write, and transactional workloads.
Other storage engines include:
• MyISAM: Useful for mostly read and little update of data
• **MEMORY:**Stores all data in memory
• **NDB:**Used by MySQL Cluster to provide redundant scalable topology for highly available
data
Note: Storage engines extend beyond just the storage layer, and consist of more than just storage. They
also include other structures and implementation mechanisms.
Storage Engine: Overview
Storage engines are server components that act as handlers for different table types. Storage engines are
used to:
• Store data
• Retrieve data
• Find data through an index
A client retrieves data from tables or changes data in tables by sending requests to the server in the form
of SQL statements. The server executes each statement by using the two-tier processing model.
Clients normally do not need to be concerned about which engines are involved in processing SQL
statements. Clients can access and manipulate tables by using statements that are the same no matter
which engine manages them. Exceptions to this engine-independence of SQL statements include the
following:
• CREATE TABLE has an ENGINE option that specifies which storage engine to use on a per-
table basis.
• ALTER TABLE has an ENGINE option that enables the conversion of a table to use a different
storage engine.
• Some index types are available only for particular storage engines. For example, only the
InnoDB and MyISAM engines support full-text indexes.
• COMMITand ROLLBACK operations affect only tables that are managed by transactional
storage engines such as InnoDB and NDB.
Features Dependent on Storage Engine
The following properties are dependent on the storage engine:
• Storage medium: A table storage engine can store data on disk, in memory, or over a network.
• Transactional capabilities: Some storage engines support full ACID transactional capability,
while others may have no transactional support. Note: ACID is discussed in the lesson titled
“Transactions and Locking.”
• **Locking: **Storage engines may use different locking granularity (such as table-level or
row-level locks) and mechanisms to provide consistency with concurrent transactions.
• Backup and recovery: May be affected by how the storage engine stores and operates the data
• Optimization: Different indexing implementations may affect optimization. Storage engines
use internal caches, buffers, and memory in different ways to optimize performance.
• Special features: Certain engine types have features that provide full-text search, referential
integrity, and the ability to handle spatial data.
The optimizer may need to make different choices depending on the storage engine, but this is all
handled through a standardized interface (API) that each storage engine supports.
How MySQL Uses Disk Space

Program files are stored under server installation directories, along with the data directory. The program
executable and log files are created by the execution of the various client, administrative, and utility
programs. The primary use of disk space is the data directory.
- Server log files and status files contain information about statements that the server processes. Logs
are used for troubleshooting, monitoring, replication, and recovery. - InnoDB log files for all databases
reside at the data directory level. - InnoDB System Table space contains the data dictionary, undo log,
and buffers. - Each database has a single directory under the data directory, regardless of what types of
tables are created in the database. The database directories store the following:
• Data files:Storage engine–specific data files. These files can also include metadata or index
information, depending on the storage engine used.
• Format files (.frm):Contain a description of each table and/or view structure, located in the
corresponding database directory
 • Triggers:Named database objects that are associated with a table and are activated when a
particular event occurs for the table
- The location of the data directory depends on the configuration, operating system, installation package,
and distribution. A typical location is /var/lib/mysql. - MySQL stores the system database (mysql) on
disk. mysql contains information such as users, privileges, plugins, help lists, events, time-zone
implementations, and stored routines.
How MySQL Uses Memory
Memory allocation can be divided into the following two categories:
1. Global(per-instance memory): Allocated once when the server starts and freed when the server
shuts down. This memory is shared across all sessions. When all the physical memory has been used
up, the operating system starts swapping. This has an adverse effect on MySQL server performance and
can cause the server to crash
2. Session(per-session memory): Dynamically allocated per session (sometimes referred to as thread).
This memory can be freed when the session ends or is no longer needed. This memory is mostly used
for handling query results. The sizes of the buffers used are per connection. For instance, a read_buffer
of 10 MB with 100 connections means that there could be a total of 100*10 MB used for all read buffers
simultaneously.
Memory Structures
Server allocates memory in three different categories:

The server allocates memory for many kinds of data as it runs.

1. Thread cache: Threads are used in MySQL (and other programs) to split the execution of the
application into two or more simultaneously running tasks. An individual thread is created for each
client that connects to the MySQL server to handle that connection.
2. Buffers and caches: Buffers and caches provide a data management subsystem and support fast-
access items such as grant table buffers, storage engine buffers such as InnoDB’s log buffers, and table
open caches that hold descriptors for open tables. A query cache is also used to speed up the processing
of queries that are issued repeatedly.
If you use the MEMORY storage engine, MySQL uses the main memory as the principal data store.
Other storage engines may also use the main memory for data storage, but MEMORY is unique for
being designed not to store data on disk.
Connection/Session
1. Internal temporary tables: In some cases of query execution, MySQL creates a temporary table to
resolve the query. The temporary table can be created in memory or on disk depending on its size or
contents or on the query syntax.
2. Client-specific buffers : Are specifically designed to support the individual clients that are
connected. Examples of the buffers include:
• Communications buffer for exchanging information
• Table read buffers (including buffers that support joins)
• Sort operations
MySQL Plugin Interface
Currently, the plugin API supports:
• Full-text parser plugins that can be used to replace or augment the built-in full-text parser. For
example, a plugin can parse text into words by using rules that differ from those used by the
built-in parser. This is useful to parse text with characteristics different from those expected by
the built-in parser.
• Storage engines that provide low-level storage, retrieval, and data indexing to the server
• Information schema plugins. An information schema plugin appears as a table in the MySQL
INFORMATION_SCHEMAdatabase. The INFORMATION_SCHEMAdatabase is discussed
later in more detail.
• A Daemon plugin starts a background process that runs within the server (for example, to
perform heartbeat processing at regular intervals).
The plugin interface requires the PLUGINS table in the mysql database. This table is created as part of
the MySQL installation process.

MySQL Workbench is a visual database design tool that

integrates SQL development, administration, database design, creation and maintenance into a
single integrated development environment for the MySQL database system. It is the successor to
DBDesigner 4 from fabFORCE.net, and replaces the previous package of software, MySQL GUI Tools
Bundle.
History
fabFORCE.net DBDesigner4

fabFORCE.net
DBDesigner4
DBDesigner4 is an open source visual database design and querying tool for the MySQL database
released under the GPL. It was written in 2002/2003 by the Austrian programmer Michael G. Zinner
for his fabFORCE.net platform using Delphi 7 / Kylix 3.[3][4]
While being a physical-modeling only tool DBDesigner4 offers a comprehensive feature set including
reverse engineering of MySQL databases, model-to-database synchronization, model poster printing,
basic version control of schema models and a SQL query builder.[5] It is available for MS Windows,
Mac OS X and Linux.[6]
In late 2003, Zinner was approached by representatives from MySQL AB and joined the company to
take over the development of graphical user interface (GUI) tools for MySQL. This led to the creation
of the MySQL GUI Tools Bundle.[7]
MySQL GUI Tools Bundle

The MySQL Administrator part of GUI Tools

The MySQL GUI Tools Bundle is a cross-platform open source suite of desktop applications for the
administration of MySQL database servers, and for building and manipulating the data within MySQL
databases. It was developed by MySQL AB and later by Sun Microsystems and released under the GPL.
Development on the GUI Tools bundle has stopped, and is now[when?] only preserved under the
Download Archives of the MySQL site.[8]
The GUI Tools bundle has been superseded by MySQL Workbench, and reached its End-of-Life with
the beta releases of MySQL Workbench 5.2. However, the MySQL Support team continued to provide
assistance for the bundle until June 30, 2010.[9]
Releases
The first preview version of MySQL Workbench was released in September 2005, [10] and was not
included in the MySQL GUI Tools Bundle. Development was started again in 2007 and MySQL
Workbench was set to become the MySQL GUI flagship product.[11]
Version numbering was started at 5.0 to emphasise that MySQL Workbench was developed as the
successor to DBDesigner4.
MySQL Workbench 5.0 and 5.1
MySQL Workbench 5.0 and 5.1 are specialized visual database design tools for the MySQL database.
While MySQL Workbench 5.0 was a MS Windows-only product, cross-platform support was added to
MySQL Workbench 5.1 and later.
MySQL Workbench 5.2
Starting with MySQL Workbench 5.2 the application has evolved to a general database GUI application.
Apart from physical database modeling it features an SQL Editor, database migration tools, and a
database server administration interface, replacing the old MySQL GUI Tools Bundle.
MySQL Workbench 6.0
On May 22, 2013, the MySQL Workbench Team announced[15] that they were working on Version 6.0.
The first public beta, labeled version 6.0.2, was released[16] on June 14, 2013, and the first general-
availability release was made on August 12, 2013.[17]
MySQL Workbench 6.1
On January 23, 2014 the MySQL Workbench Team announced[18] its first public beta release of Version
6.1. The first general-availability release was made on March 31, 2014.[19] New features include
improved Visual Explain output, a Performance dashboard, Performance Schema support, additional
query result views, and MSAA support.
MySQL Workbench 6.2
[edit]
On August 19, 2014, the MySQL Workbench Team announced[20] its first public beta release of Version
6.2. The first general-availability release was made on September 23, 2014.[21] New features are shortcut
buttons for common operations, "pinning" of the results tab, Microsoft Access Migration, [22] MySQL
Fabric Integration, Spatial View Panel to visualize spatial and geometry data, Geometry Data Viewer,
Result Set Width, SQL editor tabs are properly saved, Shared Snippets, a new Run SQL Script dialog,
Model Script Attachments, Client Connections management has a new "Show Details" window where
more information about connections, locks, and attributes is displayed, performance columns can
display sizes in KB, MB, or GB, the migration wizard can resume operations of data copying if
interrupted, MySQL connection password is remembered across the MySQL Workbench session.
MySQL Workbench 6.3
[edit]
On March 5, 2015, the MySQL Workbench Team announced[23] its first public beta release of Version
6.3. The first general-availability release was made on April 23, 2015.[24] New features include a "fast
migration" option to migrate the data from the command-line instead of the GUI, a SSL certificate
generator, improved SQL auto-completion, a new table data import and export wizard, and MySQL
Enterprise Firewall support. Version 6.3.8, MySQL Workbench for MacOS has incompatibilities with
MacOS Sierra.[25] Version 6.3.9 is compatible with MacOS Sierra, however it doesn't work on MacOS
High Sierra.[26] MacOS High Sierra users need to run version 6.3.10.[26]
MySQL Workbench 8.0
[edit]
On April 5, 2018, the MySQL Workbench Team announced[27] the first public release of version 8.0.11
as a Release Candidate (RC) together with MySQL Community Server 8.0.11. The first General
Availability (GA) release appeared on July 27, 2018[28] again together with the server following the new
policy for aligning version numbers across most of MySQL products.[29] MySQL Workbench now
uses ANTLR4 as backend parser and has a new auto-completion engine that works with object editors
(triggers, views, stored procedures, and functions) in the visual SQL editor and in models. The new
versions add support for new language features in MySQL 8.0, such as common-table expressions and
roles. There's also support for invisible indexes and persisting of global system variables. The new
default authentication plugin caching_sha2_password in MySQL 8.0 is now supported by Workbench,
so resetting user accounts to other authentication types is no longer necessary when connecting to the
latest servers. Administrative tabs are updated with the latest configuration options and the user
interface was made more consistent between the tabs.
As of 1 July 2024, the latest version is 8.0.38, but its syntax-checker is inconsistent with deprecation of
the terms "master" and "slave" in favour of "source" and "replica" respectively in MySQL version 8.0.
Features
[edit]
Prominent features of MySQL Workbench are:
• General
• Database Connection & Instance Management
• Wizard driven action items
• Fully scriptable with Python and Lua
• Support for custom plugins
 • MSAA (Windows Accessibility API) compliant
• Supports MySQL Enterprise features (Audit Log, Firewall, and Enterprise Backup)
• SQL Editor
• Schema object browsing, inspection, and search
• SQL syntax highlighter and statement parser
• SQL code completion and context sensitive help
• Multiple and editable result sets
• Visual EXPLAIN
• SQL snippets collections
• SSH connection tunneling
• Unicode support
• Data modeling
• ER diagramming
• Drag'n'Drop visual modeling
• Reverse engineering from SQL Scripts and live database
• Forward engineering to SQL Scripts and live database
• Schema synchronization
• Printing of models
• Import from fabFORCE.net DBDesigner4
• Database administration
• Start and stop of database instances
• Instance configuration
• Database account management
• Instance variables browsing
• Log file browsing
• Data dump export/import
• Performance monitoring
• Performance Schema metrics
• MySQL instance dashboard
• Query statistics
• Database migration
• Any ODBC compliant database
• Native support: Microsoft SQL Server, PostgreSQL, SQL Anywhere, SQLite, and
Sybase ASE
Licensing and editions
MySQL Workbench is the first MySQL family of products that offer two different editions - an open
source and a proprietary edition.[30] The "Community Edition" is a full featured product that is not
crippled in any way. Being the foundation for all other editions it will benefit from all future
development efforts. The proprietary "Standard Edition" extends the Community Edition with a series
of modules and plugins.[31][citation needed]
As this business decision was announced soon after the takeover of MySQL by Sun Microsystems, this
has caused speculation in the press about the future licensing of the MySQL database.[32][33]
Community reception and reviews
Since its introduction MySQL Workbench has become popular within the MySQL community. It is now
the second most downloaded product from the MySQL website with more than 250,000 downloads a
month.[34] Before that it was voted Database Tool of the Year 2009 on Developer.com.[35]

Unit 3

The answer is, yes. Database maintenance or table maintenance is required to identify and correct the
database issues such as-
• Server crash which results in damaged tables.
• Slow query processing.
There are multiple ways to analyze and maintain your database tables such as –
• MySQL Workbench
• Server Auto-Recovery
• SQL Statements
• mysqlcheck and myisamchk
• MySQL Enterprise Monitor
In this tutorial, we will learn SQL statements that are used to perform MySQL table maintenance.
Table Maintenance Using SQL Statements
There are multiple SQL statements available for analyzing, checking, repairing and optimizing the table.
• ANALYZE TABLE – To update index statistics
• CHECK TABLE – To check a table or tables for errors.
• CHECKSUM TABLE – To check integrity properly
• REPAIR TABLE – To perform repairs if any
• OPTIMIZE TABLE – To optimize the table
We will see the details of each statement one by one along with its syntax and example.
ANALYZE TABLE Statement
When you do a join on something other than a constant, MySQL utilizes the stored key distribution
statistics to determine the order in which the optimizer joins tables. Furthermore, key distributions
decide the indexes MySQL uses for each table in a query. To analyze and save the statistics, use the
ANALYZE TABLE command, or set InnoDB to gather them automatically after a certain number of
data changes or when you query table or index metadata.
In short, ANALYZE TABLE does a key distribution analysis on the named table or tables and saves the
results. This statement is comparable to myisamchk – analysis for MyISAM tables.
Following are the characteristics of ANALYZE TABLE statement-
• MySQL locks the table with a read lock for InnoDB and MyISAM during analysis.
• To perform analysis, you require SELECT and INSERT privileges.
• It supports partitioned tables.
Syntax of the ANALYZE TABLE statement is –
ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name]
Let’s analyze an existing table.
ANALYZE TABLE journaldev.emp;

Analyze Table
MySQL does not analyze the table if it has not changed since running the last ANALYZE TABLE
command.
CHECK TABLE Statement
CHECK TABLE looks for faults in a table or tables. CHECK TABLE may also check views for issues,
such as tables that are no longer referenced in the view definition.
Following are the characteristics of the CHECK TABLE-
• It works for InnoDB, MyISAM, ARCHIVE, and CSV tables only.
• It supports partitioned tables as well.
The FOR UPGRADE option determines whether or not the listed tables are compatible with the current
MySQL version. The server uses FOR UPGRADE to check each table to see whether any of the table’s
data types or indexes have changed in an incompatible way since the table was created. If this is not the
case, the check will be successful. Otherwise, if a suspected conflict exists, the server does a thorough
table check (which might take some time).
Syntax of the CHECK TABLE statement is –
CHECK TABLE tbl_name [, tbl_name] ... [option] ...Code language: SQL (Structured Query
Language) (sql)
Let’s check an existing table –
CHECK TABLE journaldev.emp;Code language: SQL (Structured Query Language) (sql)

Check Table
Repair a table if the output from the CHECK TABLE shows that it has issues. Before fixing a table,
you might use the CHECK TABLE command to discover hardware issues (such as faulty memory or
bad disc sectors). Normally, the Msg text output column is ok. Run a table repair if you don’t get either
OK or the Table is already up to date. If the table is identified as corrupted or not properly closed, yet
CHECK TABLE finds no problems with it, it is regarded as OK.
CHECKSUM TABLE Statement
CHECKSUM TABLE returns a checksum for a table’s contents. This statement can be used to ensure
that the contents are the same before and after a backup, rollback, or other action that restores the data
to a known state.
Following are the characteristics of the CHECKSUM TABLE-
• It requires the SELECT privilege on the table.
• It does not support views. The checksum value will be NULL if you run the statement against
a view and will return a warning.
• It will return the checksum value NULL and a warning if you run the statement against a non-
existing table.
• The table is locked with a read lock for InnoDB and MyISAM during the checksum operation.
Syntax of the CHECKSUM TABLE is-
CHECKSUM TABLE tbl_name [, tbl_name] ... [
Let’s find a checksum value of an existing table.
CHECKSUM TABLE journaldev.emp;

Checksum Table
The value of the checksum is determined by the table row format. When the row format changes, so do
the checksum. For example, after MySQL 4.1, the storage format for VARCHAR changed, therefore if
you upgrade a 4.1 table to a later version, the checksum value will change if the table contains
VARCHAR columns.
OPTIMIZE TABLE Statement
To save storage space and enhance I/O efficiency while accessing the database, OPTIMIZE TABLE
reorganizes the physical storage of table data and related index data by defragmenting it. The specific
modifications performed to each table are determined by the table’s storage engine.
Following are the characteristics of the OPTIMIZE TABLE-
• Defragmenting entails recovering unnecessary space caused by deletions and updates, as well
as consolidating records that have gotten divided and stored in several locations.
• It requires SELECT and INSERT privileges on the table.
• It works for InnoDB, MyISAM, and ARCHIVE tables only.
After updating a large number of rows, you may use the OPTIMIZE TABLE query to rebuild a
FULLTEXT index in InnoDB. OPTIMIZE TABLE is mapped to ALTER TABLE in InnoDB tables,
which rebuilds the table to update index statistics and clear up unnecessary space in the clustered index.
Because InnoDB does not suffer from fragmentation like other storage engines, you won’t need to use
OPTIMIZE TABLE very often.
Syntax of the OPTIMIZE table is:
OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] .
Let’s optimize an existing table:
OPTIMIZE TABLE is mapped to ALTER TABLE… FORCE in InnoDB tables, which rebuilds the table
to update index statistics and free up space in the clustered index. When you run OPTIMIZE TABLE
on an InnoDB table, this appears in the output, as shown below:
OPTIMIZE TABLE uuids;

Optimize Table
REPAIR TABLE Statement
REPAIR TABLE works only for particular storage engines, and it fixes a potentially corrupted table.
Following are the characteristics of the REPAIR TABLE-
• It requires SELECT and INSERT privileges on the table.
• QUICK option: Only attempts to fix the index file rather than the data file. This form of
correction is similar to what myisamchk –recover –fast does.
• EXTENDED option: Instead of building one index at a time with sorting, MySQL builds the
index row by row. This is similar to the work done by myisamchk –safe-recover.
 • USE_FRM option: If the.MYI index file is missing or its header is malformed, the USE FRM
option is available. This option instructs MySQL not to trust the information in the.MYI file
header and to re-create it using data dictionary information. Myisamchk is unable to do this
type of repair.
Before doing a table repair procedure, it is essential to make a backup of the table; in some cases, the
action may result in data loss. File system faults are one of the possible reasons, although they are not
the only ones.
To avoid additional corruption, if the server breaks during a REPAIR TABLE action, you should
immediately restart the server and run another REPAIR TABLE before completing any other activities.
If you regularly need to use REPAIR TABLE to recover from corrupt tables, attempt to figure out what’s
causing the problem so you can avoid having to use REPAIR TABLE.
Syntax of the REPAIR TABLE is –
REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]Code language: SQL (Structured Query Language) (sql)
Let’s repair an existing table-
REPAIR TABLE uuids;Code language: SQL (Structured Query Language) (sql)

Repair Table
Here, the table is of type InnoDB, hence the repair will not work on it. We will change the storage
engine of the table to MyISAM and re-run the statement.

Repair
Table OK
As you can see, there is no need to repair the table hence it returned the message “OK”.
MySQL Table Locking
Summary: in this tutorial, you will learn how to use MySQL locking for cooperating table accesses
between sessions.
A lock is a flag associated with a table. MySQL allows a client session to explicitly acquire a table lock
to prevent other sessions from accessing the same table during a specific period.
A client session can acquire or release table locks only for itself. A client session cannot acquire or
release table locks for other client sessions.

Before we move on, let’s create a table named messages for practicing with the table locking
statements.
CREATE TABLE messages (
id INT AUTO_INCREMENT PRIMARY KEY,
message VARCHAR(100) NOT NULL
);Code language: SQL (Structured Query Language) (sql)
MySQL LOCK TABLES statement
The following LOCK TABLES statement explicitly acquires a table lock:
LOCK TABLES table_name [READ | WRITE]Code language: SQL (Structured Query Language) (sql)
In this syntax, you specify the name of the table that you want to lock after the LOCK
TABLES keywords. In addition, you specify the type of lock, either READ or WRITE.
MySQL allows you to lock multiple tables by specifying a list of comma-separated table names with
lock types that you want to lock after the LOCK TABLES keywords:
LOCK TABLES table_name1 [READ | WRITE],
table_name2 [READ | WRITE],
... ;Code language: SQL (Structured Query Language) (sql)
MySQL UNLOCK TABLES statement
The UNLOCK TABLES statement releases any table locks held by the current session:
UNLOCK TABLES;Code language: SQL (Structured Query Language) (sql)
READ Locks
A READ lock has the following features:
• A READ lock for a table can be acquired by multiple sessions at the same time. In addition,
other sessions can read data from the table without acquiring the lock.
• The session that holds the READ lock can only read data from the table, but cannot write. And
other sessions cannot write data to the table until the READ lock is released. The write
operations from another session will be put into the waiting states until the READ lock is
released.
• If the session is terminated, either normally or abnormally, MySQL will release all the locks
implicitly. This feature is also relevant to the WRITE lock.
Let’s take a look at how the READ lock works in the following scenario.
First, connect to the database in the first session and use the CONNECTION_ID() function to get the
current connection id as follows:
SELECT CONNECTION_ID();Code language: SQL (Structured Query Language) (sql)

Then, insert a new row into the messages table.

INSERT INTO messages(message)
VALUES('Hello');Code language: SQL (Structured Query Language) (sql)
Next, query the data from the messages table.
SELECT * FROM messages;Code language: SQL (Structured Query Language) (sql)

After that, acquire a lock using the LOCK TABLE statement.

LOCK TABLE messages READ;Code language: SQL (Structured Query Language) (sql)
Finally, try to insert a new row into the messages table:
INSERT INTO messages(message)
VALUES('Hi');Code language: SQL (Structured Query Language) (sql)
MySQL issued the following error:
Error Code: 1099. Table 'messages' was locked with a READ lock and can't be updated.Code language:
SQL (Structured Query Language) (sql)
So once the READ lock is acquired, you cannot write data to the table within the same session.
Let’s check the READ lock from a different session.
First, connect to the database and check the connection id:
SELECT CONNECTION_ID();Code language: SQL (Structured Query Language) (sql)
Next, query data from the messages table:
SELECT * FROM messages;Code language: SQL (Structured Query Language) (sql)

Then, insert a new row into the messages table:

INSERT INTO messages(message)
VALUES('Bye');Code language: SQL (Structured Query Language) (sql)
Here is the output:

The insert operation from the second session is in the waiting state because a READ lock is already
acquired on the messages table by the first session and it has not been released yet.
From the first session, use the SHOW PROCESSLIST statement to show detailed information:
SHOW PROCESSLIST;Code language: SQL (Structured Query Language) (sql)

After that, go back to the first session and release the lock by using the UNLOCK TABLES statement.
After you release the READ lock from the first session, the INSERT operation in the second session is
executed.
Finally, check the data of the messages table to see if the INSERT operation from the second session
was executed.
SELECT * FROM messages;Code language: SQL (Structured Query Language) (sql)

Write Locks
A WRITE lock has the following features:
• The only session that holds the lock of a table can read and write data from the table.
• Other sessions cannot read data from and write data to the table until the WRITE lock is
released.
Let’s go into detail to see how the WRITE lock works.
First, acquire a WRITE lock from the first session.
LOCK TABLE messages WRITE;Code language: SQL (Structured Query Language) (sql)
Then, insert a new row into the messages table.
INSERT INTO messages(message)
VALUES('Good Morning');Code language: SQL (Structured Query Language) (sql)
It worked.
Next, query data from the messages table.
SELECT * FROM messages;Code language: SQL (Structured Query Language) (sql)

It also works.
After that, from the second session, attempt to write and read data:
INSERT INTO messages(message)
VALUES('Bye Bye');

SELECT * FROM messages;Code language: SQL (Structured Query Language) (sql)

MySQL puts these operations into a waiting state. You can check it using the SHOW
PROCESSLIST statement:
SHOW PROCESSLIST;Code language: SQL (Structured Query Language) (sql)

Finally, release the lock from the first session.

UNLOCK TABLES;Code language: SQL (Structured Query Language) (sql)
You will see all pending operations from the second session executed and the following picture
illustrates the result:

Read vs. Write locks

• Read locks are “shared” locks that prevent a write lock is being acquired but not other read
locks.
• Write locks are “exclusive” locks that prevent any other lock of any kind.
In this tutorial, you have learned how to lock and unlock tables to cooperate with the table accesses
between sessions.
0.11.1 Internal Locking Methods
This section discusses internal locking; that is, locking performed within the MySQL server itself to
manage contention for table contents by multiple sessions. This type of locking is internal because it is
performed entirely by the server and involves no other programs. For locking performed on MySQL
files by other programs, see Section 10.11.5, “External Locking”.
• Row-Level Locking
• Table-Level Locking
• Choosing the Type of Locking
Row-Level Locking
MySQL uses row-level locking for InnoDB tables to support simultaneous write access by multiple
sessions, making them suitable for multi-user, highly concurrent, and OLTP applications.
To avoid deadlocks when performing multiple concurrent write operations on a single InnoDB table,
acquire necessary locks at the start of the transaction by issuing a SELECT ... FOR UPDATE statement
for each group of rows expected to be modified, even if the data change statements come later in the
transaction. If transactions modify or lock more than one table, issue the applicable statements in the
same order within each transaction. Deadlocks affect performance rather than representing a serious
error, because InnoDB automatically detects deadlock conditions by default and rolls back one of the
affected transactions.
On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait
for the same lock. At times, it may be more efficient to disable deadlock detection and rely on
the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs. Deadlock
detection can be disabled using the innodb_deadlock_detect configuration option.
Advantages of row-level locking:
• Fewer lock conflicts when different sessions access different rows.
• Fewer changes for rollbacks.
• Possible to lock a single row for a long time.
Table-Level Locking
MySQL uses table-level locking for MyISAM, MEMORY, and MERGE tables, permitting only one
session to update those tables at a time. This locking level makes these storage engines more suitable
for read-only, read-mostly, or single-user applications.
These storage engines avoid deadlocks by always requesting all needed locks at once at the beginning
of a query and always locking the tables in the same order. The tradeoff is that this strategy reduces
concurrency; other sessions that want to modify the table must wait until the current data change
statement finishes.
Advantages of table-level locking:
• Relatively little memory required (row locking requires memory per row or group of rows
locked)
• Fast when used on a large part of the table because only a single lock is involved.
• Fast if you often do GROUP BY operations on a large part of the data or must scan the entire
table frequently.
MySQL grants table write locks as follows:
1. If there are no locks on the table, put a write lock on it.
 2. Otherwise, put the lock request in the write lock queue.
MySQL grants table read locks as follows:
1. If there are no write locks on the table, put a read lock on it.
2. Otherwise, put the lock request in the read lock queue.
Table updates are given higher priority than table retrievals. Therefore, when a lock is released, the lock
is made available to the requests in the write lock queue and then to the requests in the read lock queue.
This ensures that updates to a table are not “starved” even when there is heavy SELECT activity for the
table. However, if there are many updates for a table, SELECT statements wait until there are no more
updates.
For information on altering the priority of reads and writes, see Section 10.11.2, “Table Locking Issues”.
You can analyze the table lock contention on your system by checking
the Table_locks_immediate and Table_locks_waited status variables, which indicate the number of
times that requests for table locks could be granted immediately and the number that had to wait,
respectively:
mysql> SHOW STATUS LIKE 'Table%';
+-----------------------+---------+
| Variable_name | Value |
+-----------------------+---------+
| Table_locks_immediate | 1151552 |
| Table_locks_waited | 15324 |
+-----------------------+---------+
The Performance Schema lock tables also provide locking information. See Section 29.12.13,
“Performance Schema Lock Tables”.
The MyISAM storage engine supports concurrent inserts to reduce contention between readers and
writers for a given table: If a MyISAM table has no free blocks in the middle of the data file, rows are
always inserted at the end of the data file. In this case, you can freely mix
concurrent INSERT and SELECT statements for a MyISAM table without locks. That is, you can insert
rows into a MyISAM table at the same time other clients are reading from it. Holes can result from rows
having been deleted from or updated in the middle of the table. If there are holes, concurrent inserts are
disabled but are enabled again automatically when all holes have been filled with new data. To control
this behavior, use the concurrent_insert system variable. See Section 10.11.3, “Concurrent Inserts”.
If you acquire a table lock explicitly with LOCK TABLES, you can request a READ LOCAL lock
rather than a READ lock to enable other sessions to perform concurrent inserts while you have the table
locked.
To perform many INSERT and SELECT operations on a table t1 when concurrent inserts are not
possible, you can insert rows into a temporary table temp_t1 and update the real table with the rows
from the temporary table:
mysql> LOCK TABLES t1 WRITE, temp_t1 WRITE;
mysql> INSERT INTO t1 SELECT * FROM temp_t1;
mysql> DELETE FROM temp_t1;
mysql> UNLOCK TABLES;
Choosing the Type of Locking
Generally, table locks are superior to row-level locks in the following cases:
• Most statements for the table are reads.
• Statements for the table are a mix of reads and writes, where writes are updates or deletes for a
single row that can be fetched with one key read:
• UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;
DELETE FROM tbl_name WHERE unique_key_col=key_value;
• SELECT combined with concurrent INSERT statements, and very
few UPDATE or DELETE statements.
• Many scans or GROUP BY operations on the entire table without any writers.
With higher-level locks, you can more easily tune applications by supporting locks of different types,
because the lock overhead is less than for row-level locks.
Options other than row-level locking:
• Versioning (such as that used in MySQL for concurrent inserts) where it is possible to have one
writer at the same time as many readers. This means that the database or table supports different
views for the data depending on when access begins. Other common terms for this are “time
travel,” “copy on write,” or “copy on demand.”
• Copy on demand is in many cases superior to row-level locking. However, in the worst case, it
can use much more memory than using normal locks.
• Instead of using row-level locks, you can employ application-level locks, such as those
provided by GET_LOCK() and RELEASE_LOCK() in MySQL. These are advisory locks, so
they work only with applications that cooperate with each other. See Section 14.14, “Locking
Functions”.

2. Row-Level Locks
Row-level locking is more granular and is supported by the InnoDB storage engine.
• Implicit Locks: InnoDB automatically locks rows that are being modified or selected with
certain conditions. These locks are managed by the storage engine.
• Explicit Locks: You can also explicitly request row-level locks using SQL statements:
o SELECT ... FOR UPDATE: Locks the selected rows for update, preventing other
transactions from modifying or locking those rows.

SELECT * FROM table_name WHERE condition FOR UPDATE;

o SELECT ... LOCK IN SHARE MODE: Locks the selected rows to prevent other
transactions from modifying them, but allows other transactions to read them.
SELECT * FROM table_name WHERE condition LOCK IN SHARE MODE;
Use Cases: Row-level locks are more suitable for high-concurrency environments because they lock
only the rows being accessed or modified.
Locking Mechanisms
1. Implicit Locking
• Transaction Control: InnoDB handles locks automatically as part of transaction management.
When a transaction starts, it acquires locks on the rows it accesses based on the operations
performed and the isolation level of the transaction.
• Isolation Levels: MySQL supports different transaction isolation levels that control how
transactions interact with each other and manage locks:
o READ UNCOMMITTED: Allows dirty reads. Transactions can see uncommitted
changes from other transactions.
o READ COMMITTED: Only committed changes are visible to transactions. No dirty
reads.
o REPEATABLE READ: Ensures that if a transaction reads a row, it will see the same
row if read again in the same transaction.
o SERIALIZABLE: The strictest level, where transactions are executed in a serial order
to prevent conflicts.
Documentation: MySQL Isolation Levels
2. Explicit Locking
• Explicit Table Locks: Used to lock tables at the beginning of a transaction. This can block
other sessions from accessing the locked tables.
• Explicit Row Locks: Achieved through SELECT ... FOR UPDATE or SELECT ... LOCK IN
SHARE MODE to control access at the row level.
Deadlocks
A deadlock occurs when two or more transactions hold locks that prevent each other from proceeding.
InnoDB automatically detects deadlocks and rolls back one of the transactions to resolve the deadlock.
• Detection and Resolution: InnoDB uses a deadlock detection algorithm that periodically
checks for deadlocks. When detected, it will automatically choose a transaction to roll back and
allow the other transactions to proceed.
Handling Deadlocks:
• Retry Logic: Implement retry logic in your application code to handle deadlocks gracefully.
• Minimize Locking Time: Keep transactions short and avoid holding locks for extended
periods.
Best Practices for Locking
1. Use Transactions Wisely: Keep transactions as short as possible to reduce the likelihood of
locking conflicts and deadlocks.
2. Indexing: Proper indexing helps reduce the number of rows locked by queries, improving
performance.
3. Isolation Levels: Choose the appropriate isolation level based on your application’s needs.
Lower isolation levels can improve performance but may expose transactions to issues like
dirty reads.
 4. Monitor and Optimize: Use MySQL performance monitoring tools to analyze locking issues
and optimize your queries and schema.
5. Avoid Lock Contention: Minimize contention by avoiding long-running queries and updating
rows in a manner that reduces lock contention.
By understanding and properly managing locks, you can ensure better concurrency control and maintain
the performance and integrity of your MySQL databases.

Row-level locking in MySQL is a mechanism that allows multiple transactions to operate on the same
table concurrently without interfering with each other, by locking only the rows that are being modified.
This helps in improving performance and concurrency compared to table-level locking, where the entire
table is locked for the duration of a transaction.
Here’s a detailed look at how row-level locking works in MySQL:
1. Storage Engines
Row-level locking is supported by certain storage engines in MySQL, notably:
• InnoDB: The default storage engine in MySQL, which provides support for row-level locking.
• MyISAM: Uses table-level locking rather than row-level locking.
2. How It Works
When a transaction modifies a row, MySQL locks that specific row to prevent other transactions from
making conflicting changes to it until the first transaction completes. This locking is generally done
using the following mechanisms:
• Shared Locks: Allow other transactions to read the row but not modify it.
• Exclusive Locks: Prevent other transactions from reading or modifying the row.
3. Types of Locks
InnoDB supports several types of row-level locks:
• Record Locks: Lock a single row in the table.
• Gap Locks: Prevent new rows from being inserted into the gap between existing rows. This is
useful for preventing phantom reads.
• Next-Key Locks: A combination of record and gap locks. They lock the row and the gap before
and after the row, helping prevent both phantom reads and other transactions from inserting
rows into the range.
4. Transactions and Isolation Levels
Row-level locking interacts with MySQL’s transaction isolation levels:
• READ COMMITTED: Allows reading of committed data. Row-level locks are held only
during the duration of the transaction that is modifying the data.
• REPEATABLE READ: Ensures that if a transaction reads a row, it will see the same row if it
reads it again. This level uses Next-Key Locks to maintain consistent results.
• SERIALIZABLE: The strictest level, which ensures complete isolation by acquiring a range
lock on the data, making it behave as if transactions are executed serially.
5. Deadlock Handling
Deadlocks occur when two or more transactions are waiting for each other to release locks. InnoDB
detects deadlocks and automatically rolls back one of the transactions to resolve the deadlock, allowing
the other transaction(s) to proceed.
6. Example Usage
Consider a table employees with columns id, name, and salary. If two transactions try to update the
salary of the same employee concurrently:
• Transaction 1: UPDATE employees SET salary = salary + 1000 WHERE id = 1;
• Transaction 2: UPDATE employees SET salary = salary + 500 WHERE id = 1;
InnoDB will lock the row with id = 1 when Transaction 1 starts its update and will lock the same row
when Transaction 2 tries to update it. One transaction will complete successfully, and the other will be
rolled back or retried.
7. Best Practices
• Minimize Lock Duration: Keep transactions as short as possible to reduce the time locks are
held.
• Optimize Queries: Ensure queries use indexes effectively to minimize the number of rows
locked.
• Handle Deadlocks Gracefully: Implement proper error handling to retry transactions when
deadlocks occur.
By understanding and effectively using row-level locking, you can improve the concurrency and
performance of your MySQL databases.
4o mini
Table-level locking in MySQL is a locking mechanism where the entire table is locked during a
transaction, preventing other transactions from accessing or modifying the table's data until the lock is
released. This approach contrasts with row-level locking, where only the specific rows being modified
are locked, allowing for higher concurrency.
When Table-Level Locking is Used
Table-level locking is primarily associated with the following scenarios:
1. Storage Engines:
o MyISAM: The MyISAM storage engine uses table-level locking by default. It locks
the whole table for reading or writing operations.
 o InnoDB: Though InnoDB supports row-level locking, it can use table-level locks in
certain situations, such as during a schema change or when explicitly requested.
2. Explicit Table Locks:
o You can explicitly lock a table using SQL commands, which is useful when you need
to ensure exclusive access to the table for operations such as large data imports or
complex operations that need to be atomic.
Types of Table-Level Locks
• Read Lock (Shared Lock): Allows other transactions to read the table but prevents any write
operations. Multiple transactions can hold a read lock simultaneously.
• Write Lock (Exclusive Lock): Prevents any other transactions from reading or writing to the
table. Only one transaction can hold a write lock at a time.
Locking Commands
• LOCK TABLES: This command allows you to lock one or more tables in a specified mode.
sql

LOCK TABLES employees WRITE;

This locks the employees table for writing, preventing any other operations from modifying or reading
the table until the lock is released.
• UNLOCK TABLES: Releases any table locks that have been acquired by the current session.
sql

UNLOCK TABLES;
Implications and Considerations
1. Concurrency: Table-level locking can significantly impact concurrency. When a table is
locked, other transactions must wait until the lock is released, which can lead to contention and
reduced performance in high-traffic scenarios.
2. Performance: For operations that need to lock a large portion of the table or for operations on
a table with a high rate of concurrent access, table-level locking can be a bottleneck. Row-level
locking or other optimization strategies might be preferable.
3. Deadlocks: Although table-level locking generally reduces the risk of deadlocks compared to
row-level locking, it can still occur in complex scenarios involving multiple tables and
transactions.
4. Schema Changes: Certain schema modifications (like adding or dropping columns) may
require a table-level lock to ensure the changes are applied consistently.
Examples
1. Locking for Reading:
sql
LOCK TABLES employees READ;
This will allow only read operations on the employees table while preventing writes until the lock is
released.
2. Locking for Writing:

LOCK TABLES employees WRITE;

This prevents both reading and writing by other transactions until the lock is released.
3. Releasing Locks:

UNLOCK TABLES;
This command is used to release any table locks acquired by the session.
Best Practices
• Minimize Lock Duration: Keep the duration of table locks as short as possible to minimize
contention.
• Avoid Unnecessary Locks: Use table-level locking only when necessary, especially for high-
concurrency environments.
• Consider Alternatives: Evaluate whether row-level locking (with InnoDB) or other
mechanisms might better suit your needs for concurrent operations.
Table-level locking can be a useful tool in scenarios where exclusive access to a table is required.
However, in environments with high concurrent access, using a storage engine with row-level locking,
like InnoDB, may provide better performance and scalability.