MySQL, the most popular Open Source SQL database management system, is developed, distributed, and supported by MySQL AB. MySQL AB is a commercial company, founded by the MySQL developers. It is a second generation Open Source company that unites Open Source values and methodology with a successful business model.
The MySQL Web site (http://www.mysql.com/) provides the latest information about MySQL software and MySQL AB.
MySQL is a database management system.
A database is a structured collection of data. It may be anything from a simple shopping list to a picture gallery or the vast amounts of information in a corporate network. To add, access, and process data stored in a computer database, you need a database management system such as MySQL Server. Since computers are very good at handling large amounts of data, database management systems play a central role in computing, as standalone utilities, or as parts of other applications.
MySQL is a relational database management system.
A relational database stores data in separate tables rather than putting all the data in one big storeroom. This adds speed and flexibility. The SQL part of “MySQL” stands for “Structured Query Language.” SQL is the most common standardized language used to access databases and is defined by the ANSI/ISO SQL Standard. The SQL standard has been evolving since 1986 and several versions exist. In this manual, “SQL-92” refers to the standard released in 1992, “SQL:1999” refers to the standard released in 1999, and “SQL:2003” refers to the current version of the standard. We use the phrase “the SQL standard” to mean the current version of the SQL Standard at any time.
MySQL software is Open Source.
Open Source means that it is possible for anyone to use and modify the software. Anybody can download the MySQL software from the Internet and use it without paying anything. If you wish, you may study the source code and change it to suit your needs. The MySQL software uses the GPL (GNU General Public License), http://www.fsf.org/licenses/, to define what you may and may not do with the software in different situations. If you feel uncomfortable with the GPL or need to embed MySQL code into a commercial application, you can buy a commercially licensed version from us. See the MySQL Licensing Overview for more information (http://www.mysql.com/company/legal/licensing/).
The MySQL Database Server is very fast, reliable, and easy to use.
If that is what you are looking for, you should give it a try. MySQL Server also has a practical set of features developed in close cooperation with our users. You can find a performance comparison of MySQL Server with other database managers on our benchmark page. See Section 7.1.4, “The MySQL Benchmark Suite”.
MySQL Server was originally developed to handle large databases much faster than existing solutions and has been successfully used in highly demanding production environments for several years. Although under constant development, MySQL Server today offers a rich and useful set of functions. Its connectivity, speed, and security make MySQL Server highly suited for accessing databases on the Internet.
MySQL Server works in client/server or embedded systems.
The MySQL Database Software is a client/server system that consists of a multi-threaded SQL server that supports different backends, several different client programs and libraries, administrative tools, and a wide range of application programming interfaces (APIs).
We also provide MySQL Server as an embedded multi-threaded library that you can link into your application to get a smaller, faster, easier-to-manage standalone product.
A large amount of contributed MySQL software is available.
It is very likely that your favorite application or language supports the MySQL Database Server.
The official way to pronounce “MySQL” is “My Ess Que Ell” (not “my sequel”), but we don't mind if you pronounce it as “my sequel” or in some other localized way.
We started out with the intention of using the
mSQL database system to connect to our tables
using our own fast low-level (ISAM) routines. However, after some
testing, we came to the conclusion that
was not fast enough or flexible enough for our needs. This
resulted in a new SQL interface to our database but with almost
the same API interface as
mSQL. This API was
designed to allow third-party code that was written for use with
mSQL to be ported easily for use with MySQL.
The derivation of the name MySQL is not clear. Our base directory and a large number of our libraries and tools have had the prefix “my” for well over 10 years. However, co-founder Monty Widenius's daughter is also named My. Which of the two gave its name to MySQL is still a mystery, even for us.
The name of the MySQL Dolphin (our logo) is “Sakila,” which was chosen by the founders of MySQL AB from a huge list of names suggested by users in our “Name the Dolphin” contest. The winning name was submitted by Ambrose Twebaze, an Open Source software developer from Swaziland, Africa. According to Ambrose, the feminine name Sakila has its roots in SiSwati, the local language of Swaziland. Sakila is also the name of a town in Arusha, Tanzania, near Ambrose's country of origin, Uganda.
The following list describes some of the important characteristics of the MySQL Database Software. See also Section 1.6, “MySQL Development Roadmap”, for more information about current and upcoming features.
Internals and Portability:
Written in C and C++.
Tested with a broad range of different compilers.
Works on many different platforms. See Section 2.1.1, “Operating Systems Supported by MySQL”.
Uses GNU Automake, Autoconf, and Libtool for portability.
APIs for C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, and Tcl are available. See Chapter 22, APIs and Libraries.
Fully multi-threaded using kernel threads. It can easily use multiple CPUs if they are available.
Provides transactional and non-transactional storage engines.
Uses very fast B-tree disk tables (
with index compression.
Relatively easy to add other storage engines. This is useful if you want to add an SQL interface to an in-house database.
A very fast thread-based memory allocation system.
Very fast joins using an optimized one-sweep multi-join.
In-memory hash tables, which are used as temporary tables.
SQL functions are implemented using a highly optimized class library and should be as fast as possible. Usually there is no memory allocation at all after query initialization.
The MySQL code is tested with Purify (a commercial memory leakage detector) as well as with Valgrind, a GPL tool (http://developer.kde.org/~sewardj/).
The server is available as a separate program for use in a client/server networked environment. It is also available as a library that can be embedded (linked) into standalone applications. Such applications can be used in isolation or in environments where no network is available.
Many data types: signed/unsigned integers 1, 2, 3, 4, and 8
ENUM, and OpenGIS
spatial types. See Chapter 11, Data Types.
Fixed-length and variable-length records.
Statements and Functions:
Full operator and function support in the
of queries. For example:
SELECT CONCAT(first_name, ' ', last_name)->
WHERE income/dependents > 10000 AND age > 30;
Full support for SQL
GROUP BY and
ORDER BY clauses. Support for group
LEFT OUTER JOIN and
RIGHT OUTER JOIN with both standard SQL and
Support for aliases on tables and columns as required by standard SQL.
return the number of rows that were changed (affected). It is
possible to return the number of rows matched instead by
setting a flag when connecting to the server.
SHOW statement can be used
to retrieve information about databases, storage engines,
tables, and indexes.
EXPLAIN statement can be used to
determine how the optimizer resolves a query.
Function names do not clash with table or column names. For
ABS is a valid column name. The
only restriction is that for a function call, no spaces are
allowed between the function name and the
(’ that follows it. See
Section 9.5, “Treatment of Reserved Words in MySQL”.
You can mix tables from different databases in the same query (as of MySQL 3.22).
A privilege and password system that is very flexible and secure, and that allows host-based verification. Passwords are secure because all password traffic is encrypted when you connect to a server.
Scalability and Limits:
Handles large databases. We use MySQL Server with databases that contain 50 million records. We also know of users who use MySQL Server with 60,000 tables and about 5,000,000,000 rows.
Up to 64 indexes per table are allowed (32 before MySQL
4.1.2). Each index may consist of 1 to 16 columns or parts of
columns. The maximum index width is 1000 bytes (767 for
InnoDB); before MySQL 4.1.2, the limit is
500 bytes. An index may use a prefix of a column for
Clients can connect to the MySQL server using TCP/IP sockets on any platform. On Windows systems in the NT family (NT, 2000, XP, 2003, or Vista), clients can connect using named pipes. On Unix systems, clients can connect using Unix domain socket files.
In MySQL 4.1 and higher, Windows servers also support
shared-memory connections if started with the
--shared-memory option. Clients can connect
through shared memory by using the
The Connector/ODBC (MyODBC) interface provides MySQL support for client programs that use ODBC (Open Database Connectivity) connections. For example, you can use MS Access to connect to your MySQL server. Clients can be run on Windows or Unix. MyODBC source is available. All ODBC 2.5 functions are supported, as are many others. See Chapter 23, Connectors.
The Connector/J interface provides MySQL support for Java client programs that use JDBC connections. Clients can be run on Windows or Unix. Connector/J source is available. See Chapter 23, Connectors.
MySQL Connector/NET enables developers to easily create .NET applications that require secure, high-performance data connectivity with MySQL. It implements the required ADO.NET interfaces and integrates into ADO.NET aware tools. Developers can build applications using their choice of .NET languages. MySQL Connector/NET is a fully managed ADO.NET driver written in 100% pure C#. See Chapter 23, Connectors.
The server can provide error messages to clients in many languages. See Section 5.11.2, “Setting the Error Message Language”.
Full support for several different character sets, including
ujis, and more.
For example, the Scandinavian characters
ö’ are allowed in table and
column names. Unicode support is available as of MySQL 4.1.
All data is saved in the chosen character set. All comparisons for normal string columns are case-insensitive.
Sorting is done according to the chosen character set (using Swedish collation by default). It is possible to change this when the MySQL server is started. To see an example of very advanced sorting, look at the Czech sorting code. MySQL Server supports many different character sets that can be specified at compile time and runtime.
Clients and Tools:
MySQL Server has built-in support for SQL statements to check,
optimize, and repair tables. These statements are available
from the command line through the
mysqlcheck client. MySQL also includes
myisamchk, a very fast command-line utility
for performing these operations on
tables. See Chapter 5, Database Administration.
All MySQL programs can be invoked with the
-? options to
obtain online assistance.
This section addresses the questions, “How stable is MySQL Server?” and, “Can I depend on MySQL Server in this project?” We will try to clarify these issues and answer some important questions that concern many potential users. The information in this section is based on data gathered from the mailing lists, which are very active in identifying problems as well as reporting types of use.
The original code stems back to the early 1980s. It provides a
stable code base, and the
ISAM table format
used by the original storage engine remains backward-compatible.
At TcX, the predecessor of MySQL AB, MySQL code has worked in
projects since mid-1996, without any problems. When the MySQL
Database Software initially was released to a wider public, our
new users quickly found some pieces of untested code. Each new
release since then has had fewer portability problems, even though
each new release has also had many new features.
Each release of the MySQL Server has been usable. Problems have occurred only when users try code from the “gray zones.” Naturally, new users don't know what the gray zones are; this section therefore attempts to document those areas that are currently known. The descriptions mostly deal with Versions 3.23 and later of MySQL Server. All known and reported bugs are fixed in the latest version, with the exception of those listed in the bugs section, which are design-related. See Section A.8, “Known Issues in MySQL”.
The MySQL Server design is multi-layered with independent modules. Some of the newer modules are listed here with an indication of how well-tested each of them is:
Large groups of servers using replication are in production use, with good results. Work on enhanced replication features is continuing.
InnoDB tables (Stable)
InnoDB transactional storage engine has
been stable since version 3.23.49.
is being used in large, heavy-load production systems.
Full-text searches (Stable)
Full-text searching is widely used. Important feature enhancements were added in MySQL 4.0 and 4.1.
MyODBC 3.51 (Stable)
MyODBC 3.51 uses ODBC SDK 3.51 and is in
wide production use. Some issues brought up appear to be
application-related and independent of the ODBC driver or
underlying database server.
MySQL 3.22 had a 4GB (4 gigabyte) limit on table size. With the
MyISAM storage engine in MySQL 3.23, the
maximum table size was increased to 65536 terabytes
(2567 – 1 bytes). With this
larger allowed table size, the maximum effective table size for
MySQL databases is usually determined by operating system
constraints on file sizes, not by MySQL internal limits.
InnoDB storage engine maintains
InnoDB tables within a tablespace that can be
created from several files. This allows a table to exceed the
maximum individual file size. The tablespace can include raw disk
partitions, which allows extremely large tables. The maximum
tablespace size is 64TB.
The following table lists some examples of operating system file-size limits. This is only a rough guide and is not intended to be definitive. For the most up-to-date information, be sure to check the documentation specific to your operating system.
|Operating System||File-size Limit|
|Linux 2.2-Intel 32-bit||2GB (LFS: 4GB)|
|Linux 2.4+||(using ext3 filesystem) 4TB|
|NetWare w/NSS filesystem||8TB|
|Win32 w/ FAT/FAT32||2GB/4GB|
|Win32 w/ NTFS||2TB (possibly larger)|
|MacOS X w/ HFS+||2TB|
On Linux 2.2, you can get
MyISAM tables larger
than 2GB in size by using the Large File Support (LFS) patch for
the ext2 filesystem. On Linux 2.4, patches also exist for ReiserFS
to get support for big files (up to 2TB). Most current Linux
distributions are based on kernel 2.4 or higher and include all
the required LFS patches. With JFS and XFS, petabyte and larger
files are possible on Linux. However, the maximum available file
size still depends on several factors, one of them being the
filesystem used to store MySQL tables.
For a detailed overview about LFS in Linux, have a look at Andreas Jaeger's Large File Support in Linux page at http://www.suse.de/~aj/linux_lfs.html.
Windows users please note: FAT and VFAT (FAT32) are not considered suitable for production use with MySQL. Use NTFS instead.
By default, MySQL creates
MyISAM tables with an
internal structure that allows a maximum size of about 4GB. You
can check the maximum table size for a
table with the
SHOW TABLE STATUS statement or
with myisamchk -dv
Section 13.5.4, “
If you need a
MyISAM table that is larger than
4GB and your operating system supports large files, the
CREATE TABLE statement supports
options. See Section 13.1.5, “
CREATE TABLE Syntax”. You can also change
these options with
ALTER TABLE to increase a
table's maximum allowable size after the table has been created.
See Section 13.1.2, “
ALTER TABLE Syntax”.
Other ways to work around file-size limits for
MyISAM tables are as follows:
If your large table is read-only, you can use myisampack to compress it. myisampack usually compresses a table by at least 50%, so you can have, in effect, much bigger tables. myisampack also can merge multiple tables into a single table. See Section 8.5, “myisampack — Generate Compressed, Read-Only MyISAM Tables”.
MySQL includes a
MERGE library that allows
you to handle a collection of
that have identical structure as a single
MERGE table. See
Section 14.3, “The
MERGE Storage Engine”.
The MySQL Server itself has no problems with Year 2000 (Y2K) compliance:
MySQL Server uses Unix time functions that handle dates into
TIMESTAMP values. For
values, dates through the year
All MySQL date functions are implemented in one source file,
sql/time.cc, and are coded very carefully
to be year 2000-safe.
In MySQL, the
YEAR data type can store the
2155 in one byte and display them using two
or four digits. All two-digit years are considered to be in
which means that if you store
01 in a
YEAR column, MySQL Server treats it as
The following simple demonstration illustrates that MySQL Server
has no problems with
DATETIME values through the year 9999, and no
TIMESTAMP values until after the
DROP TABLE IF EXISTS y2k;Query OK, 0 rows affected (0.00 sec) mysql>
CREATE TABLE y2k (date DATE,->
time_stamp TIMESTAMP);Query OK, 0 rows affected (0.01 sec) mysql>
INSERT INTO y2k VALUES->
('1998-12-31','1998-12-31 23:59:59','1998-12-31 23:59:59'),->
('1999-01-01','1999-01-01 00:00:00','1999-01-01 00:00:00'),->
('1999-09-09','1999-09-09 23:59:59','1999-09-09 23:59:59'),->
('2000-01-01','2000-01-01 00:00:00','2000-01-01 00:00:00'),->
('2000-02-28','2000-02-28 00:00:00','2000-02-28 00:00:00'),->
('2000-02-29','2000-02-29 00:00:00','2000-02-29 00:00:00'),->
('2000-03-01','2000-03-01 00:00:00','2000-03-01 00:00:00'),->
('2000-12-31','2000-12-31 23:59:59','2000-12-31 23:59:59'),->
('2001-01-01','2001-01-01 00:00:00','2001-01-01 00:00:00'),->
('2004-12-31','2004-12-31 23:59:59','2004-12-31 23:59:59'),->
('2005-01-01','2005-01-01 00:00:00','2005-01-01 00:00:00'),->
('2030-01-01','2030-01-01 00:00:00','2030-01-01 00:00:00'),->
('2040-01-01','2040-01-01 00:00:00','2040-01-01 00:00:00'),->
('9999-12-31','9999-12-31 23:59:59','9999-12-31 23:59:59');Query OK, 14 rows affected, 2 warnings (0.00 sec) Records: 14 Duplicates: 0 Warnings: 2 mysql>
SELECT * FROM y2k;+------------+---------------------+---------------------+ | date | date_time | time_stamp | +------------+---------------------+---------------------+ | 1998-12-31 | 1998-12-31 23:59:59 | 1998-12-31 23:59:59 | | 1999-01-01 | 1999-01-01 00:00:00 | 1999-01-01 00:00:00 | | 1999-09-09 | 1999-09-09 23:59:59 | 1999-09-09 23:59:59 | | 2000-01-01 | 2000-01-01 00:00:00 | 2000-01-01 00:00:00 | | 2000-02-28 | 2000-02-28 00:00:00 | 2000-02-28 00:00:00 | | 2000-02-29 | 2000-02-29 00:00:00 | 2000-02-29 00:00:00 | | 2000-03-01 | 2000-03-01 00:00:00 | 2000-03-01 00:00:00 | | 2000-12-31 | 2000-12-31 23:59:59 | 2000-12-31 23:59:59 | | 2001-01-01 | 2001-01-01 00:00:00 | 2001-01-01 00:00:00 | | 2004-12-31 | 2004-12-31 23:59:59 | 2004-12-31 23:59:59 | | 2005-01-01 | 2005-01-01 00:00:00 | 2005-01-01 00:00:00 | | 2030-01-01 | 2030-01-01 00:00:00 | 2030-01-01 00:00:00 | | 2040-01-01 | 2040-01-01 00:00:00 | 0000-00-00 00:00:00 | | 9999-12-31 | 9999-12-31 23:59:59 | 0000-00-00 00:00:00 | +------------+---------------------+---------------------+ 14 rows in set (0.00 sec)
The final two
TIMESTAMP column values are zero
because the year values (
9999) exceed the
TIMESTAMP data type, which is used
to store the current time, supports values that range from
'1970-01-01 00:00:00' to
00:00:00' on 32-bit machines (signed value). On 64-bit
TIMESTAMP handles values up to
2106 (unsigned value).
Although MySQL Server itself is Y2K-safe, you may run into
problems if you use it with applications that are not Y2K-safe.
For example, many old applications store or manipulate years using
two-digit values (which are ambiguous) rather than four-digit
values. This problem may be compounded by applications that use
values such as
“missing” value indicators. Unfortunately, these
problems may be difficult to fix because different applications
may be written by different programmers, each of whom may use a
different set of conventions and date-handling functions.
Thus, even though MySQL Server has no Y2K problems, it is the application's responsibility to provide unambiguous input. See Section 11.3.4, “Y2K Issues and Date Types”, for MySQL Server's rules for dealing with ambiguous date input data that contains two-digit year values.