Abstract
This is the MySQL Reference Manual. It documents MySQL 3.23 through MySQL 4.1.16.
Document generated on: 2006-01-06 (revision: 696)
Table of Contents
AUTO_INCREMENTAccess denied ErrorsSELECT Statements and Other QueriesEXPLAIN Syntax (Get Information About a SELECT)SELECT QueriesWHERE ClausesIS NULLDISTINCTLEFT JOIN and RIGHT JOINORDER BYGROUP BYLIMITINSERT StatementsUPDATE StatementsDELETE StatementsMyISAM Key CacheMyISAM Index Statistics CollectionMyISAM TablesMyISAM Log FileCOLLATE in SQL StatementsCOLLATE Clause PrecedenceBINARY OperatorGROUP BY ClausesInnoDB Storage EngineInnoDB OverviewInnoDB Contact InformationInnoDB in MySQL 3.23InnoDB ConfigurationInnoDB Startup OptionsInnoDB TablespaceInnoDB TablesInnoDB Data and Log FilesInnoDB DatabaseInnoDB Database to Another MachineInnoDB Transaction Model and LockingInnoDB Lock ModesInnoDB and AUTOCOMMITInnoDB and TRANSACTION ISOLATION LEVELSELECT ... FOR UPDATE and SELECT ... LOCK IN SHARE MODEInnoDBInnoDBInnoDB Performance Tuning TipsInnoDB TablesInnoDB TroubleshootingGeometryPointCurveLineStringSurfacePolygonGeometryCollectionMultiPointMultiCurveMultiLineStringMultiSurfaceMultiPolygonGeometry FunctionsAccess deniedCan't connect to [local] MySQL serverClient does not support authentication protocolHost 'host_name' is blockedToo many connectionsOut of memoryMySQL server has gone awayPacket too largeThe table is fullCan't create/write to fileCommands out of syncIgnoring userTable 'tbl_name' doesn't existCan't initialize character setDATE ColumnsNULL ValuesInnoDBList of Tables
List of Examples
DriverManagerThis is the Reference Manual for all releases of the MySQL Database System through version 4.1.16. It is applicable for older versions of the MySQL software (such as 3.23 or 4.0-production) because functional changes are indicated with reference to a version number. For later MySQL releases, see the appropriately-numbered edition of this manual.
Table of Contents
The MySQL® software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software. MySQL is a registered trademark of MySQL AB.
The MySQL software is Dual Licensed. Users can choose to use the MySQL software as an Open Source product under the terms of the GNU General Public License (http://www.fsf.org/licenses/) or can purchase a standard commercial license from MySQL AB. See http://www.mysql.com/company/legal/licensing/ for more information on our licensing policies.
The following list describes some sections of particular interest in this manual:
For a discussion about the capabilities of the MySQL Database Server, see Section 1.4.2, “The Main Features of MySQL”.
For installation instructions, see Chapter 2, Installing MySQL.
For tips on porting the MySQL Database Software to new architectures or operating systems, see Appendix E, Porting to Other Systems.
For information about upgrading from MySQL 4.0 to MySQL 4.1, see Section 2.10.1, “Upgrading from MySQL 4.0 to 4.1”.
For information about upgrading from MySQL 3.23 to MySQL 4.0, see Section 2.10.2, “Upgrading from MySQL 3.23 to 4.0”.
For a tutorial introduction to the MySQL Database Server, see Chapter 3, Tutorial.
For benchmarking information, see the
sql-bench benchmarking directory in your
MySQL distribution.
For a history of new features and bugfixes, see Appendix D, MySQL Change History.
For a list of currently known bugs and misfeatures, see Section A.8, “Known Issues in MySQL”.
For a list of all the contributors to this project, see Appendix C, Credits.
Important:
To report errors (often called “bugs”), please visit http://bugs.mysql.com. See Section 1.8, “How to Report Bugs or Problems”.
If you have found a sensitive security bug in MySQL Server, please
let us know immediately by sending an email message to
<security@mysql.com>.
This is the Reference Manual for all releases of the MySQL Database System from version 3.23 through release 4.1.16. It is also applicable for versions of the MySQL software previous to 4.1 (such as 3.23 or 4.0) because functional changes are indicated with reference to version numbers. For later MySQL releases, see the appropriately-numbered edition of this manual.
Because this manual serves as a reference, it does not provide general instruction on SQL or relational database concepts. It also does not teach you how to use your operating system or command-line interpreter.
The MySQL Database Software is under constant development, and the Reference Manual is updated frequently as well. The most recent version of the manual is available online in searchable form at http://dev.mysql.com/doc/. Other formats also are available there, including HTML, PDF, and Windows CHM versions.
The Reference Manual source files are written in DocBook XML format. The HTML version and other formats are produced automatically, primarily using the DocBook XSL stylesheets. For information about DocBook, see http://docbook.org/
If you have any suggestions concerning additions or corrections to
this manual, please send them to the documentation team at
<docs@mysql.com>.
This manual was originally written by David Axmark and Michael “Monty” Widenius. It is maintained by the MySQL Documentation Team, consisting of Paul DuBois, Stefan Hinz, Mike Hillyer, and Jon Stephens. For the many other contributors, see Appendix C, Credits.
The copyright to this manual is owned by the Swedish company MySQL AB. MySQL® and the MySQL logo are registered trademarks of MySQL AB. Other trademarks and registered trademarks referred to in this manual are the property of their respective owners, and are used for identification purposes only.
This manual uses certain typographical conventions:
Text in this style is used for SQL
statements; database, table, and column names; program listings
and source code; and environment variables. Example: “To
reload the grant tables, use the FLUSH
PRIVILEGES statement”.
Text in this style indicates input that
you type in examples.
Text in this style indicates the names of executable programs and scripts, examples being mysql (the MySQL command line client program) and mysqld (the MySQL server executable).
Text in this style is used for
variable input for which you should substitute a value of your
own choosing.
Filenames and directory names are written like this: “The
global my.cnf file is located in the
/etc directory”.
Character sequences are written like this: “To specify a
wildcard, use the ‘%’
character”.
Text in this style is used for emphasis.
Text in this style is used in table headings and to convey especially strong emphasis.
When commands are shown that are meant to be executed from within a
particular program, the prompt shown preceding the command indicates
which command to use. For example, shell>
indicates a command that you execute from your login shell, and
mysql> indicates a statement that you execute
from the mysql client program:
shell>type a shell command heremysql>type a mysql statement here
The “shell” is your command interpreter. On Unix, this is typically a program such as sh, csh, or bash. On Windows, the equivalent program is command.com or cmd.exe, typically run in a console window.
When you enter a command or statement shown in an example, do not type the prompt shown in the example.
Database, table, and column names must often be substituted into
statements. To indicate that such substitution is necessary, this
manual uses db_name,
tbl_name, and
col_name. For example, you might see a
statement like this:
mysql> SELECT col_name FROM db_name.tbl_name;
This means that if you were to enter a similar statement, you would supply your own database, table, and column names, perhaps like this:
mysql> SELECT author_name FROM biblio_db.author_list;
SQL keywords are not case sensitive and may be written in any lettercase. This manual uses uppercase.
In syntax descriptions, square brackets
(‘[’ and
‘]’) indicate optional words or
clauses. For example, in the following statement, IF
EXISTS is optional:
DROP TABLE [IF EXISTS] tbl_name
When a syntax element consists of a number of alternatives, the
alternatives are separated by vertical bars
(‘|’). When one member from a set of
choices may be chosen, the alternatives are
listed within square brackets (‘[’
and ‘]’):
TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM]str)
When one member from a set of choices must be
chosen, the alternatives are listed within braces
(‘{’ and
‘}’):
{DESCRIBE | DESC} tbl_name [col_name | wild]
An ellipsis (…) indicates the omission of
a section of a statement, typically to provide a shorter version of
more complex syntax. For example, INSERT …
SELECT is shorthand for the form of
INSERT statement that is followed by a
SELECT statement.
An ellipsis can also indicate that the preceding syntax element of a
statement may be repeated. In the following example, multiple
reset_option values may be given, with
each of those after the first preceded by commas:
RESETreset_option[,reset_option] ...
Commands for setting shell variables are shown using Bourne shell
syntax. For example, the sequence to set the CC
environment variable and run the configure
command looks like this in Bourne shell syntax:
shell> CC=gcc ./configure
If you are using csh or tcsh, you must issue commands somewhat differently:
shell>setenv CC gccshell>./configure
MySQL AB is the company of the MySQL founders and main developers. MySQL AB was originally established in Sweden by David Axmark, Allan Larsson, and Michael “Monty” Widenius.
We are dedicated to developing the MySQL database software and promoting it to new users. MySQL AB owns the copyright to the MySQL source code, the MySQL logo and (registered) trademark, and this manual. See Section 1.4, “Overview of the MySQL Database Management System”.
The MySQL core values show our dedication to MySQL and Open Source.
These core values direct how MySQL AB works with the MySQL server software:
To be the best and the most widely used database in the world
To be available and affordable by all
To be easy to use
To be continuously improved while remaining fast and safe
To be fun to use and improve
To be free from bugs
These are the core values of the company MySQL AB and its employees:
We subscribe to the Open Source philosophy and support the Open Source community
We aim to be good citizens
We prefer partners that share our values and mindset
We answer email and provide support
We are a virtual company, networking with others
We work against software patents
The MySQL Web site (http://www.mysql.com/) provides the latest information about MySQL and MySQL AB.
By the way, the “AB” part of the company name is the acronym for the Swedish “aktiebolag,” or “stock company.” It translates to “MySQL, Inc.” In fact, MySQL, Inc. and MySQL GmbH are examples of MySQL AB subsidiaries. They are located in the United States and Germany, respectively.
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 mSQL
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 18, 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 (MyISAM)
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.
Data Types:
Many data types: signed/unsigned integers 1, 2, 3, 4, and 8
bytes long, FLOAT,
DOUBLE, CHAR,
VARCHAR, TEXT,
BLOB, DATE,
TIME, DATETIME,
TIMESTAMP, YEAR,
SET, 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
SELECT and WHERE clauses
of queries. For example:
mysql>SELECT CONCAT(first_name, ' ', last_name)->FROM citizen->WHERE income/dependents > 10000 AND age > 30;
Full support for SQL GROUP BY and
ORDER BY clauses. Support for group
functions (COUNT(), COUNT(DISTINCT
...), AVG(),
STD(), SUM(),
MAX(), MIN(), and
GROUP_CONCAT()).
Support for LEFT OUTER JOIN and
RIGHT OUTER JOIN with both standard SQL and
ODBC syntax.
Support for aliases on tables and columns as required by standard SQL.
DELETE, INSERT,
REPLACE, and UPDATE
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.
The MySQL-specific SHOW command can be used
to retrieve information about databases, database engines,
tables, and indexes.
The EXPLAIN command can be used to
determine how the optimizer resolves a query.
Function names do not clash with table or column names. For
example, 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.6, “Treatment of Reserved Words in MySQL”.
You can mix tables from different databases in the same query (as of MySQL 3.22).
Security:
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 (500 before
MySQL 4.1.2). An index may use a prefix of a column for
CHAR, VARCHAR,
BLOB, or TEXT column
types.
Connectivity:
Clients can connect to the MySQL server using TCP/IP sockets on any platform. On Windows systems in the NT family (NT, 2000, XP, or 2003), clients can connect using named pipes. On Unix systems, clients can connect using Unix domain socket files.
In MySQL versions 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
--protocol=memory option.
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 19, 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 19, 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 19, Connectors.
Localization:
The server can provide error messages to clients in many languages. See Section 5.9.2, “Setting the Error Message Language”.
Full support for several different character sets, including
latin1 (cp1252), german,
big5, ujis, and more.
For example, the Scandinavian characters
‘å’,
‘ä’ and
‘ö’ 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 MyISAM
tables. See Chapter 5, Database Administration.
All MySQL programs can be invoked with the
--help or -? 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:
Replication (Stable)
Large groups of servers using replication are in production use, with good results. Work on enhanced replication features is continuing.
InnoDB tables (Stable)
The InnoDB transactional storage engine has
been stable since version 3.23.49. InnoDB
is being used in large, heavy-load production systems.
BDB tables (Stable)
The Berkeley DB code is very stable, but we
are still improving the BDB transactional
storage engine interface in MySQL Server.
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.
The 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 |
| Solaris 9/10 | 16TB |
| 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 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 MyISAM
table with the SHOW TABLE STATUS statement or
with myisamchk -dv
tbl_name. See
Section 13.5.4, “SHOW Syntax”.
If you need a MyISAM table that is larger than
4GB and your operating system supports large files, the
CREATE TABLE statement supports
AVG_ROW_LENGTH and MAX_ROWS
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.2, “myisampack — Generate Compressed, Read-Only MyISAM Tables”.
MySQL includes a MERGE library that allows
you to handle a collection of MyISAM tables
that have identical structure as a single
MERGE table. See
Section 14.2, “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
the year 2037 for
TIMESTAMP values. For
DATE and DATETIME
values, dates through the year 9999 are
accepted.
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 column type can store
the years 0 and 1901 to
2155 in one byte and display them using two
or four digits. All two-digit years are considered to be in
the range 1970 to 2069,
which means that if you store 01 in a
YEAR column, MySQL Server treats it as
2001.
The following simple demonstration illustrates that MySQL Server
has no problems with DATE or
DATETIME values through the year 9999, and no
problems with TIMESTAMP values until after the
year 2030:
mysql>DROP TABLE IF EXISTS y2k;Query OK, 0 rows affected (0.00 sec) mysql>CREATE TABLE y2k (date DATE,->date_time DATETIME,->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 (2040,
9999) exceed the TIMESTAMP
maximum. The TIMESTAMP data type, which is used
to store the current time, supports values that range from
'1970-01-01 00:00:00' to '2030-01-01
00:00:00' on 32-bit machines (signed value). On 64-bit
machines, 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 00 or 99 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.
MaxDB is a heavy-duty enterprise database. The database management system is SAP-certified.
MaxDB is the new name of a database management system formerly called SAP DB. In 2003 SAP AG and MySQL AB joined a partnership and re-branded the database system to MaxDB. The development of MaxDB has continued since then as it was done before—through the SAP developer team.
MySQL AB cooperates closely with the MaxDB team at SAP around delivering improvements to the MaxDB product. Joint efforts include development of new native drivers to enable more efficient usage of MaxDB in the Open Source community, and improvement of documentation to expand the MaxDB user base. Interoperability features between MySQL and MaxDB database also are seen as important. For example, the new MaxDB Synchronization Manager supports data synchronization from MaxDB to MySQL.
The MaxDB database management system does not share a common code-base with the MySQL database management system. The MaxDB and MySQL database management systems are independent products provided by MySQL AB.
MySQL AB offers a complete portfolio of Professional Services for MaxDB.
MaxDB is an ANSI SQL-92 (entry level) compliant relational database management system (RDBMS) from SAP AG, that is delivered by MySQL AB as well. MaxDB fulfills the needs for enterprise usage: safety, scalability, high concurrency, and performance. It runs on all major operating systems. Over the years it has proven able to run SAP R/3 and terabytes of data in 24×7 operation.
The database development started in 1977 as a research project at the Technical University of Berlin. In the early 1980s it became a database product that subsequently was owned by Nixdorf, Siemens Nixdorf, Software AG, and today by SAP AG. Along the way, it has been named VDN, Reflex, Supra 2, DDB/4, Entire SQL-DB-Server, and ADABAS D. In 1997, SAP took over the software from software AG and renamed it to SAP DB. Since October 2000, SAP DB sources additionally were released as Open Source under the GNU General Public License (see Appendix J, GNU General Public License).
In 2003, SAP AG and MySQL AB formed a partnership and re-branded the database system to MaxDB.
The history of MaxDB goes back to SAP DB, SAP AG's DBMS. That is, MaxDB is a re-branded and enhanced version of SAP DB. For many years, MaxDB has been used for small, medium, and large installations of the mySAP Business Suite and other demanding SQL applications requiring an enterprise-class DBMS with regard to the number of users, the transactional workload, and the size of the database.
SAP DB was meant to provide an alternative to third-party database systems such as Oracle, Microsoft SQL Server, and DB2 by IBM. In October 2000, SAP AG released SAP DB under the GNU GPL license (see Appendix J, GNU General Public License), thus making it Open Source software.
Today, MaxDB is used in about 3,500 SAP customer installations worldwide. Moreover, the majority of all DBMS installations on Unix and Linux within SAP’s IT department rely on MaxDB. MaxDB is tuned toward heavy-duty online transaction processing (OLTP) with several thousand users and database sizes ranging from several hundred GB to multiple TB.
In 2003, SAP and MySQL concluded a partnership and development cooperation agreement. As a result, SAP's database system SAP DB has been delivered under the name of MaxDB by MySQL since the release of version 7.5 (November 2003).
Version 7.5 of MaxDB is a direct advancement of the SAP DB 7.4 code base. Therefore, the MaxDB software version 7.5 can be used as a direct upgrade of previous SAP DB versions starting 7.2.04 and higher.
The former SAP DB development team at SAP AG is responsible, now as before, for developing and supporting MaxDB. MySQL AB cooperates closely with the MaxDB team at SAP around delivering improvements to the MaxDB product, see Section 1.5, “Overview of the MaxDB Database Management System”. Both SAP AG and MySQL AB handle the sale and distribution of MaxDB. The advancement of MaxDB and the MySQL Server leverages synergies that benefit both product lines.
MaxDB is subjected to SAP AG's complete quality assurance process before it is shipped with SAP solutions or provided as a download from the MySQL site.
MaxDB is a heavy-duty, SAP-certified Open Source database for OLTP and OLAP usage which offers high reliability, availability, scalability, and a very comprehensive feature set. It is targeted for large mySAP Business Suite environments and other applications that require maximum enterprise-level database functionality and complements the MySQL database server.
MaxDB operates as a client/server product. It was developed to meet the needs of installations in OLTP and Data Warehouse/OLAP/Decision Support scenarios and offers these benefits:
Easy configuration and administration: GUI-based Installation Manager and Database Manager as single administration tools for DBMS operations
Around-the-clock operation, no planned downtimes, no permanent attendance required: Automatic space management, no need for reorganizations
Sophisticated backup and restore capabilities: Online and incremental backups, recovery wizard to guide you through the recovery scenario
Supports large number of users, database sizes in the terabytes, and demanding workloads: Proven reliability, performance, and scalability
High availability: Cluster support, standby configuration, hot standby configuration
MaxDB can be used under the same licenses available for the other products distributed by MySQL AB. Thus, MaxDB is available under the GNU General Public License, and a commercial license. For more information on licensing, see http://www.mysql.com/company/legal/licensing/.
MySQL AB offers MaxDB technical support to non-SAP customers. MaxDB support is available on various levels (Basic, Silver, and Gold), which expand from unlimited email/web-support to 24×7 phone support for business critical systems.
MySQL AB also offers Licenses and Support for MaxDB when used with SAP Applications, like SAP NetWeaver and mySAP Business Suite. For more information on licenses and support for your needs, please contact MySQL AB. (See http://www.mysql.com/company/contact/.)
Consulting and training services are available. MySQL gives classes on MaxDB at regular intervals. See http://www.mysql.com/training/ for a list of classes.
MaxDB is MySQL AB's SAP-certified database. The MaxDB database server complements the MySQL AB product portfolio. Some MaxDB features are not available on the MySQL database management server and vice versa.
The following list summarizes the main differences between MaxDB and MySQL; it is not complete.
MaxDB runs as a client/server system. MySQL can run as a client/server system or as an embedded system.
MaxDB might not run on all platforms supported by MySQL.
MaxDB uses a proprietary network protocol for client/server communication. MySQL uses either TCP/IP (with or without SSL encryption), sockets (under Unix-like systems), or named pipes or shared memory (under Windows NT-family systems).
MaxDB supports stored procedures and functions. MySQL 5.0 and up also supports stored procedures and function and functions. MaxDB supports programming of triggers through an SQL extension. MySQL 5.0 supports triggers. MaxDB contains a debugger for stored procedure languages, can cascade nested triggers, and supports multiple triggers per action and row.
MaxDB is distributed with user interfaces that are text-based, graphical, or Web-based. MySQL is distributed with text-based user interfaces only; graphical user interfaces (MySQL Query Browser, MySQL Administrator) are shipped separately from the main distributions. Web-based user interfaces for MySQL are offered by third parties.
MaxDB supports a number of programming interfaces that also are supported by MySQL. For developing with MaxDB, the MaxDB ODBC Driver, SQL Database Connectivity (SQLDBC), JDBC Driver, Perl and Python modules and a MaxDB PHP extension, which provides access to MySQL MaxDB databases using PHP, are available. Third Party Programming Interfaces: Support for OLE DB, ADO, DAO, RDO and .NET through ODBC. MaxDB supports embedded SQL with C/C++.
MaxDB includes administrative features that MySQL does not have: job scheduling by time, event, and alert, and sending messages to a database administrator on alert thresholds.
MaxDB and MySQL are independent database management servers. The interoperation of the systems is possible in a way that the systems can exchange their data. To exchange data between MaxDB and MySQL, you can use the import and export tools of the systems or the MaxDB Synchronization Manager. The import and export tools can be used to transfer data in an infrequent, manual fashion. The MaxDB Synchronization Manager offers faster, automatic data transfer capabilities.
The MaxDB Loader can be used to export data and object
definitions. The Loader can export data using MaxDB internal,
binary formats and text formats (CSV). Data exported from MaxDB in
text formats can be imported into MySQL using the
mysqlimport client program. To export MySQL
data, you can use either mysqldump to create
INSERT statements or SELECT ... INTO
OUTFILE to create a text file (CSV). Use the MaxDB
Loader to import the data files generated by MySQL.
Object definitions can be exchanged between the systems using
MaxDB Loader and the MySQL tool mysqldump. As
the SQL dialects of both systems differ slightly and MaxDB has
features currently not supported by MySQL like SQL constraints, we
recommend to hand-tune the definition files. The
mysqldump tool offers an option
--compatible=maxdb to produce output that is
compatible to MaxDB to make porting easier.
The MaxDB Synchronization Manager is available as part of MaxDB 7.6. The Synchronization Manager supports creation of asynchronous replication scenarios between several MaxDB instances. However, interoperability features also are planned, so that the Synchronization Manager supports replication to and from a MySQL server.
In the first release, the Synchronization Manager supports inserting data into MySQL. This means that initially only replication from MaxDB to MySQL is supported. In the course of 2005, exporting of data from a MySQL server to the Synchronization Manager will be added, thus adding support for MySQL to MaxDB replication scenarios.
The main page for MaxDB information is http://www.mysql.com/products/maxdb, which provides details about the features of the MaxDB database management systems and has pointers to available documentation.
The MySQL Reference Manual does not contain any MaxDB documentation other than the introduction given in this section. MaxDB has its own documentation, which is called the MaxDB library and is available at http://dev.mysql.com/doc/maxdb/index.html.
MySQL AB runs a community mailing list on MaxDB; see http://lists.mysql.com/maxdb. The list shows a vivid community discussion. Many of the core developers contribute to it. Product announcements are sent to the list.
A Web forum on MaxDB is available at http://forums.mysql.com/. The forum focuses on MaxDB questions not related to SAP applications.
This section provides a snapshot of the MySQL development roadmap, including major features implemented in or planned for various MySQL releases. The following sections provide information for each release series.
The current production release series is MySQL 5.0, which was declared stable for production use as of MySQL 5.0.15, released in October 2005. The previous production release series was MySQL 4.1, which was declared stable for production use as of MySQL 4.1.7, released in October 2004. “Production status” means that future 5.0 and 4.1 development is limited only to bugfixes. For the older MySQL 4.0 and 3.23 series, only critical bugfixes are made.
Active MySQL development currently is taking place in the MySQL 5.0 and 5.1 release series; and new features are being added only to the latter.
Before upgrading from one release series to the next, please see the notes at Section 2.10, “Upgrading MySQL”.
The most requested features and the versions in which they were implemented or are scheduled for implementation are summarized in the following table:
| Feature | MySQL Series |
| Foreign keys | 3.23 (for the InnoDB storage engine) |
| Unions | 4.0 |
| Subqueries | 4.1 |
| R-trees | 4.1 (for the MyISAM storage engine) |
| Stored procedures | 5.0 |
| Views | 5.0 |
| Cursors | 5.0 |
| XA transactions | 5.0 |
| Foreign keys | 5.2 (implemented in 3.23 for InnoDB) |
| Triggers | 5.0 and 5.1 |
| Partitioning | 5.1 |
| Row-Based Replication | 5.1 |
MySQL 4.0 is available for download at http://dev.mysql.com/ and from our mirrors. MySQL 4.0 has been tested by a large number of users and is in production use at many large sites.
Speed enhancements
MySQL 4.0 implemented a query cache that can give a major speed boost to applications with repetitive queries. See Section 5.12, “The MySQL Query Cache”.
MySQL 4.0 further increased the speed of MySQL Server
in a number of areas, such as bulk
INSERT statements, searching on
packed indexes, full-text searching (using
FULLTEXT indexes), and
COUNT(DISTINCT).
Introduction of Embedded MySQL Server
The Embedded Server library added in this release can easily be used to create standalone and embedded applications. The embedded server provides an alternative to using MySQL in a client/server environment. See Section 1.6.1.2, “The Embedded MySQL Server”.
InnoDB storage engine as standard
The InnoDB storage engine began to
be offered as a standard feature of the MySQL server.
This provided full support for ACID transactions,
foreign keys with cascading UPDATE
and DELETE, and row-level locking
as standard features. See Chapter 15, The InnoDB Storage Engine.
New functionality
The enhanced FULLTEXT search
capabilities of MySQL Server 4.0 enabled
FULLTEXT indexing of large text
masses with both binary and natural-language searching
logic. It became possible to customize minimal word
length and define your own stop word lists in most
human languages, enabling a broader class of
applications to be built with MySQL Server. See
Section 12.7, “Full-Text Search Functions”.
Standards compliance, portability, and migration
MySQL Server added support for the
UNION statement, a standard SQL
feature.
Starting with version 4.0, MySQL runs natively on Novell NetWare 6.0 and higher. See Section 2.6, “Installing MySQL on NetWare”.
Features to simplify migration from other database
systems to MySQL Server include TRUNCATE
TABLE (as in Oracle)
.
Internationalization
German-speaking users should note that MySQL 4.0 added
support for a new character set,
latin1_de, which ensures that words
with umlauts are sorted in the same order as in German
telephone books.
Usability enhancements
As of version 4.0, most mysqld
parameters (startup options) can be set without taking
down the server. This is a convenient feature for
database administrators. See
Section 13.5.3, “SET Syntax”.
Multiple-table DELETE and
UPDATE statements were added.
On Windows, symbolic link handling at the database
level was enabled by default. On Unix, the
MyISAM storage engine added support
for symbolic linking at the table level (and not just
the database level as before).
The addition of the
SQL_CALC_FOUND_ROWS and
FOUND_ROWS() functions made it
possible to find out the number of rows a
SELECT query that includes a
LIMIT clause would have returned
without that clause.
The news section of this manual includes a more in-depth list of MySQL 4.0 features. See Section D.2, “Changes in release 4.0.x (Recent; still supported)”.
The libmysqld embedded server library made
MySQL Server suitable for a wider range of applications. Using
this library, developers can embed MySQL Server into various
applications and electronics devices, where the end user has
no knowledge of there actually being an underlying database.
Embedded MySQL Server is ideal for use in Internet appliances,
public kiosks, turnkey hardware/software combination units,
high performance Internet servers, self-contained databases
distributed on CD-ROM, and so on.
The embedded MySQL library uses the same interface as the normal client library. See Section 18.1, “libmysqld, the Embedded MySQL Server Library”. Embedded MySQL is available under the same dual-licensing model as the MySQL Server; see http://www.mysql.com/company/legal/licensing/ for more information.
On Windows there are two different libraries:
libmysqld.lib | Dynamic library for threaded applications. |
mysqldemb.lib | Static library for not threaded applications. |
MySQL Server 4.0 laid the foundation for new features implemented in MySQL 4.1, such as subqueries and Unicode support, which were desired by many of our customers.
MySQL Server 4.1 is currently in production status, and binaries are available for download at http://dev.mysql.com/downloads/mysql/4.1.html. All binary releases pass our extensive test suite without any errors on the platforms on which we test. See Section D.1, “Changes in release 4.1.x (Production)”.
For those wishing to use the most recent development source for MySQL 4.1, we also make our BitKeeper repositories publicly available. See Section 2.8.3, “Installing from the Development Source Tree”.
This section lists features implemented in MySQL 4.1. Features that are available in MySQL 5.0 are described in Section 1.6.3, “What's New in MySQL 5.0”.
Support for subqueries and derived tables:
A “subquery” is a
SELECT statement nested within
another statement. A “derived table” (an
unnamed view) is a subquery in the
FROM clause of another statement.
See Section 13.2.8, “Subquery Syntax”.
Speed enhancements:
Faster binary client/server protocol with support for prepared statements and parameter binding. See Section 18.2.4, “C API Prepared Statements”.
BTREE indexing is supported for
HEAP tables, significantly
improving response time for non-exact searches.
Added functionality:
CREATE TABLE
allows
you to create, with a single statement, a new table
with a structure exactly like that of an existing
table.
tbl_name2 LIKE
tbl_name1
The MyISAM storage engine added
support for OpenGIS spatial types for storing
geographical data. See
Chapter 17, Spatial Extensions in MySQL.
Support was added for replication over SSL connections.
Support for a number of additional storage engines was implemented in the MySQL 4.1 release series:
The EXAMPLE storage engine is
a “stub” engine that serves as an
example in the MySQL source code for writing new
storage engines, and is primarily of interest to
developers. See
Section 14.5, “The EXAMPLE Storage Engine”.
NDB Cluster is the storage
engine used by MySQL Cluster to implement tables
that are partitioned over many computers. See
Chapter 16, MySQL Cluster.
The ARCHIVE storage engine is
used for storing large amounts of data without
indexes in a very small footprint. See
Section 14.6, “The ARCHIVE Storage Engine”.
The CSV storage engine stores
data in text files using comma-separated-values
format. See
Section 14.7, “The CSV Storage Engine”.
The BLACKHOLE storage engine
accepts but does not store data, and always
returns an empty result set. It is for use
primarily in replication. See
Section 14.8, “The BLACKHOLE Storage Engine”.
Note: These engine were implemented at different points in the development of MySQL 4.1. Please see the indicated sections for particulars in each case.
Standards compliance, portability, and migration:
The enhanced client/server protocol available beginning with MySQL 4.1.1 provides the ability to pass multiple warnings to the client, rather than only a single result, making it much easier to track problems that occur in operations such as bulk data loading.
SHOW WARNINGS shows warnings for
the last command. See Section 13.5.4.21, “SHOW WARNINGS Syntax”.
Internationalization and Localization:
To support applications that require the use of local
languages, the MySQL software added extensive Unicode
support through the utf8 and
ucs2 character sets.
Definition of character sets by column, table, and database. This allows for a high degree of flexibility in application design, particularly for multi-language Web sites. See Chapter 10, Character Set Support.
Per-connection time zones support, allowing individual clients to select their own time zones when necessary.
Usability enhancements:
The addition of a server-based HELP
command that can be used to get help information for
SQL statements. This information is always applicable
to the particular server version being used. Because
this information is available by issuing an SQL
statement, any client can access it. For example, the
help command of the
mysql command-line client has been
modified to have this capability.
The improved client/server protocol allows multiple statements to be issued with a single call, and for returning multiple result sets. See Section 18.2.9, “C API Handling of Multiple Query Execution”.
The syntax INSERT ... ON DUPLICATE KEY UPDATE
... was implemented. This allows you to
update an existing row if the insert would have caused
a duplicate value for a primary or unique index. See
Section 13.2.4, “INSERT Syntax”.
The aggregate function
GROUP_CONCAT(), added the
capability to concatenate column values from grouped
rows into a single result string. See
Section 12.10, “Functions and Modifiers for Use with GROUP BY Clauses”.
The News section of this manual includes a more in-depth list of MySQL 4.1 features. See Section D.1, “Changes in release 4.1.x (Production)”.
The following features are implemented in MySQL 5.0.
BIT Data
Type: Can be used to store numbers in binary
notation.
Cursors: Elementary support for server-side cursors.
Data Dictionary (Information
Schema): The introduction of the
INFORMATION_SCHEMA database in MySQL 5.0
provided a standards-compliant means for accessing the MySQL
Server's metadata, that is, data about the databases
(schemas) on the server and the objects which they contain.
Instance Manager: Can be used to start and stop the MySQL Server, even from a remote host.
Precision Math: MySQL 5.0 introduced stricter criteria for acceptance or rejection of data, and implemented a new library for fixed-point arithmetic. These contributed to a much higher degree of accuracy for mathematical operations and greater control over invalid values.
Storage Engines: Storage
engines added in MySQL 5.0 include
ARCHIVE and FEDERATED.
Stored Routines: Support for named stored procedures and stored functions was implemented in MySQL 5.0.
Strict Mode and Standard Error Handling: MySQL 5.0 added a strict mode where by it follows standard SQL in a number of ways in which it did not previously. Support for standard SQLSTATE error messages was also implemented.
Triggers: MySQL 5.0 added limited support for triggers.
VARCHAR Data
Type: The maximum effective length of a
VARCHAR column was increased to 65,532
bytes, and stripping of trailing whitespace was eliminated.
Views: MySQL 5.0 added support for named, updateable views.
For those wishing to take a look at the bleeding edge of MySQL development, we make our BitKeeper repository for MySQL publicly available. See Section 2.8.3, “Installing from the Development Source Tree”.
This section lists sources of additional information that you may find helpful, such as the MySQL mailing lists and user forums, and Internet Relay Chat.
This section introduces the MySQL mailing lists and provides guidelines as to how the lists should be used. When you subscribe to a mailing list, you receive all postings to the list as email messages. You can also send your own questions and answers to the list.
To subscribe to or unsubscribe from any of the mailing lists described in this section, visit http://lists.mysql.com/. For most of them, you can select the regular version of the list where you get individual messages, or a digest version where you get one large message per day.
Please do not send messages about subscribing or unsubscribing to any of the mailing lists, because such messages are distributed automatically to thousands of other users.
Your local site may have many subscribers to a MySQL mailing list.
If so, the site may have a local mailing list, so that messages
sent from lists.mysql.com to your site are
propagated to the local list. In such cases, please contact your
system administrator to be added to or dropped from the local
MySQL list.
If you wish to have traffic for a mailing list go to a separate
mailbox in your mail program, set up a filter based on the message
headers. You can use either the List-ID: or
Delivered-To: headers to identify list
messages.
The MySQL mailing lists are as follows:
announce
This list is for announcements of new versions of MySQL and related programs. This is a low-volume list to which all MySQL users should subscribe.
mysql
This is the main list for general MySQL discussion. Please note that some topics are better discussed on the more-specialized lists. If you post to the wrong list, you may not get an answer.
bugs
This list is for people who want to stay informed about issues reported since the last release of MySQL or who want to be actively involved in the process of bug hunting and fixing. See Section 1.8, “How to Report Bugs or Problems”.
internals
This list is for people who work on the MySQL code. This is also the forum for discussions on MySQL development and for posting patches.
mysqldoc
This list is for people who work on the MySQL documentation: people from MySQL AB, translators, and other community members.
benchmarks
This list is for anyone interested in performance issues. Discussions concentrate on database performance (not limited to MySQL), but also include broader categories such as performance of the kernel, filesystem, disk system, and so on.
packagers
This list is for discussions on packaging and distributing MySQL. This is the forum used by distribution maintainers to exchange ideas on packaging MySQL and on ensuring that MySQL looks and feels as similar as possible on all supported platforms and operating systems.
java
This list is for discussions about the MySQL server and Java. It is mostly used to discuss JDBC drivers such as MySQL Connector/J.
win32
This list is for all topics concerning the MySQL software on Microsoft operating systems, such as Windows 9x, Me, NT, 2000, XP, and 2003.
myodbc
This list is for all topics concerning connecting to the MySQL server with ODBC.
gui-tools
This list is for all topics concerning MySQL graphical user
interface tools such as MySQL Administrator
and MySQL Query Browser.
cluster
This list is for discussion of MySQL Cluster.
dotnet
This list is for discussion of the MySQL server and the .NET platform. It is mostly related to MySQL Connector/Net.
plusplus
This list is for all topics concerning programming with the C++ API for MySQL.
perl
This list is for all topics concerning Perl support for MySQL
with DBD::mysql.
If you're unable to get an answer to your questions from a MySQL mailing list or forum, one option is to purchase support from MySQL AB. This puts you in direct contact with MySQL developers.
The following table shows some MySQL mailing lists in languages other than English. These lists are not operated by MySQL AB.
<mysql-france-subscribe@yahoogroups.com>
A French mailing list.
A Korean mailing list. To subscribe, email subscribe
mysql your@email.address to this list.
<mysql-de-request@lists.4t2.com>
A German mailing list. To subscribe, email subscribe
mysql-de your@email.address to this list. You can
find information about this mailing list at
http://www.4t2.com/mysql/.
<mysql-br-request@listas.linkway.com.br>
A Portuguese mailing list. To subscribe, email
subscribe mysql-br your@email.address to
this list.
A Spanish mailing list. To subscribe, email subscribe
mysql your@email.address to this list.
Please don't post mail messages from your browser with HTML mode turned on. Many users don't read mail with a browser.
When you answer a question sent to a mailing list, if you consider your answer to have broad interest, you may want to post it to the list instead of replying directly to the individual who asked. Try to make your answer general enough that people other than the original poster may benefit from it. When you post to the list, please make sure that your answer is not a duplication of a previous answer.
Try to summarize the essential part of the question in your reply. Don't feel obliged to quote the entire original message.
When answers are sent to you individually and not to the mailing list, it is considered good etiquette to summarize the answers and send the summary to the mailing list so that others may have the benefit of responses you received that helped you solve your problem.
The forums at http://forums.mysql.com are an important community resource. Many forums are available, grouped into these general categories:
Migration
MySQL Usage
MySQL Connectors
Programming Languages
Tools
3rd-Party Applications
Storage Engines
MySQL Technology
SQL Standards
Business
In addition to the various MySQL mailing lists and forums, you can find experienced community people on Internet Relay Chat (IRC). These are the best networks/channels currently known to us:
freenode (see http://www.freenode.net/ for servers)
#mysql is primarily for MySQL questions,
but other database and general SQL questions are welcome.
Questions about PHP, Perl, or C in combination with MySQL are
also common.
If you are looking for IRC client software to connect to an IRC
network, take a look at xChat
(http://www.xchat.org/). X-Chat (GPL licensed) is
available for Unix as well as for Windows platforms (a free
Windows build of X-Chat is available at
http://www.silverex.org/download/).
Before posting a bug report about a problem, please try to verify that it is a bug and that it has not been reported already:
Start by searching the MySQL online manual at http://dev.mysql.com/doc/. We try to keep the manual up to date by updating it frequently with solutions to newly found problems. The change history (http://dev.mysql.com/doc/mysql/en/news.html) can be particularly useful since it is quite possible that a newer version contains a solution to your problem.
If you get a parse error for a SQL statement, please check your
syntax closely. If you can't find something wrong with it, it's
extremely likely that your current version of MySQL Server
doesn't support the syntax you are using. If you are using the
current version and the manual doesn't cover the syntax that you
are using, MySQL Server doesn't support your statement. In this
case, your options are to implement the syntax yourself or email
<licensing@mysql.com> and ask for an offer to
implement it.
If the manual covers the syntax you are using, but you have an older version of MySQL Server, you should check the MySQL change history to see when the syntax was implemented. In this case, you have the option of upgrading to a newer version of MySQL Server.
For solutions to some common problems, see Appendix A, Problems and Common Errors.
Search the bugs database at http://bugs.mysql.com/ to see whether the bug has been reported and fixed.
Search the MySQL mailing list archives at http://lists.mysql.com/. See Section 1.7.1, “MySQL Mailing Lists”.
You can also use http://www.mysql.com/search/ to search all the Web pages (including the manual) that are located at the MySQL AB Web site.
If you can't find an answer in the manual, the bugs database, or the mailing list archives, check with your local MySQL expert. If you still can't find an answer to your question, please use the following guidelines for reporting the bug.
The normal way to report bugs is to visit http://bugs.mysql.com/, which is the address for our bugs database. This database is public and can be browsed and searched by anyone. If you log in to the system, you can enter new reports. If you have no Web access, you can generate a bug report by using the mysqlbug script described at the end of this section.
All bugs posted in the bugs database at http://bugs.mysql.com/ are corrected or documented in the next MySQL release. If only minor code changes are needed to correct a problem, we may also post a patch that fixes the problem.
If you have found a sensitive security bug in MySQL, you can send
email to <security@mysql.com>.
To discuss problems with other users, you can use one of the MySQL mailing lists. Section 1.7.1, “MySQL Mailing Lists”.
Writing a good bug report takes patience, but doing it right the first time saves time both for us and for yourself. A good bug report, containing a full test case for the bug, makes it very likely that we will fix the bug in the next release. This section helps you write your report correctly so that you don't waste your time doing things that may not help us much or at all. Please read this section carefully and make sure that all the information described here is included in your report.
Preferably, you should test the problem using the latest production
or development version of MySQL Server before posting. Anyone should
be able to repeat the bug by just using mysql test <
script_file on your test case or by running the shell or
Perl script that you include in the bug report. Any bug that we are
able to repeat has a high chance of being fixed in the next MySQL
release.
It is most helpful when a good description of the problem is included in the bug report. That is, give a good example of everything you did that led to the problem and describe, in exact detail, the problem itself. The best reports are those that include a full example showing how to reproduce the bug or problem. See Section E.1.6, “Making a Test Case If You Experience Table Corruption”.
Remember that it is possible for us to respond to a report containing too much information, but not to one containing too little. People often omit facts because they think they know the cause of a problem and assume that some details don't matter. A good principle to follow is that if you are in doubt about stating something, state it. It is faster and less troublesome to write a couple more lines in your report than to wait longer for the answer if we must ask you to provide information that was missing from the initial report.
The most common errors made in bug reports are (a) not including the version number of the MySQL distribution that you use, and (b) not fully describing the platform on which the MySQL server is installed (including the platform type and version number). These are highly relevant pieces of information, and in 99 cases out of 100, the bug report is useless without them. Very often we get questions like, “Why doesn't this work for me?” Then we find that the feature requested wasn't implemented in that MySQL version, or that a bug described in a report has been fixed in newer MySQL versions. Errors often are platform-dependent. In such cases, it is next to impossible for us to fix anything without knowing the operating system and the version number of the platform.
If you compiled MySQL from source, remember also to provide information about your compiler if it is related to the problem. Often people find bugs in compilers and think the problem is MySQL-related. Most compilers are under development all the time and become better version by version. To determine whether your problem depends on your compiler, we need to know what compiler you used. Note that every compiling problem should be regarded as a bug and reported accordingly.
If a program produces an error message, it is very important to include the message in your report. If we try to search for something from the archives, it is better that the error message reported exactly matches the one that the program produces. (Even the lettercase should be observed.) It is best to copy and paste the entire error message into your report. You should never try to reproduce the message from memory.
If you have a problem with Connector/ODBC (MyODBC), please try to generate a trace file and send it with your report. See Section 19.1.1.9, “How to Report MyODBC Problems or Bugs”.
If your report includes long query output lines from test cases that
you run with the mysql command-line tool, you can
make the output more readable by using the
--vertical option or the \G
statement terminator. The EXPLAIN SELECT example
later in this section demonstrates the use of \G.
Please include the following information in your report:
The version number of the MySQL distribution you are using (for
example, MySQL 5.0.19). You can find out which version you are
running by executing mysqladmin version. The
mysqladmin program can be found in the
bin directory under your MySQL installation
directory.
The manufacturer and model of the machine on which you experience the problem.
The operating system name and version. If you work with Windows,
you can usually get the name and version number by
double-clicking your My Computer icon and pulling down the
“Help/About Windows” menu. For most Unix-like
operating systems, you can get this information by executing the
command uname -a.
Sometimes the amount of memory (real and virtual) is relevant. If in doubt, include these values.
If you are using a source distribution of the MySQL software, include the name and version number of the compiler that you used. If you have a binary distribution, include the distribution name.
If the problem occurs during compilation, include the exact error messages and also a few lines of context around the offending code in the file where the error occurs.
If mysqld died, you should also report the statement that crashed mysqld. You can usually get this information by running mysqld with query logging enabled, and then looking in the log after mysqld crashes See Section E.1.5, “Using Log Files to Find Cause of Errors in mysqld”.
If a database table is related to the problem, include the
output from the SHOW CREATE TABLE
statement in the bug report. This is a very easy way to get the
definition of any table in a database. The information helps us
create a situation matching the one that you have experienced.
db_name.tbl_name
For performance-related bugs or problems with
SELECT statements, you should always include
the output of EXPLAIN SELECT ..., and at
least the number of rows that the SELECT
statement produces. You should also include the output from
SHOW CREATE TABLE
for each table
that is involved. The more information you provide about your
situation, the more likely it is that someone can help you.
tbl_name
The following is an example of a very good bug report. The
statements are run using the mysql
command-line tool. Note the use of the \G
statement terminator for statements that would otherwise provide
very long output lines that are difficult to read.
mysql>SHOW VARIABLES;mysql>SHOW COLUMNS FROM ...\G<output from SHOW COLUMNS>mysql>EXPLAIN SELECT ...\G<output from EXPLAIN>mysql>FLUSH STATUS;mysql>SELECT ...;<A short version of the output from SELECT, including the time taken to run the query>mysql>SHOW STATUS;<output from SHOW STATUS>
If a bug or problem occurs while running mysqld, try to provide an input script that reproduces the anomaly. This script should include any necessary source files. The more closely the script can reproduce your situation, the better. If you can make a reproducible test case, you should upload it to be attached to the bug report.
If you can't provide a script, you should at least include the output from mysqladmin variables extended-status processlist in your report to provide some information on how your system is performing.
If you can't produce a test case with only a few rows, or if the
test table is too big to be included in the bug report (more
than 10 rows), you should dump your tables using
mysqldump and create a
README file that describes your problem.
Create a compressed archive of your files using
tar and gzip or
zip, and use FTP to transfer the archive to
ftp://ftp.mysql.com/pub/mysql/upload/. Then enter
the problem into our bugs database at
http://bugs.mysql.com/.
If you believe that the MySQL server produces a strange result from a statement, include not only the result, but also your opinion of what the result should be, and an explanation describing the basis for your opinion.
When you provide an example of the problem, it's better to use the table names, variable names, and so forth that exist in your actual situation than to come up with new names. The problem could be related to the name of a table or variable. These cases are rare, perhaps, but it is better to be safe than sorry. After all, it should be easier for you to provide an example that uses your actual situation, and it is by all means better for us. If you have data that you don't want to be visible to others in the bug report, you can use FTP to transfer it to ftp://ftp.mysql.com/pub/mysql/upload/. If the information is really top secret and you don't want to show it even to us, go ahead and provide an example using other names, but please regard this as the last choice.
Include all the options given to the relevant programs, if
possible. For example, indicate the options that you use when
you start the mysqld server, as well as the
options that you use to run any MySQL client programs. The
options to programs such as mysqld and
mysql, and to the
configure script, are often key to resolving
problems and are very relevant. It is never a bad idea to
include them. If your problem involves a program written in a
language such as Perl or PHP, please include the language
processor's version number, as well as the version for any
modules that the program uses. For example, if you have a Perl
script that uses the DBI and
DBD::mysql modules, include the version
numbers for Perl, DBI, and
DBD::mysql.
If your question is related to the privilege system, please
include the output of mysqlaccess, the output
of mysqladmin reload, and all the error
messages you get when trying to connect. When you test your
privileges, you should first run mysqlaccess.
After this, execute mysqladmin reload version
and try to connect with the program that gives you trouble.
mysqlaccess can be found in the
bin directory under your MySQL installation
directory.
If you have a patch for a bug, do include it. But don't assume that the patch is all we need, or that we can use it, if you don't provide some necessary information such as test cases showing the bug that your patch fixes. We might find problems with your patch or we might not understand it at all. If so, we can't use it.
If we can't verify the exact purpose of the patch, we won't use it. Test cases help us here. Show that the patch handles all the situations that may occur. If we find a borderline case (even a rare one) where the patch won't work, it may be useless.
Guesses about what the bug is, why it occurs, or what it depends on are usually wrong. Even the MySQL team can't guess such things without first using a debugger to determine the real cause of a bug.
Indicate in your bug report that you have checked the reference manual and mail archive so that others know you have tried to solve the problem yourself.
If the problem is that your data appears corrupt or you get
errors when you access a particular table, you should first
check your tables and then try to repair them with
CHECK TABLE and REPAIR
TABLE or with myisamchk. See
Chapter 5, Database Administration.
If you are running Windows, please verify the value of
lower_case_table_names using the
SHOW VARIABLES LIKE 'lower_case_table_names'
command.
If you often get corrupted tables, you should try to find out
when and why this happens. In this case, the error log in the
MySQL data directory may contain some information about what
happened. (This is the file with the .err
suffix in the name.) See Section 5.10.1, “The Error Log”. Please
include any relevant information from this file in your bug
report. Normally mysqld should
never crash a table if nothing killed it in
the middle of an update. If you can find the cause of
mysqld dying, it's much easier for us to
provide you with a fix for the problem. See
Section A.1, “How to Determine What Is Causing a Problem”.
If possible, download and install the most recent version of MySQL Server and check whether it solves your problem. All versions of the MySQL software are thoroughly tested and should work without problems. We believe in making everything as backward-compatible as possible, and you should be able to switch MySQL versions without difficulty. See Section 2.1.2, “Choosing Which MySQL Distribution to Install”.
If you are a support customer, please cross-post the bug report to
<mysql-support@mysql.com> for higher-priority
treatment, as well as to the appropriate mailing list to see whether
someone else has experienced (and perhaps solved) the problem.
If you have no Web access and cannot report a bug by visiting
http://bugs.mysql.com/, you can use the
mysqlbug script to generate a bug report (or a
report about any problem). mysqlbug helps you
generate a report by determining much of the following information
automatically, but if something important is missing, please include
it with your message. mysqlbug can be found in
the scripts directory (source distribution) and
in the bin directory under your MySQL
installation directory (binary distribution).
This section describes how MySQL relates to the ANSI/ISO SQL standards. MySQL Server has many extensions to the SQL standard, and here you can find out what they are and how to use them. You can also find information about functionality missing from MySQL Server, and how to work around some of the differences.
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” or “standard SQL” to mean the current version of the SQL Standard at any time.
One of our main goals with the product is to continue to work
toward compliance with the SQL standard, but without sacrificing
speed or reliability. We are not afraid to add extensions to SQL
or support for non-SQL features if this greatly increases the
usability of MySQL Server for a large segment of our user base.
The HANDLER interface is an example of this
strategy. See Section 13.2.3, “HANDLER Syntax”.
We continue to support transactional and non-transactional databases to satisfy both mission-critical 24/7 usage and heavy Web or logging usage.
MySQL Server was originally designed to work with medium-sized databases (10-100 million rows, or about 100MB per table) on small computer systems. Today MySQL Server handles terabyte-sized databases, but the code can also be compiled in a reduced version suitable for hand-held and embedded devices. The compact design of the MySQL server makes development in both directions possible without any conflicts in the source tree.
Currently, we are not targeting real-time support, although MySQL replication capabilities offer significant functionality.
In MySQL 4.1.2 in later, high-availability database clustering is
supported by the NDBCluster storage engine. See
Chapter 16, MySQL Cluster.
XML support is to be implemented in a future version of the database server.
Our aim is to support the full ANSI/ISO SQL standard, but without making concessions to speed and quality of the code.
ODBC levels 0-3.51.
The MySQL server can operate in different SQL modes, and can apply these modes differentially for different clients. This capability allows applications to tailor server operation to their own requirements.
SQL modes control aspects of server operation such as what SQL syntax MySQL should support and what kind of data validation checks it should perform. This makes it easier to use MySQL in different environments and to use MySQL together with other database servers.
You can set the default SQL mode by starting
mysqld with the
--sql-mode="
option. Beginning with MySQL 4.1, you can also change the mode
at runtime by setting the mode_value"sql_mode system
variable with a SET [SESSION|GLOBAL]
sql_mode='
statement.
mode_value'
For more information on setting the SQL mode, see Section 5.2.2, “The Server SQL Mode”.
You can tell mysqld to run in ANSI mode with
the --ansi startup option. Running the server
in ANSI mode is the same as starting it with the following
options:
--transaction-isolation=SERIALIZABLE --sql-mode=ANSI
As of MySQL 4.1.1, you can achieve the same effect at runtime by executing these two statements:
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET GLOBAL sql_mode = 'ANSI';
You can see that setting the sql_mode system
variable to 'ANSI' enables all SQL mode
options that are relevant for ANSI mode as follows:
mysql>SET GLOBAL sql_mode='ANSI';mysql>SELECT @@global.sql_mode;-> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ANSI'
Note that running the server in ANSI mode with
--ansi is not quite the same as setting the SQL
mode to 'ANSI'. The --ansi
option affects the SQL mode and also sets the transaction
isolation level. Setting the SQL mode to
'ANSI' has no effect on the isolation level.
See Section 5.2.1, “mysqld Command-Line Options”, and Section 1.9.2, “Selecting SQL Modes”.
MySQL Server supports some extensions that you probably won't find in other SQL DBMSs. Be warned that if you use them, your code won't be portable to other SQL servers. In some cases, you can write code that includes MySQL extensions, but is still portable, by using comments of the following form:
/*! MySQL-specific code */
In this case, MySQL Server parses and executes the code within
the comment as it would any other SQL statement, but other SQL
servers will ignore the extensions. For example, MySQL Server
recognizes the STRAIGHT_JOIN keyword in the
following statement, but other servers will not:
SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ...
If you add a version number after the
‘!’ character, the syntax within
the comment is executed only if the MySQL version is greater
than or equal to the specified version number. The
TEMPORARY keyword in the following comment is
executed only by servers from MySQL 3.23.02 or higher:
CREATE /*!32302 TEMPORARY */ TABLE t (a INT);
The following descriptions list MySQL extensions, organized by category.
Organization of data on disk
MySQL Server maps each database to a directory under the MySQL data directory, and maps tables within a database to filenames in the database directory. This has a few implications:
Database and table names are case sensitive in MySQL Server on operating systems that have case-sensitive filenames (such as most Unix systems). See Section 9.2.2, “Identifier Case Sensitivity”.
You can use standard system commands to back up, rename,
move, delete, and copy tables that are managed by the
MyISAM or ISAM
storage engines. For example, it is possible to rename a
MyISAM table by renaming the
.MYD, .MYI,
and .frm files to which the table
corresponds. (Nevertheless, it is preferable to use
RENAME TABLE or ALTER TABLE
… RENAME and let the server rename the
files.)
Database and table names cannot contain pathname separator
characters (‘/’,
‘\’).
General language syntax
By default, strings can be enclosed by either
‘"’ or
‘'’, not just by
‘'’. (If the
ANSI_QUOTES SQL mode is enabled,
strings can be enclosed only by
‘'’ and the server
interprets strings enclosed by
‘"’ as identifiers.)
Use of ‘\’ as an escape
character in strings.
In SQL statements, you can access tables from different
databases with the
db_name.tbl_name syntax. Some
SQL servers provide the same functionality but call this
User space. MySQL Server doesn't
support tablespaces such as used in statements like
this: CREATE TABLE ralph.my_table...IN
my_tablespace.
SQL statement syntax
The ANALYZE TABLE, CHECK
TABLE, OPTIMIZE TABLE, and
REPAIR TABLE statements.
The CREATE DATABASE, DROP
DATABASE, and ALTER
DATABASE statements. See
Section 13.1.3, “CREATE DATABASE Syntax”,
Section 13.1.6, “DROP DATABASE Syntax”, and
Section 13.1.1, “ALTER DATABASE Syntax”.
The DO statement.
EXPLAIN SELECT to obtain a
description of how tables are processed by the query
optimizer.
The FLUSH and
RESET statements.
The SET statement. See
Section 13.5.3, “SET Syntax”.
The SHOW statement. See
Section 13.5.4, “SHOW Syntax”.
Use of LOAD DATA INFILE. In many
cases, this syntax is compatible with Oracle's
LOAD DATA INFILE. See
Section 13.2.5, “LOAD DATA INFILE Syntax”.
Use of RENAME TABLE. See
Section 13.1.9, “RENAME TABLE Syntax”.
Use of REPLACE instead of
DELETE plus
INSERT. See
Section 13.2.6, “REPLACE Syntax”.
Use of CHANGE
,
col_nameDROP
, or
col_nameDROP INDEX, IGNORE
or RENAME in ALTER
TABLE statements. Use of multiple
ADD, ALTER,
DROP, or CHANGE
clauses in an ALTER TABLE statement.
See Section 13.1.2, “ALTER TABLE Syntax”.
Use of index names, indexes on a prefix of a column, and
use of INDEX or
KEY in CREATE
TABLE statements. See
Section 13.1.5, “CREATE TABLE Syntax”.
Use of TEMPORARY or IF NOT
EXISTS with CREATE TABLE.
Use of IF EXISTS with DROP
TABLE and DROP DATABASE.
The capability of dropping multiple tables with a single
DROP TABLE statement.
The ORDER BY and
LIMIT clauses of the
UPDATE and DELETE
statements.
INSERT INTO ... SET
syntax.
col_name = ...
The DELAYED clause of the
INSERT and REPLACE
statements.
The LOW_PRIORITY clause of the
INSERT, REPLACE,
DELETE, and UPDATE
statements.
Use of INTO OUTFILE or INTO
DUMPFILE in SELECT
statements. See Section 13.2.7, “SELECT Syntax”.
Options such as STRAIGHT_JOIN or
SQL_SMALL_RESULT in
SELECT statements.
You don't need to name all selected columns in the
GROUP BY clause. This gives better
performance for some very specific, but quite normal
queries. See
Section 12.10, “Functions and Modifiers for Use with GROUP BY Clauses”.
You can specify ASC and
DESC with GROUP
BY, not just with ORDER BY.
The ability to set variables in a statement with the
:= assignment operator:
mysql>SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg->FROM test_table;mysql>SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
Data types
The MEDIUMINT,
SET, and ENUM data
types, and the various BLOB and
TEXT data types.
The AUTO_INCREMENT,
BINARY, NULL,
UNSIGNED, and
ZEROFILL data type attributes.
Functions and operators
To make it easier for users who migrate from other SQL environments, MySQL Server supports aliases for many functions. For example, all string functions support both standard SQL syntax and ODBC syntax.
MySQL Server understands the || and
&& operators to mean logical
OR and AND, as in the C programming language. In MySQL
Server, || and OR
are synonyms, as are && and
AND. Because of this nice syntax,
MySQL Server doesn't support the standard SQL
|| operator for string concatenation;
use CONCAT() instead. Because
CONCAT() takes any number of
arguments, it's easy to convert use of the
|| operator to MySQL Server.
Use of COUNT(DISTINCT
where
value_list)value_list has more than one
element.
String comparisons are case-insensitive by default, with
sort ordering determined by the current character set
(cp1252 Latin1 by default). If you don't like this, you
should declare your columns with the
BINARY attribute or use the
BINARY cast, which causes comparisons
to be done using the underlying character code values
rather then a lexical ordering.
The % operator is a synonym for
MOD(). That is,
N %
MMOD(.
N,M)% is supported for C programmers and
for compatibility with PostgreSQL.
The =, <>,
<=,<,
>=,>,
<<,
>>,
<=>, AND,
OR, or LIKE
operators may be used in expressions in the output
column list (to the left of the FROM)
in SELECT statements. For example:
mysql> SELECT col1=1 AND col2=2 FROM my_table;
The LAST_INSERT_ID() function returns
the most recent AUTO_INCREMENT value.
See Section 12.9.3, “Information Functions”.
LIKE is allowed on numeric values.
The REGEXP and NOT
REGEXP extended regular expression operators.
CONCAT() or CHAR()
with one argument or more than two arguments. (In MySQL
Server, these functions can take a variable number of
arguments.)
The BIT_COUNT(),
CASE, ELT(),
FROM_DAYS(),
FORMAT(), IF(),
PASSWORD(),
ENCRYPT(), MD5(),
ENCODE(),
DECODE(),
PERIOD_ADD(),
PERIOD_DIFF(),
TO_DAYS(), and
WEEKDAY() functions.
Use of TRIM() to trim substrings.
Standard SQL supports removal of single characters only.
The GROUP BY functions
STD(), BIT_OR(),
BIT_AND(),
BIT_XOR(), and
GROUP_CONCAT(). See
Section 12.10, “Functions and Modifiers for Use with GROUP BY Clauses”.
For a prioritized list indicating when new extensions are added to MySQL Server, you should consult the online MySQL TODO list at http://dev.mysql.com/doc/mysql/en/TODO.html.
We try to make MySQL Server follow the ANSI SQL standard and the ODBC SQL standard, but MySQL Server performs operations differently in some cases:
For VARCHAR columns, trailing spaces are
removed when the value is stored. See
Section A.8, “Known Issues in MySQL”.
In some cases, CHAR columns are silently
converted to VARCHAR columns when you
define a table or alter its structure. See
Section 13.1.5.1, “Silent Column Specification Changes”.
Privileges for a table are not automatically revoked when
you delete a table. You must explicitly issue a
REVOKE statement to revoke privileges for
a table. See Section 13.5.1.2, “GRANT and REVOKE Syntax”.
The CAST() function does not support cast
to REAL or BIGINT. See
Section 12.8, “Cast Functions and Operators”.
MySQL 4.1 and up supports subqueries and derived tables. A
“subquery” is a SELECT
statement nested within another statement. A “derived
table” (an unnamed view) is a subquery in the
FROM clause of another statement. See
Section 13.2.8, “Subquery Syntax”.
For MySQL versions older than 4.1, most subqueries can be rewritten using joins or other methods. See Section 13.2.8.11, “Rewriting Subqueries as Joins for Earlier MySQL Versions”, for examples that show how to do this.
MySQL Server doesn't support the SELECT … INTO
TABLE Sybase SQL extension. Instead, MySQL Server
supports the INSERT INTO … SELECT
standard SQL syntax, which is basically the same thing. See
Section 13.2.4.1, “INSERT ... SELECT Syntax”. For example:
INSERT INTO tbl_temp2 (fld_id)
SELECT tbl_temp1.fld_order_id
FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
Alternatively, you can use SELECT … INTO
OUTFILE or CREATE TABLE …
SELECT.
MySQL Server (version 3.23-max and all versions 4.0 and above)
supports transactions with the InnoDB and
BDB transactional storage engines.
InnoDB provides full
ACID compliance. MySQL Cluster is also a
transaction-safe storage engine. See
Chapter 14, Storage Engines and Table Types.
The other non-transactional storage engines in MySQL Server
(such as MyISAM) follow a different
paradigm for data integrity called “atomic
operations.” In transactional terms,
MyISAM tables effectively always operate in
AUTOCOMMIT=1 mode. Atomic operations often
offer comparable integrity with higher performance.
Because MySQL Server supports both paradigms, you can decide whether your applications are best served by the speed of atomic operations or the use of transactional features. This choice can be made on a per-table basis.
As noted, the trade-off for transactional versus
non-transactional table types lies mostly in performance.
Transactional tables have significantly higher memory and disk
space requirements, and more CPU overhead. On the other hand,
transactional table types such as InnoDB
also offer many significant features. MySQL Server's modular
design allows the concurrent use of different storage engines
to suit different requirements and deliver optimum performance
in all situations.
But how do you use the features of MySQL Server to maintain
rigorous integrity even with the non-transactional
MyISAM tables, and how do these features
compare with the transactional table types?
If your applications are written in a way that is
dependent on being able to call
ROLLBACK rather than
COMMIT in critical situations,
transactions are more convenient. Transactions also ensure
that unfinished updates or corrupting activities are not
committed to the database; the server is given the
opportunity to do an automatic rollback and your database
is saved.
If you use non-transactional tables, MySQL Server in almost all cases allows you to resolve potential problems by including simple checks before updates and by running simple scripts that check the databases for inconsistencies and automatically repair or warn if such an inconsistency occurs. Note that just by using the MySQL log or even adding one extra log, you can normally fix tables perfectly with no data integrity loss.
More often than not, critical transactional updates can be
rewritten to be atomic. Generally speaking, all integrity
problems that transactions solve can be done with
LOCK TABLES or atomic updates, ensuring
that there are no automatic aborts from the server, which
is a common problem with transactional database systems.
To be safe with MySQL Server, whether or not you use transactional tables, you only need to have backups and have binary logging turned on. When that is true, you can recover from any situation that you could with any other transactional database system. It is always good to have backups, regardless of which database system you use.
The transactional paradigm has its benefits and its drawbacks. Many users and application developers depend on the ease with which they can code around problems where an abort appears to be necessary, or is necessary. However, even if you are new to the atomic operations paradigm, or more familiar with transactions, do consider the speed benefit that non-transactional tables can offer on the order of three to five times the speed of the fastest and most optimally tuned transactional tables.
In situations where integrity is of highest importance, MySQL
Server offers transaction-level reliability and integrity even
for non-transactional tables. If you lock tables with
LOCK TABLES, all updates stall until
integrity checks are made. If you obtain a READ
LOCAL lock (as opposed to a write lock) for a table
that allows concurrent inserts at the end of the table, reads
are allowed, as are inserts by other clients. The newly
inserted records are not be seen by the client that has the
read lock until it releases the lock. With INSERT
DELAYED, you can write inserts that go into a local
queue until the locks are released, without having the client
wait for the insert to complete. See
Section 13.2.4.2, “INSERT DELAYED Syntax”.
“Atomic,” in the sense that we mean it, is nothing magical. It only means that you can be sure that while each specific update is running, no other user can interfere with it, and there can never be an automatic rollback (which can happen with transactional tables if you are not very careful). MySQL Server also guarantees that there are no dirty reads.
Following are some techniques for working with non-transactional tables:
Loops that need transactions normally can be coded with
the help of LOCK TABLES, and you don't
need cursors to update records on the fly.
To avoid using ROLLBACK, you can employ
the following strategy:
Use LOCK TABLES to lock all the
tables you want to access.
Test the conditions that must be true before performing the update.
Update if the conditions are satisfied.
Use UNLOCK TABLES to release your
locks.
This is usually a much faster method than using transactions with possible rollbacks, although not always. The only situation this solution doesn't handle is when someone kills the threads in the middle of an update. In that case, all locks are released but some of the updates may not have been executed.
You can also use functions to update records in a single operation. You can get a very efficient application by using the following techniques:
Modify columns relative to their current value.
Update only those columns that actually have changed.
For example, when we are updating customer information, we
update only the customer data that has changed and test
only that none of the changed data, or data that depends
on the changed data, has changed compared to the original
row. The test for changed data is done with the
WHERE clause in the
UPDATE statement. If the record wasn't
updated, we give the client a message: “Some of the
data you have changed has been changed by another
user.” Then we show the old row versus the new row
in a window so that the user can decide which version of
the customer record to use.
This gives us something that is similar to column locking
but is actually even better because we only update some of
the columns, using values that are relative to their
current values. This means that typical
UPDATE statements look something like
these:
UPDATE tablename SET pay_back=pay_back+125;
UPDATE customer
SET
customer_date='current_date',
address='new address',
phone='new phone',
money_owed_to_us=money_owed_to_us-125
WHERE
customer_id=id AND address='old address' AND phone='old phone';
This is very efficient and works even if another client
has changed the values in the pay_back
or money_owed_to_us columns.
In many cases, users have wanted LOCK
TABLES or ROLLBACK for the
purpose of managing unique identifiers. This can be
handled much more efficiently without locking or rolling
back by using an AUTO_INCREMENT column
and either the LAST_INSERT_ID() SQL
function or the mysql_insert_id() C API
function. See Section 12.9.3, “Information Functions”, and
Section 18.2.3.35, “mysql_insert_id()”.
You can generally code around the need for row-level
locking. Some situations really do need it, and
InnoDB tables support row-level
locking. Otherwise, with MyISAM tables,
you can use a flag column in the table and do something
like the following:
UPDATE tbl_name SET row_flag=1 WHERE id=ID;
MySQL returns 1 for the number of
affected rows if the row was found and
row_flag wasn't 1 in
the original row. You can think of this as though MySQL
Server changed the preceding statement to:
UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;
Stored procedures and functions are implemented beginning with MySQL 5.0.
Basic trigger functionality is implemented beginning with MySQL 5.0.2, with further development planned for MySQL 5.1.
In MySQL Server 3.23.44 and up, the InnoDB
storage engine supports checking of foreign key constraints,
including CASCADE, ON
DELETE, and ON UPDATE. See
Section 15.7.4, “FOREIGN KEY Constraints”.
For storage engines other than InnoDB,
MySQL Server parses the FOREIGN KEY syntax
in CREATE TABLE statements, but does not
use or store it. In the future, the implementation will be
extended to store this information in the table specification
file so that it may be retrieved by
mysqldump and ODBC. At a later stage,
foreign key constraints will be implemented for
MyISAM tables as well.
Foreign key enforcement offers several benefits to database developers:
Assuming proper design of the relationships, foreign key constraints make it more difficult for a programmer to introduce an inconsistency into the database.
Centralized checking of constraints by the database server makes it unnecessary to perform these checks on the application side. This eliminates the possibility that different applications may not all check the constraints in the same way.
Using cascading updates and deletes can simplify the application code.
Properly designed foreign key rules aid in documenting relationships between tables.
Do keep in mind that these benefits come at the cost of additional overhead for the database server to perform the necessary checks. Additional checking by the server affects performance, which for some applications may be sufficiently undesirable as to be avoided if possible. (Some major commercial applications have coded the foreign key logic at the application level for this reason.)
MySQL gives database developers the choice of which approach
to use. If you don't need foreign keys and want to avoid the
overhead associated with enforcing referential integrity, you
can choose another storage engine instead, such as
MyISAM. (For example, the
MyISAM storage engine offers very fast
performance for applications that perform only
INSERT and SELECT
operations. In this case, the table has no holes in the middle
and the inserts can be performed concurrently with retrievals.
See Section 7.3.2, “Table Locking Issues”.)
If you choose not to take advantage of referential integrity checks, keep the following considerations in mind:
In the absence of server-side foreign key relationship checking, the application itself must handle relationship issues. For example, it must take care to insert rows into tables in the proper order, and to avoid creating orphaned child records. It must also be able to recover from errors that occur in the middle of multiple-record insert operations.
If ON DELETE is the only referential
integrity capability an application needs, you can achieve
a similar effect as of MySQL Server 4.0 by using
multiple-table DELETE statements to
delete rows from many tables with a single statement. See
Section 13.2.1, “DELETE Syntax”.
A workaround for the lack of ON DELETE
is to add the appropriate DELETE
statements to your application when you delete records
from a table that has a foreign key. In practice, this is
often as quick as using foreign keys and is more portable.
Be aware that the use of foreign keys can sometimes lead to problems:
Foreign key support addresses many referential integrity issues, but it is still necessary to design key relationships carefully to avoid circular rules or incorrect combinations of cascading deletes.
It is not uncommon for a DBA to create a topology of
relationships that makes it difficult to restore
individual tables from a backup. (MySQL alleviates this
difficulty by allowing you to temporarily disable foreign
key checks when reloading a table that depends on other
tables. See
Section 15.7.4, “FOREIGN KEY Constraints”. As of
MySQL 4.1.1, mysqldump generates dump
files that take advantage of this capability automatically
when they are reloaded.)
Note that foreign keys in SQL are used to check and enforce
referential integrity, not to join tables. If you want to get
results from multiple tables from a SELECT
statement, you do this by performing a join between them:
SELECT * FROM t1, t2 WHERE t1.id = t2.id;
See Section 13.2.7.1, “JOIN Syntax”, and
Section 3.6.6, “Using Foreign Keys”.
The FOREIGN KEY syntax without ON
DELETE ... is often used by ODBC applications to
produce automatic WHERE clauses.
Views (including updatable views) are implemented beginning with MySQL Server 5.0.1.
Views are useful for allowing users to access a set of relations (tables) as if it were a single table, and limiting their access to just that. Views can also be used to restrict access to rows (a subset of a particular table). For access control to columns, you can also use the sophisticated privilege system in MySQL Server. See Section 5.6, “The MySQL Access Privilege System”.
In designing an implementation of views, our ambitious goal, as much as is possible within the confines of SQL, has been full compliance with “Codd's Rule #6” for relational database systems: “All views that are theoretically updatable, should in practice also be updatable.”
Standard SQL uses the C syntax /* this is a comment
*/ for comments, and MySQL Server supports this
syntax as well. MySQL also support extensions to this syntax
that allow MySQL-specific SQL to be embedded in the comment,
as described in Section 9.5, “Comment Syntax”.
Standard SQL uses ‘--’ as a
start-comment sequence. MySQL Server uses
‘#’ as the start comment
character. MySQL Server 3.23.3 and up also supports a variant
of the ‘--’ comment style. That
is, the ‘--’ start-comment
sequence must be followed by a space (or by a control
character such as a newline). The space is required to prevent
problems with automatically generated SQL queries that use
constructs such as the following, where we automatically
insert the value of the payment for
!payment!:
UPDATE account SET credit=credit-!payment!
Consider about what happens if payment has
a negative value such as -1:
UPDATE account SET credit=credit--1
credit--1 is a legal expression in SQL, but
‘--’ is interpreted as the
start of a comment, part of the expression is discarded. The
result is a statement that has a completely different meaning
than intended:
UPDATE account SET credit=credit
The statement produces no change in value at all! This
illustrates that allowing comments to start with
‘--’ can have serious
consequences.
Using our implementation of require a following space for
‘--’ to be recognized as a
start-comment sequence in MySQL Server 3.23.3 and up,
credit--1 is actually safe.
Another safe feature is that the mysql
command-line client ignores lines that start with
‘--’.
The following information is relevant only if you are running a MySQL version earlier than 3.23.3:
If you have an SQL script in a text file that contains
‘--’ comments, you should use
the replace utility as follows to convert
the comments to use ‘#’
characters before executing the script:
shell>replace " --" " #" < text-file-with-funny-comments.sql \| mysqldb_name
That is safer than executing the script in the usual way:
shell> mysql db_name < text-file-with-funny-comments.sql
You can also edit the script file “in place” to
change the ‘--’ comments to
‘#’ comments:
shell> replace " --" " #" -- text-file-with-funny-comments.sql
Change them back with this command:
shell> replace " #" " --" -- text-file-with-funny-comments.sql
MySQL allows you to work both with transactional tables that allow rollback and with non-transactional tables that do not. Because of this, constraint handling is a bit different in MySQL than in other DBMSs. We must handle the case when you have inserted or updated a lot of rows in a non-transactional table for which changes cannot be rolled back when an error occurs.
The basic philosophy is that MySQL Server tries to produce an error for anything that it can detect while parsing a statement to be executed, and tries to recover from any errors that occur while executing the statement. We do this in most cases.
The options MySQL has when an error occurs are to stop the statement in the middle or to recover as well as possible from the problem and continue. By default, the server follows the latter course. This means, for example, that the server may coerce illegal values to the closest legal values.
The following sections describe how MySQL Server handles different types of constraints.
Normally, an error occurs when you try to
INSERT or UPDATE a row
that causes a primary key, unique key, or foreign key
violation. If you are using a transactional storage engine
such as InnoDB, MySQL automatically rolls
back the statement. If you are using a non-transactional
storage engine, MySQL stops processing the statement at the
row for which the error occurred and leaves any remaining rows
unprocessed.
If you want to ignore such key violations, MySQL supports an
IGNORE keyword for
INSERT and UPDATE. In
this case, MySQL ignores any key violations and continues
processing with the next row. See Section 13.2.4, “INSERT Syntax”,
and Section 13.2.10, “UPDATE Syntax”.
You can get information about the number of rows actually
inserted or updated with the mysql_info() C
API function. In MySQL 4.1 and up, you also can use the
SHOW WARNINGS statement. See
Section 18.2.3.33, “mysql_info()”, and
Section 13.5.4.21, “SHOW WARNINGS Syntax”.
Currently, only InnoDB tables support
foreign keys. See
Section 15.7.4, “FOREIGN KEY Constraints”. (Foreign key
support in MyISAM tables is scheduled for
implementation in MySQL 5.2. See Section 1.6, “MySQL Development Roadmap”.)
Through version 4.1, MySQL is forgiving of illegal or improper
data values and coerces them to legal values for data entry.
When you insert an “incorrect” value into a
column, such as a NULL into a NOT
NULL column or a too-large numeric value into a
numeric column, MySQL sets the column to the “best
possible value” instead of producing an error. The
following rules describe in more detail how this works:
If you try to store an out of range value into a numeric column, MySQL Server instead stores zero, the smallest possible value, or the largest possible value, whichever is closest to the invalid value. column.
For strings, MySQL stores either the empty string or as much of the string as can be stored in the column.
If you try to store a string that doesn't start with a number into a numeric column, MySQL Server stores 0.
Invalid values for ENUM and
SET columns ae handled as described in
Section 1.9.6.3, “ENUM and SET Constraints”.
MySQL allows you to store certain incorrect date values
into DATE and
DATETIME columns (such as
'2000-02-31' or
'2000-02-00'). The idea is that it's
not the job of the SQL server to validate dates. If MySQL
can store a date value and retrieve exactly the same
value, MySQL stores it as given. If the date is totally
wrong (outside the server's ability to store it), the
special “zero” date value
'0000-00-00' is stored in the column
instead.
If you try to store NULL into a column
that doesn't take NULL values, an error
occurs for single-row INSERT
statements. For multiple-row INSERT
statements or for INSERT INTO ...
SELECT statements, MySQL Server stores the
implicit default value for the column data type. In
general, this is 0 for numeric types,
the empty string ('') for string types,
and the “zero” value for date and time types.
Implicit default values are discussed in
Section 13.1.5, “CREATE TABLE Syntax”.
If an INSERT statement specifies no
value for a column, MySQL inserts its default value if the
column definition includes an explicit
DEFAULT clause. If the definition has
no such DEFAULT clause, MySQL inserts
the implicit default value for the column data type.
The reason for using the preceding rules is that we can't check these conditions until the statement has begun executing. We can't just roll back if we encounter a problem after updating a few rows, because the storage engine may not support rollback. The option of terminating the statement is not that good; in this case, the update would be “half done,” which is probably the worst possible scenario. In this case, it's better to “do the best you can” and then continue as if nothing happened.
ENUM and SET columns
provide an efficient way to define columns that can contain
only a given set of values. See Section 11.4.4, “The ENUM Type”, and
Section 11.4.5, “The SET Type”. However, in MySQL 4.1 and earlier,
ENUM and SET columns do
not provide true constraints on entry of invalid data:
ENUM columns always have a default
value. If you specify no default value, then it is
NULL for columns that can have
NULL, otherwise it is the first
enumeration value in the column definition.
If you insert an incorrect value into an
ENUM column or if you force a value
into an ENUM column with
IGNORE, it is set to the reserved
enumeration value of 0, which is
displayed as an empty string in string context.
If you insert an incorrect value into a
SET column, the incorrect value is
ignored. For example, if the column can contain the values
'a', 'b', and
'c', an attempt to assign
'a,x,b,y' results in a value of
'a,b'.
Table of Contents
This chapter describes how to obtain and install MySQL:
Determine whether your platform is supported. Please note that not all supported systems are equally good for running MySQL on them. On some it is much more robust and efficient than others. See Section 2.1.1, “Operating Systems Supported by MySQL”, for details.
Choose which distribution to install. Several versions of MySQL are available, and most are available in several distribution formats. You can choose from pre-packaged distributions containing binary (precompiled) programs or source code. When in doubt, use a binary distribution. We also provide public access to our current source tree for those who want to see our most recent developments and help us test new code. To determine which version and type of distribution you should use, see Section 2.1.2, “Choosing Which MySQL Distribution to Install”.
Download the distribution that you want to
install. For a list of sites from which you can
obtain MySQL, see Section 2.1.3, “How to Get MySQL”. You can
verify the integrity of the distribution using the instructions
in Section 2.1.4, “Verifying Package Integrity Using MD5 Checksums or GnuPG”.
Install the distribution. To install MySQL from a binary distribution, use the instructions in Section 2.2, “Standard MySQL Installation Using a Binary Distribution”. To install MySQL from a source distribution or from the current development source tree, use the instructions in Section 2.8, “MySQL Installation Using a Source Distribution”.
Note: If you plan to upgrade an existing version of MySQL to a newer version rather than installing MySQL for the first time, see Section 2.10, “Upgrading MySQL”, for information about upgrade procedures and about issues that you should consider before upgrading.
If you encounter installation difficulties, see Section 2.12, “Operating System-Specific Notes”, for information on solving problems for particular platforms.
Perform any necessary post-installation setup. After installing MySQL, read Section 2.9, “Post-Installation Setup and Testing”. This section contains important information about making sure the MySQL server is working properly. It also describes how to secure the initial MySQL user accounts, which have no passwords until you assign passwords. The section applies whether you install MySQL using a binary or source distribution.
If you want to run the MySQL benchmark scripts, Perl support for MySQL must be available. See Section 2.13, “Perl Installation Notes”.
Before installing MySQL, you should do the following:
Determine whether or not MySQL runs on your platform.
Choose a distribution to install.
Download the distribution and verify its integrity.
This section contains the information necessary to carry out these steps. After doing so, you can use the instructions in later sections of the chapter to install the distribution that you choose.
This section lists the operating systems on which you can expect to be able to run MySQL.
We use GNU Autoconf, so it is possible to port MySQL to all modern systems that have a C++ compiler and a working implementation of POSIX threads. (Thread support is needed for the server. To compile only the client code, the only requirement is a C++ compiler.) We use and develop the software ourselves primarily on Linux (SuSE and Red Hat), FreeBSD, and Sun Solaris (versions 8 and 9).
MySQL has been reported to compile successfully on the following combinations of operating system and thread package. Note that for many operating systems, native thread support works only in the latest versions.
AIX 4.x, 5.x with native threads. See Section 2.12.5.3, “IBM-AIX notes”.
Amiga.
BSDI 2.x with the MIT-pthreads package. See Section 2.12.4.4, “BSD/OS Version 2.x Notes”.
BSDI 3.0, 3.1 and 4.x with native threads. See Section 2.12.4.4, “BSD/OS Version 2.x Notes”.
Digital Unix 4.x with native threads. See Section 2.12.5.5, “Alpha-DEC-UNIX Notes (Tru64)”.
FreeBSD 2.x with the MIT-pthreads package. See Section 2.12.4.1, “FreeBSD Notes”.
FreeBSD 3.x and 4.x with native threads. See Section 2.12.4.1, “FreeBSD Notes”.
FreeBSD 4.x with LinuxThreads. See Section 2.12.4.1, “FreeBSD Notes”.
HP-UX 10.20 with the DCE threads or the MIT-pthreads package. See Section 2.12.5.1, “HP-UX Version 10.20 Notes”.
HP-UX 11.x with the native threads. See Section 2.12.5.2, “HP-UX Version 11.x Notes”.
Linux 2.0+ with LinuxThreads 0.7.1+ or
glibc 2.0.7+ for various CPU
architectures. See Section 2.12.1, “Linux Notes”.
Mac OS X. See Section 2.12.2, “Mac OS X Notes”.
NetBSD 1.3/1.4 Intel and NetBSD 1.3 Alpha (requires GNU make). See Section 2.12.4.2, “NetBSD Notes”.
Novell NetWare 6.0. See Section 2.6, “Installing MySQL on NetWare”.
OpenBSD > 2.5 with native threads. OpenBSD < 2.5 with the MIT-pthreads package. See Section 2.12.4.3, “OpenBSD 2.5 Notes”.
OS/2 Warp 3, FixPack 29 and OS/2 Warp 4, FixPack 4. See Section 2.12.6, “OS/2 Notes”.
SCO OpenServer 5.0.X with a recent port of the FSU Pthreads package. See Section 2.12.5.8, “SCO UNIX and OpenServer 5.0.x Notes”.
SCO UnixWare 7.1.x. See Section 2.12.5.9, “SCO UnixWare 7.1.x and OpenUNIX 8.0.0 Notes”.
SCO Openserver 6.0.x. See Section 2.12.5.10, “SCO OpenServer 6.0.x Notes”.
SGI Irix 6.x with native threads. See Section 2.12.5.7, “SGI Irix Notes”.
Solaris 2.5 and above with native threads on SPARC and x86. See Section 2.12.3, “Solaris Notes”.
SunOS 4.x with the MIT-pthreads package. See Section 2.12.3, “Solaris Notes”.
Tru64 Unix. See Section 2.12.5.5, “Alpha-DEC-UNIX Notes (Tru64)”.
Windows 9x, Me, NT, 2000, XP, and 2003. See Section 2.3, “Installing MySQL on Windows”.
Not all platforms are equally well-suited for running MySQL. How well a certain platform is suited for a high-load mission-critical MySQL server is determined by the following factors:
General stability of the thread library. A platform may have an excellent reputation otherwise, but MySQL is only as stable as the thread library it calls, even if everything else is perfect.
The capability of the kernel and the thread library to take advantage of symmetric multi-processor (SMP) systems. In other words, when a process creates a thread, it should be possible for that thread to run on a different CPU than the original process.
The capability of the kernel and the thread library to run
many threads that acquire and release a mutex over a short
critical region frequently without excessive context
switches. If the implementation of
pthread_mutex_lock() is too anxious to
yield CPU time, this hurts MySQL tremendously. If this issue
is not taken care of, adding extra CPUs actually makes MySQL
slower.
General filesystem stability and performance.
If your tables are big, the ability of the filesystem to deal with large files at all and to deal with them efficiently.
Our level of expertise here at MySQL AB with the platform. If we know a platform well, we enable platform-specific optimizations and fixes at compile time. We can also provide advice on configuring your system optimally for MySQL.
The amount of testing we have done internally for similar configurations.
The number of users that have successfully run MySQL on the platform in similar configurations. If this number is high, the chances of encountering platform-specific surprises are much smaller.
Based on the preceding criteria, the best platforms for running
MySQL at this point are x86 with SuSE Linux using a 2.4 kernel,
and ReiserFS (or any similar Linux distribution) and SPARC with
Solaris (2.7-9). FreeBSD comes third, but we really hope it
joins the top club once the thread library is improved. We also
hope that at some point we is able to include into the top
category all other platforms on which MySQL currently compiles
and runs okay, but not quite with the same level of stability
and performance. This requires some effort on our part in
cooperation with the developers of the operating system and
library components that MySQL depends on. If you are interested
in improving one of those components, are in a position to
influence its development, and need more detailed instructions
on what MySQL needs to run better, send an email message to the
MySQL internals mailing list. See
Section 1.7.1, “MySQL Mailing Lists”.
Please note that the purpose of the preceding comparison is not to say that one operating system is better or worse than another in general. We are talking only about choosing an OS for the specific purpose of running MySQL. With this in mind, the result of this comparison would be different if we considered more factors. In some cases, the reason one OS is better than the other could simply be that we have been able to put more effort into testing and optimizing for a particular platform. We are just stating our observations to help you decide which platform to use for running MySQL.
When preparing to install MySQL, you should decide which version to use. MySQL development occurs in several release series, and you can pick the one that best fits your needs. After deciding which version to install, you can choose a distribution format. Releases are available in binary or source format.
The first decision to make is whether you want to use a production (stable) release or a development release. In the MySQL development process, multiple release series co-exist, each at a different stage of maturity:
MySQL 5.0 is the newest development release series and is under very active development for new features. Alpha releases have been issued to allow more widespread testing.
MySQL 4.1 is the current stable (production-quality) release series. New releases are issued for bugfixes. No new features are added that could diminish the code stability.
MySQL 4.0 is the previous stable (production-quality) release series. New releases are issued for bugfixes. No new features are added that could diminish the code stability.
MySQL 3.23 is the old stable (production-quality) release series. This series is retired, so new releases are issued only to fix critical bugs.
We do not believe in a complete freeze, as this also leaves out bugfixes and things that “must be done.” “Somewhat frozen” means that we may add small things that “almost surely do not affect anything that's currently working.” Naturally, relevant bugfixes from an earlier series propagate to later series.
Normally, if you are beginning to use MySQL for the first time or trying to port it to some system for which there is no binary distribution, we recommend going with the production release series. Currently this is MySQL 4.1. All MySQL releases, even those from development series, are checked with the MySQL benchmarks and an extensive test suite before being issued.
If you are running an old system and want to upgrade, but do not want to take the chance of having a non-seamless upgrade, you should upgrade to the latest version in the same release series you are using (where only the last part of the version number is newer than yours). We have tried to fix only fatal bugs and make small, relatively safe changes to that version.
If you want to use new features not present in the production release series, you can use a version from a development series. Note that development releases are not as stable as production releases.
If you want to use the very latest sources containing all current patches and bugfixes, you can use one of our BitKeeper repositories. These are not “releases” as such, but are available as previews of the code on which future releases are based.
The MySQL naming scheme uses release names that consist of
three numbers and a suffix; for example,
mysql-4.1.2-alpha. The numbers within the
release name are interpreted like this:
The first number (4) is the major
version and also describes the file format. All version 4
releases have the same file format.
The second number (1) is the release
level. Taken together, the major version and release level
constitute the release series number.
The third number (2) is the version
number within the release series. This is incremented for
each new release. Usually you want the latest version for
the series you have chosen.
For each minor update, the last number in the version string is incremented. When there are major new features or minor incompatibilities with previous versions, the second number in the version string is incremented. When the file format changes, the first number is increased.
Release names also include a suffix to indicates the stability level of the release. Releases within a series progress through a set of suffixes to indicate how the stability level improves. The possible suffixes are:
alpha indicates that the release
contains some large section of new code that hasn't been
100% tested. Known bugs should be documented in the News
section. See Appendix D, MySQL Change History. There are also new
commands and extensions in most alpha releases. Active
development that may involve major code changes can occur
in an alpha release, but everything is tested before
issuing a release.
beta means that we are feature complete
and that all new code has been tested. No major new
features that could cause corruption in old code are
added. There should be no known critical bugs. A version
changes from alpha to beta when there have not been any
reported fatal bugs within an alpha version for at least a
month and we have no plans to add any features that could
make any old command unreliable.
All API's, extern visible structures and columns for SQL commands will not change during future beta, release candidate, or production releases.
rc is a release candidate; that is, a
beta that has been around a while and seems to work fine.
Only minor fixes are added. (A release candidate is what
formerly was known as a gamma release.)
If there is no suffix, it means that the version has been run for a while at many different sites with no reports of critical repeatable bugs other than platform-specific bugs. Only critical bugfixes are applied to the release. This is what we call a production (stable) or `General Availability' (GA) release.
MySQL uses a naming scheme that is slightly different from most other products. In general, it is relatively safe to use any version that has been out for a couple of weeks without being replaced with a new version within the release series.
All releases of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Because the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better.
All releases have been tested at least with:
An internal test suite
The mysql-test directory contains an
extensive set of test cases. We run these tests for
virtually every server binary. See
Section 20.1.2, “MySQL Test Suite”, for more information
about this test suite.
The MySQL benchmark suite
This suite runs a range of common queries. It is also a test to see whether the latest batch of optimizations actually made the code faster. See Section 7.1.4, “The MySQL Benchmark Suite”.
The crash-me test
This test tries to determine what features the database supports and what its capabilities and limitations are. See Section 7.1.4, “The MySQL Benchmark Suite”.
Another test is that we use the newest MySQL version in our internal production environment, on at least one machine. We have more than 100GB of data to work with.
After choosing which version of MySQL to install, you should decide whether to use a binary distribution or a source distribution. In most cases, you should probably use a binary distribution, if one exists for your platform. Binary distributions are available in native format for many platforms, such as RPM files for Linux or DMG package installers for Mac OS X. Distributions also are available as Zip archives or compressed tar files.
Reasons to choose a binary distribution include the following:
Binary distributions generally are easier to install than source distributions.
To satisfy different user requirements, we provide two different binary versions: one compiled with the non-transactional storage engines (a small, fast binary), and one configured with the most important extended options like transaction-safe tables. Both versions are compiled from the same source distribution. All native MySQL clients can connect to servers from either MySQL version.
The extended MySQL binary distribution is marked with the
-max suffix and is configured with the
same options as mysqld-max. See
Section 5.1.2, “The mysqld-max Extended MySQL Server”.
If you want to use the MySQL-Max RPM,
you must first install the standard
MySQL-server RPM.
Under some circumstances, you may be better off installing MySQL from a source distribution:
You want to install MySQL at some explicit location. The standard binary distributions are “ready to run” at any place, but you may want to have even more flexibility to place MySQL components where you want.
You want to configure mysqld with some extra features that are not included in the standard binary distributions. Here is a list of the most common extra options that you may want to use:
--with-innodb (default for MySQL 4.0
and up)
--with-berkeley-db (not available on
all platforms)
--with-raid
--with-libwrap
--with-named-z-libs (this is done for
some of the binaries)
--with-debug[=
full]
You want to configure mysqld without some features that are included in the standard binary distributions. For example, distributions normally are compiled with support for all character sets. If you want a smaller MySQL server, you can recompile it with support for only the character sets you need.
You have a special compiler (such as
pgcc) or want to use compiler options
that are better optimized for your processor. Binary
distributions are compiled with options that should work
on a variety of processors from the same processor family.
You want to use the latest sources from one of the BitKeeper repositories to have access to all current bugfixes. For example, if you have found a bug and reported it to the MySQL development team, the bugfix is committed to the source repository and you can access it there. The bugfix does not appear in a release until a release actually is issued.
You want to read (or modify) the C and C++ code that makes up MySQL. For this purpose, you should get a source distribution, because the source code is always the ultimate manual.
Source distributions contain more tests and examples than binary distributions.
MySQL is evolving quite rapidly here at MySQL AB and we want to share new developments with other MySQL users. We try to make a release when we have very useful features that others seem to have a need for.
We also try to help out users who request features that are easy to implement. We take note of what our licensed users want to have, and we especially take note of what our support customers want and try to help them out.
No one has to download a new release. The News section tells you if the new release has something you really want. See Appendix D, MySQL Change History.
We use the following policy when updating MySQL:
Releases are issued within each series. For each release, the last number in the version is one more than the previous release within the same series.
Production (stable) releases are meant to appear about 1-2 times a year. However, if small bugs are found, a release with only bugfixes is issued.
Working releases/bugfixes to old releases are meant to appear about every 4-8 weeks.
Binary distributions for some platforms are made by us for major releases. Other people may make binary distributions for other systems, but probably less frequently.
We make fixes available as soon as we have identified and corrected small or non-critical but annoying bugs. The fixes are available immediately from our public BitKeeper repositories, and will be included in the next release.
If by any chance a fatal bug is found in a release, we make a new release as soon as possible. (We would like other companies to do this, too!)
We put a lot of time and effort into making our releases bug-free. We haven't released a single MySQL version with any known “fatal” repeatable bugs. (A “fatal” bug is something that crashes MySQL under normal usage, produces incorrect answers for normal queries, or has a security problem.)
We have documented all open problems, bugs, and issues that are dependent on design decisions. See Section A.8, “Known Issues in MySQL”.
Our aim is to fix everything that is fixable without risk of making a stable MySQL version less stable. In certain cases, this means we can fix an issue in the development versions, but not in the stable (production) version. Naturally, we document such issues so that users are aware of them.
Here is a description of how our build process works:
We monitor bugs from our customer support list, the bugs database at http://bugs.mysql.com/, and the MySQL external mailing lists.
All reported bugs for live versions are entered into the bugs database.
When we fix a bug, we always try to make a test case for it and include it into our test system to ensure that the bug can never recur without being detected. (About 90% of all fixed bugs have a test case.)
We create test cases for all new features we add to MySQL.
Before we start to build a new MySQL release, we ensure that all reported repeatable bugs for the MySQL version (3.23.x, 4.0.x, and so forth) are fixed. If something is impossible to fix (due to some internal design decision in MySQL), we document this in the manual. See Section A.8, “Known Issues in MySQL”.
We do a build on all platforms for which we support binaries (15+ platforms) and run our test suite and benchmark suite on all of them.
We do not publish a binary for a platform for which the test or benchmark suite fails. If the problem is due to a general error in the source, we fix it and do the build plus tests on all systems again from scratch.
The build and test process takes 2-3 days. If we receive a report regarding a fatal bug during this process (for example, one that causes a core dump), we fix the problem and restart the build process.
After publishing the binaries on
http://dev.mysql.com/, we send out an
announcement message to the mysql and
announce mailing lists. See
Section 1.7.1, “MySQL Mailing Lists”. The announcement message
contains a list of all changes to the release and any
known problems with the release. The Known Problems
section in the release notes has been needed for only a
handful of releases.
To quickly give our users access to the latest MySQL features, we do a new MySQL release every 4-8 weeks. Source code snapshots are built daily and are available at http://downloads.mysql.com/snapshots.php.
If, despite our best efforts, we get any bug reports after
the release is done that there was something critically
wrong with the build on a specific platform, we fix it at
once and build a new 'a' release for
that platform. Thanks to our large user base, problems are
found quickly.
Our track record for making stable releases is quite good.
In the last 150 releases, we had to do a new build for
fewer than 10 releases. In three of these cases, the bug
was a faulty glibc library on one of
our build machines that took us a long time to track down.
As a service of MySQL AB, we provide a set of binary distributions of MySQL that are compiled on systems at our site or on systems where supporters of MySQL kindly have given us access to their machines.
In addition to the binaries provided in platform-specific
package formats, we offer binary distributions for a number of
platforms in the form of compressed tar
files (.tar.gz files). See
Section 2.2, “Standard MySQL Installation Using a Binary Distribution”.
For Windows distributions, see Section 2.3, “Installing MySQL on Windows”.
These distributions are generated using the script
Build-tools/Do-compile, which compiles the
source code and creates the binary tar.gz
archive using
scripts/make_binary_distribution.
These binaries are configured and built with the following
compilers and options. This information can also be obtained
by looking at the variables COMP_ENV_INFO
and CONFIGURE_LINE inside the script
bin/mysqlbug of every binary
tar file distribution.
The following binaries are built on MySQL AB development systems:
Linux 2.4.xx x86 with gcc 2.95.3:
CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc
CXXFLAGS="-O2 -mcpu=pentiumpro -felide-constructors"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.x x86 with icc (Intel C++ Compiler 8.1 or later releases):
CC=icc CXX=icpc CFLAGS="-O3 -unroll2 -ip -mp
-no-gcc -restrict" CXXFLAGS="-O3 -unroll2 -ip -mp -no-gcc
-restrict" ./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static --with-embedded-server
--with-innodb
Note that versions 8.1 and newer of the Intel compiler
have separate drivers for 'pure' C
(icc) and C++
(icpc); if you use
icc version 8.0 or older for building
MySQL, you will need to set CXX=icc.
Linux 2.4.xx Intel Itanium 2 with ecc (Intel C++ Itanium Compiler 7.0):
CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline"
CXX=ecc CXXFLAGS="-O2 -tpp2 -ip -nolib_inline" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client
--enable-local-infile
Linux 2.4.xx Intel Itanium with ecc (Intel C++ Itanium Compiler 7.0):
CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile
Linux 2.4.xx alpha with ccc (Compaq C
V6.2-505 / Compaq C++ V6.3-006):
CC=ccc CFLAGS="-fast -arch generic" CXX=cxx
CXXFLAGS="-fast -arch generic -noexceptions -nortti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-mysqld-ldflags=-non_shared
--with-client-ldflags=-non_shared
--disable-shared
Linux 2.x.xx ppc with gcc 2.95.4:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
Linux 2.4.xx s390 with gcc 2.95.3:
CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2
-felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared --with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.xx x86_64 (AMD64) with gcc 3.2.1:
CXX=gcc ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
Sun Solaris 8 x86 with gcc 3.2.3:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
Sun Solaris 8 SPARC with gcc 3.2:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-z-libs=no --with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 8 SPARC 64-bit with gcc 3.2:
CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -m64 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 9 SPARC with gcc 2.95.3:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 9 SPARC with cc-5.0 (Sun
Forte 5.0):
CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa
-xstrconst -mt -D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt
-D_FORTEC_ -xarch=v9" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=no
--enable-thread-safe-client --disable-shared
IBM AIX 4.3.2 ppc with gcc 3.2.3:
CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared
IBM AIX 4.3.3 ppc with xlC_r (IBM
Visual Age C/C++ 6.0):
CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2
-qmaxmem=8192" CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict
-qoptimize=2 -qmaxmem=8192" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-innodb
IBM AIX 5.1.0 ppc with gcc 3.3:
CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared
IBM AIX 5.2.0 ppc with xlC_r (IBM
Visual Age C/C++ 6.0):
CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2
-qmaxmem=8192" CXX=xlC_r CXXFLAGS="-ma -O2 -qstrict
-qoptimize=2 -qmaxmem=8192" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-embedded-server
--with-innodb
HP-UX 10.20 pa-risc1.1 with gcc 3.1:
CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC"
CXX=gcc CXXFLAGS="-DHPUX -I/opt/dce /include
-felide-constructors -fno-exceptions -fno-rtti -O3 -fPIC"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-pthread
--with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC
--disable-shared
HP-UX 11.00 pa-risc with aCC (HP ANSI
C++ B3910B A.03.50):
CC=cc CXX=aCC CFLAGS=+DAportable
CXXFLAGS=+DAportable ./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
HP-UX 11.11 pa-risc2.0 64bit with aCC
(HP ANSI C++ B3910B A.03.33):
CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
HP-UX 11.11 pa-risc2.0 32bit with aCC
(HP ANSI C++ B3910B A.03.33):
CC=cc CXX=aCC CFLAGS="+DAportable"
CXXFLAGS="+DAportable" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
HP-UX 11.22 ia64 64bit with aCC (HP
aC++/ANSI C B3910B A.05.50):
CC=cc CXX=aCC CFLAGS="+DD64 +DSitanium2"
CXXFLAGS="+DD64 +DSitanium2" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
Apple Mac OS X 10.2 powerpc with gcc 3.1:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
FreeBSD 4.7 i386 with gcc 2.95.4:
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=not-used
--disable-shared
FreeBSD 4.7 i386 using LinuxThreads with gcc 2.95.4:
CFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98
-D_REENTRANT -D_THREAD_SAFE
-I/usr/local/include/pthread/linuxthreads"
CXXFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98
-D_REENTRANT -D_THREAD_SAFE
-I/usr/local/include/pthread/linuxthreads" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--enable-thread-safe-client --enable-local-infile
--enable-assembler
--with-named-thread-libs="-DHAVE_GLIBC2_STYLE_GETHOSTBYNAME_R
-D_THREAD_SAFE -I /usr/local/include/pthread/linuxthreads
-L/usr/local/lib -llthread -llgcc_r" --disable-shared
--with-embedded-server --with-innodb
QNX Neutrino 6.2.1 i386 with gcc 2.95.3qnx-nto 20010315:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
The following binaries are built on third-party systems kindly provided to MySQL AB by other users. These are provided only as a courtesy; MySQL AB does not have full control over these systems, so we can provide only limited support for the binaries built on them.
SCO Unix 3.2v5.0.7 i386 with gcc 2.95.3:
CFLAGS="-O3 -mpentium" LDFLAGS=-static CXX=gcc
CXXFLAGS="-O3 -mpentium -felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared
SCO UnixWare 7.1.4 i386 with CC 3.2:
CC=cc CFLAGS="-O" CXX=CC ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared --with-readline
SCO OpenServer 6.0.0 i386 with CC 3.2:
CC=cc CFLAGS="-O" CXX=CC ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared --with-readline
Compaq Tru64 OSF/1 V5.1 732 alpha with
cc/cxx (Compaq C V6.3-029i / DIGITAL
C++ V6.1-027):
CC="cc -pthread" CFLAGS="-O4 -ansi_alias
-ansi_args -fast -inline speed -speculate all" CXX="cxx
-pthread" CXXFLAGS="-O4 -ansi_alias -fast -inline speed
-speculate all -noexceptions -nortti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
--disable-shared
--with-mysqld-ldflags=-all-static
SGI Irix 6.5 IP32 with gcc 3.0.1:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared
FreeBSD/sparc64 5.0 with gcc 3.2.1:
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
The following compile options have been used for binary packages that MySQL AB provided in the past. These binaries no longer are being updated, but the compile options are listed here for reference purposes.
Linux 2.2.xx SPARC with egcs 1.1.2:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--disable-shared
Linux 2.2.x with x686 with gcc 2.95.2:
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3
-mpentiumpro -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--enable-assembler --with-mysqld-ldflags=-all-static
--disable-shared --with-extra-charsets=complex
SunOS 4.1.4 2 sun4c with gcc 2.7.2.1:
CC=gcc CXX=gcc CXXFLAGS="-O3
-felide-constructors" ./configure
--prefix=/usr/local/mysql --disable-shared
--with-extra-charsets=complex --enable-assembler
SunOS 5.5.1 (and above) sun4u with egcs 1.0.3a or 2.90.27 or
gcc 2.95.2 and newer: CC=gcc
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex --enable-assembler
SunOS 5.6 i86pc with gcc 2.8.1:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex
BSDI BSD/OS 3.1 i386 with gcc 2.7.2.1:
CC=gcc CXX=gcc CXXFLAGS=-O ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
BSDI BSD/OS 2.1 i386 with gcc 2.7.2:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
AIX 4.2 with gcc 2.7.2.2:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
Anyone who has more optimal options for any of the preceding
configurations listed can always mail them to the MySQL
internals mailing list. See
Section 1.7.1, “MySQL Mailing Lists”.
RPM distributions prior to MySQL 3.22 are user-contributed. Beginning with MySQL 3.22, RPM distributions are generated by MySQL AB.
If you want to compile a debug version of MySQL, you should
add --with-debug or
--with-debug=full to the preceding
configure commands and remove any
-fomit-frame-pointer options.
Check the MySQL downloads page (http://dev.mysql.com/downloads/) for information about the current version and for downloading instructions. For a complete up-to-date list of MySQL download mirror sites, see http://dev.mysql.com/downloads/mirrors.html. There you can also find information about becoming a MySQL mirror site and how to report a bad or out-of-date mirror.
Our main mirror is located at http://mirrors.sunsite.dk/mysql/.
After you have downloaded the MySQL package that suits your needs and before you attempt to install it, you should make sure that it is intact and has not been tampered with. MySQL AB offers three means of integrity checking:
MD5 checksums
Cryptographic signatures using GnuPG, the
GNU Privacy Guard
For RPM packages, the built-in RPM integrity verification mechanism
The following sections describe how to use these methods.
If you notice that the MD5 checksum or GPG signatures do not
match, first try to download the respective package one more
time, perhaps from another mirror site. If you repeatedly cannot
successfully verify the integrity of the package, please notify
us about such incidents, including the full package name and the
download site you have been using, at
<webmaster@mysql.com> or
<build@mysql.com>. Do not report downloading
problems using the bug-reporting system.
After you have downloaded a MySQL package, you should make
sure that its MD5 checksum matches the one provided on the
MySQL download pages. Each package has an individual checksum
that you can verify with the following command, where
package_name is the name of the package you
downloaded:
shell> md5sum package_name
Example:
shell> md5sum mysql-standard-4.0.17-pc-linux-i686.tar.gz
60f5fe969d61c8f82e4f7f62657e1f06 mysql-standard-4.0.17-pc-linux-i686.tar.gz
You should verify that the resulting checksum (the string of hexadecimal digits) matches the one displayed on the download page immediately below the respective package.
Note: Make sure to verify the
checksum of the archive file
(for example, the .zip or
.tar.gz file) and not of the files that are
contained inside of the archive!
Note that not all operating systems support the
md5sum command. On some, it is simply
called md5 and others do not ship it at
all. On Linux, it is part of the GNU Text
Utilities package, which is available for a wide
range of platforms. You can download the source code from
http://www.gnu.org/software/textutils/ as well.
If you have OpenSSL installed, you can also
use the command openssl md5 package_name
instead. A DOS/Windows implementation of the
md5 command line utility is available from
http://www.fourmilab.ch/md5/. A graphical MD5
checking tool is winMd5Sum, which can be
obtained from
http://www.nullriver.com/index/products/winmd5sum.
Another method of verifying the integrity and authenticity of a package is to use cryptographic signatures. This is more reliable than using MD5 checksums, but requires more work.
Beginning with MySQL 4.0.10 (February 2003), MySQL AB started
signing downloadable packages with GnuPG
(GNU Privacy Guard).
GnuPG is an Open Source alternative to the
very well-known Pretty Good Privacy
(PGP) by Phil Zimmermann. See
http://www.gnupg.org/ for more information
about GnuPG and how to obtain and install
it on your system. Most Linux distributions ship with
GnuPG installed by default. For more
information about OpenPGP, see
http://www.openpgp.org/.
To verify the signature for a specific package, you first need
to obtain a copy of MySQL AB's public GPG build key. You can
download the key from
http://www.keyserver.net/. The key that you
want to obtain is named build@mysql.com.
Alternatively, you can cut and paste the key directly from the
following text:
Key ID:
pub 1024D/5072E1F5 2003-02-03
MySQL Package signing key (www.mysql.com) <build@mysql.com>
Fingerprint: A4A9 4068 76FC BD3C 4567 70C8 8C71 8D3B 5072 E1F5
Public Key (ASCII-armored):
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3
RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ
fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3
BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW
hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV
K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE
kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI
QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep
rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj
a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv
bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ
cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q
zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu
cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ
YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J
Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l
xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi
Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE
7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm
Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p
/1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq
a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf
anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW
I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu
QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92
6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ
Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A
n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ==
=YJkx
-----END PGP PUBLIC KEY BLOCK-----
You can import the build key into your personal public GPG
keyring by using gpg --import. For example,
if you save the key in a file named
mysql_pubkey.asc, the import command
looks like this:
shell> gpg --import mysql_pubkey.asc
See the GPG documentation for more information on how to work with public keys.
After you have downloaded and imported the public build key,
download your desired MySQL package and the corresponding
signature, which also is available from the download page. The
signature file has the same name as the distribution file with
an .asc extension. For example:
| Distribution file | mysql-standard-4.0.17-pc-linux-i686.tar.gz |
| Signature file | mysql-standard-4.0.17-pc-linux-i686.tar.gz.asc |
Make sure that both files are stored in the same directory and then run the following command to verify the signature for the distribution file:
shell> gpg --verify package_name.asc
Example:
shell> gpg --verify mysql-standard-4.0.17-pc-linux-i686.tar.gz.asc
gpg: Warning: using insecure memory!
gpg: Signature made Mon 03 Feb 2003 08:50:39 PM MET
using DSA key ID 5072E1F5
gpg: Good signature from
"MySQL Package signing key (www.mysql.com) <build@mysql.com>"
The Good signature message indicates that
everything is all right. You can ignore the insecure
memory warning.
For RPM packages, there is no separate signature. RPM packages have a built-in GPG signature and MD5 checksum. You can verify a package by running the following command:
shell> rpm --checksig package_name.rpm
Example:
shell> rpm --checksig MySQL-server-4.0.10-0.i386.rpm
MySQL-server-4.0.10-0.i386.rpm: md5 gpg OK
Note: If you are using RPM
4.1 and it complains about (GPG) NOT OK (MISSING
KEYS: GPG#5072e1f5), even though you have imported
the MySQL public build key into your own GPG keyring, you need
to import the key into the RPM keyring first. RPM 4.1 no
longer uses your personal GPG keyring (or GPG itself). Rather,
it maintains its own keyring because it is a system-wide
application and a user's GPG public keyring is a user-specific
file. To import the MySQL public key into the RPM keyring,
first obtain the key as described in the previous section.
Then use rpm --import to import the key.
For example, if you have the public key stored in a file named
mysql_pubkey.asc, import it using this
command:
shell> rpm --import mysql_pubkey.asc
If you need to obtain the MySQL public key, see
Section 2.1.4.2, “Signature Checking Using GnuPG”.
This section describes the default layout of the directories created by installing binary or source distributions provided by MySQL AB. If you install a distribution provided by another vendor, some other layout might be used.
On Windows, the default installation directory is
C:\mysql. With MySQL version 4.1.5 and
higher, this has changed to C:\Program
Files\MySQL\MySQL Server 4.1, where 4.1 is the major
version of the installation. The folder has the following
subdirectories:
| Directory | Contents of Directory |
bin | Client programs and the mysqld server |
data | Log files, databases |
Docs | Documentation |
examples | Example programs and scripts |
include | Include (header) files |
lib | Libraries |
scripts | Utility scripts |
share | Error message files |
Installations created from Linux RPM distributions result in files under the following system directories:
| Directory | Contents of Directory |
/usr/bin | Client programs and scripts |
/usr/sbin | The mysqld server |
/var/lib/mysql | Log files, databases |
/usr/share/doc/packages | Documentation |
/usr/include/mysql | Include (header) files |
/usr/lib/mysql | Libraries |
/usr/share/mysql | Error message and character set files |
/usr/share/sql-bench | Benchmarks |
On Unix, a tar file binary distribution is
installed by unpacking it at the installation location you
choose (typically /usr/local/mysql) and
creates the following directories in that location:
| Directory | Contents of Directory |
bin | Client programs and the mysqld server |
data | Log files, databases |
docs | Documentation, ChangeLog |
include | Include (header) files |
lib | Libraries |
scripts | mysql_install_db |
share/mysql | Error message files |
sql-bench | Benchmarks |
A source distribution is installed after you configure and
compile it. By default, the installation step installs files
under /usr/local, in the following
subdirectories:
| Directory | Contents of Directory |
bin | Client programs and scripts |
include/mysql | Include (header) files |
info | Documentation in Info format |
lib/mysql | Libraries |
libexec | The mysqld server |
share/mysql | Error message files |
sql-bench | Benchmarks and crash-me test |
var | Databases and log files |
Within an installation directory, the layout of a source installation differs from that of a binary installation in the following ways:
The mysqld server is installed in the
libexec directory rather than in the
bin directory.
The data directory is var rather than
data.
mysql_install_db is installed in the
bin directory rather than in the
scripts directory.
The header file and library directories are
include/mysql and
lib/mysql rather than
include and lib.
You can create your own binary installation from a compiled
source distribution by executing the
scripts/make_binary_distribution script
from the top directory of the source distribution.
The next several sections cover the installation of MySQL on platforms where we offer packages using the native packaging format of the respective platform. (This is also known as performing a “binary install.”) However, binary distributions of MySQL are available for many other platforms as well. See Section 2.7, “Installing MySQL on Other Unix-Like Systems”, for generic installation instructions for these packages that apply to all platforms.
See Section 2.1, “General Installation Issues”, for more information on what other binary distributions are available and how to obtain them.
A native Windows version of MySQL has been available from MySQL AB since version 3.21 and represents a sizable percentage of the daily downloads of MySQL. This section describes the process for installing MySQL on Windows.
With the release of MySQL 4.1.5, MySQL AB has introduced a new installer for the Windows version of MySQL, combined with a new GUI Configuration Wizard. This combination automatically installs MySQL, creates an option file, starts the server, and secures the default user accounts.
If you have installed a version of MySQL prior to version 4.1.5, you must perform the following steps:
Obtain and install the distribution.
Set up an option file if necessary.
Select the server that you want to use.
Start the server.
Assign passwords to the initial MySQL accounts.
This process also must be followed with newer MySQL installations where the installation package does not include an installer.
MySQL for Windows is available in two distribution formats:
The binary distribution contains a setup program that installs everything you need so that you can start the server immediately.
The source distribution contains all the code and support files for building the executables using the Visual Studio 2003 compiler system.
Generally speaking, you should use the binary distribution. It is simpler, and you need no additional tools to get MySQL up and running.
This section describes how to install MySQL on Windows using a binary distribution. To install using a source distribution, see Section 2.8.6, “Installing MySQL from Source on Windows”.
To run MySQL on Windows, you need the following:
A 32-bit Windows operating system such as 9x, Me, NT, 2000, XP, or Windows Server 2003.
A Windows NT based operating system (NT, 2000, XP, 2003) permits you to run the MySQL server as a service. The use of a Windows NT based operating system is strongly recommended. See Section 2.3.12, “Starting MySQL as a Windows Service”.
TCP/IP protocol support.
A copy of the MySQL binary distribution for Windows, which can be downloaded from http://dev.mysql.com/downloads/. See Section 2.1.3, “How to Get MySQL”.
Note: If you download the distribution via FTP, we recommend the use of an adequate FTP client with a resume feature to avoid corruption of files during the download process.
A tool that can read .zip files, to
unpack the distribution file.
Enough space on the hard drive to unpack, install, and create the databases in accordance with your requirements (generally a minimum of 200 megabytes is recommended.)
You may also have the following optional requirements:
If you plan to connect to the MySQL server via ODBC, you also need a Connector/ODBC driver. See Section 19.1, “MySQL Connector/ODBC”.
If you need tables with a size larger than 4GB, install
MySQL on an NTFS or newer filesystem. Do not forget to use
MAX_ROWS and
AVG_ROW_LENGTH when you create tables.
See Section 13.1.5, “CREATE TABLE Syntax”.
Starting with MySQL version 4.1.5, there are three install packages to choose from when installing MySQL on Windows. The Packages are as follows:
The Essentials Package:
This package has a filename similar to
mysql-essential-4.1.13a-win32.msi and
contains the minimum set of files needed to install MySQL on
Windows, including the Configuration Wizard. This package
does not include optional components such as the embedded
server and benchmark suite.
The Complete Package: This
package has a filename similar to
mysql-4.1.13a-win32.zip and contains
all files needed for a complete Windows installation,
including the Configuration Wizard. This package includes
optional components such as the embedded server and
benchmark suite.
The Noinstall Archive: This
package has a filename similar to
mysql-noinstall-4.1.13a-win32.zip and
contains all the files found in the Complete install
package, with the exception of the Configuration Wizard.
This package does not include an automated installer, and
must be manually installed and configured.
The Essentials package is recommended for most users.
Your choice of install package affects the installation process you must follow. If you choose to install either the Essentials or Complete install packages, see Section 2.3.3, “Installing MySQL with the Automated Installer”. If you choose to install MySQL from the Noinstall archive, see Section 2.3.6, “Installing MySQL from a Noinstall Zip Archive”.
Starting with MySQL 4.1.5, users can use the new MySQL Installation Wizard and MySQL Configuration Wizard to install MySQL on Windows. The MySQL Installation Wizard and MySQL Configuration Wizard are designed to install and configure MySQL in such a way that new users can immediately get started using MySQL.
The MySQL Installation Wizard and MySQL Configuration Wizard are available in the Essentials and Complete install packages, and are recommended for most standard MySQL installations. Exceptions include users who need to install multiple instances of MySQL on a single server and advanced users who want complete control of server configuration.
If you are installing a version of MySQL prior to MySQL 4.1.5, please follow the instructions for installing MySQL from the Noinstall installation package. See Section 2.3.6, “Installing MySQL from a Noinstall Zip Archive”.
MySQL Installation Wizard is a new installer for the MySQL server that uses the latest installer technologies for Microsoft Windows. The MySQL Installation Wizard, in combination with the MySQL Configuration Wizard, allows a user to install and configure a MySQL server that is ready for use immediately after installation.
The MySQL Installation Wizard is the standard installer for all MySQL server distributions, version 4.1.5 and higher. Users of previous versions of MySQL need to manually shut down and remove their existing MySQL installations before installing MySQL with the MySQL Installation Wizard. See Section 2.3.4.7, “Upgrading MySQL”, for more information on upgrading from a previous version.
Microsoft has included an improved version of their Microsoft Windows Installer (MSI) in the recent versions of Windows. Using the MSI has become the de-facto standard for application installations on Windows 2000, Windows XP, and Windows Server 2003. The MySQL Installation Wizard makes use of this technology to provide a smoother and more flexible installation progress.
The Microsoft Windows Installer Engine was updated with the release of Windows XP; those using a previous version of Windows can reference this Microsoft Knowledge Base article for information on upgrading to the latest version of the Windows Installer Engine.
Further, Microsoft has introduced the WiX (Windows Installer XML) tool set recently. It is the first highly acknowledged Open Source project from Microsoft. We switched to WiX because it is an Open Source project and it allows us to handle the complete Windows installation process in a flexible way with scripts.
Improving the MySQL Installation Wizard depends on the support and feedback of users like you. If you find that the MySQL Installation Wizard is lacking some feature important to you, or if you discover a bug, please use our MySQL Bug System to request features or report problems.
The MySQL server install packages can be downloaded from http://dev.mysql.com/downloads/. If the package you download is contained within a Zip archive, you need to extract the archive first.
The process for starting the wizard depends on the contents of
the install package you download. If there is a
setup.exe file present, double-click it to
start the install process. If there is a
.msi file present, double-click it to start
the install process.
There are up three installation types available:
Typical, Complete, and
Custom.
The Typical installation type installs the
MySQL server, the mysql command-line
client, and the command-line utilities. The command-line
clients and utilities include mysqldump,
myisamchk, and several other tools to help
you manage the MySQL server.
The Complete installation type installs all
components included in the installation package. The full
installation package includes components such as the embedded
server library, the benchmark suite, support scripts, and
documentation.
The Custom installation type gives you
complete control over which packages you wish to install and
the installation path that is used. See
Section 2.3.4.4, “The Custom Install Dialog”, for
more information on performing a custom install.
If you choose the Typical or
Complete installation types and click the
Next button, you advance to the confirmation screen to confirm
your choices and begin the installation. If you choose the
Custom installation type and click the Next
button, you advance to the custom install dialog, described in
Section 2.3.4.4, “The Custom Install Dialog”.
If you wish to change the installation path or the specific
components that are installed by the MySQL Installation
Wizard, you should choose the Custom
installation type.
All available components are listed in a tree view on the left side of the custom install dialog. Components that are not installed have a red X icon, components that are installed have a gray icon. To change whether a component is installed, click on the component's icon and choose an new option from the drop-down list that appears.
You can change the default installation path by clicking the Change... button to the right of the displayed installation path.
After choosing your install components and installation path, click the Next button to advance to the confirmation dialog.
Once you choose an installation type and optionally choose your installation components, you advance to the confirmation dialog. Your installation type and installation path are displayed for you to review.
To install MySQL if you are satisfied with your settings, click the Install button. To change your settings, click the Back button. To exit the MySQL Installation Wizard without installing MySQL, click the Cancel button.
After installation is complete, you are given the option of registering with the MySQL web site. Registration gives you access to post in the MySQL forums at forums.mysql.com, along with the ability to report bugs at bugs.mysql.com and to subscribe to the newsletter. The final screen of the installer provides a summary of the installation and gives you the option to launch the MySQL Configuration Wizard, which you can use to create a configuration file, install the MySQL service, and configure security.
Once you click the Install button, the MySQL Installation Wizard begins the installation process and makes certain changes to your system which are described in the sections that follow.
Changes to the Registry
The MySQL Installation Wizard creates one Windows registry key
in a typical install situation, located in
HKEY_LOCAL_MACHINE\SOFTWARE\MySQL AB.
The MySQL Installation Wizard creates a key named after the
major version of the server that is being installed, such as
MySQL Server 4.1. It contains two string
values, Location and
Version. The Location
string contains the path to the installation directory. In a
default installation it contains C:\Program
Files\MySQL\MySQL Server 4.1\. The
Version string contains the release number.
For example, for an installation of MySQL Server 4.1.5 the key
contains a value of 4.1.5.
These registry keys are used to help external tools identify
the installed location of the MySQL server, preventing a
complete scan of the hard-disk to determine the installation
path of the MySQL server. The registry keys are not required
to run the server and when using the
noinstall Zip archive the registry keys are
not created.
Changes to the Start Menu
The MySQL Installation Wizard creates a new entry in the Windows Start menu under a common MySQL menu heading named after the major version of MySQL that you have installed. For example, if you install MySQL 4.1, the MySQL Installation Wizard creates a MySQL Server 4.1 section in the start menu.
The following entries are created within the new Start menu section:
MySQL Command Line Client: This is a
shortcut to the mysql command-line
client and is configured to connect as the
root user. The shortcut prompts for a
root user password when connecting.
MySQL Server Instance Config Wizard:
This is a shortcut to the MySQL Configuration Wizard. Use
this shortcut to configure a newly installed server, or to
re-configure an existing server.
MySQL Documentation: This is a link to
the MySQL server documentation that is stored locally in
the MySQL server installation directory. This option is
not available when the MySQL server is installed from the
essential installation package.
Changes to the File System
The MySQL Installation Wizard by default installs the MySQL
server to C:\, where
Program
Files\MySQL\MySQL Server
4.1Program Files is the default
location for applications in your system, and
4.1 is the major version of your
MySQL server. This is the new recommended location for the
MySQL server, replacing the previous default location of
c:\mysql.
By default, all MySQL applications are stored in a common
directory at C:\, where
Program
Files\MySQLProgram Files is the default
location for applications in your Windows installation. A
typical MySQL installation on a developer machine may look
like this:
C:\Program Files\MySQL\MySQL Server 4.1 C:\Program Files\MySQL\MySQL Administrator 1.0 C:\Program Files\MySQL\MySQL Query Browser 1.0
This approach makes it easier to manage and maintain all MySQL applications installed on a particular system.
From MySQL version 4.1.5, the new MySQL Installation Wizard can perform server upgrades automatically using the upgrade capabilities of MSI. That means you do not need to remove a previous installation manually before installing a new release. The installer automatically shuts down and removes the previous MySQL service before installing the new version.
Automatic upgrades are only available when upgrading between installations that have the same major and minor version numbers. For example, you can upgrade automatically from MySQL 4.1.5 to MySQL 4.1.6, but not from MySQL 4.1 to MySQL 5.0.
If you are upgrading MySQL version 4.1.4 or earlier to version 4.1.5 or later, you must first manually shut down and remove the older installation before upgrading. Be sure to back up your databases before performing such an upgrade, so that you can restore the databases after the upgrade is completed. It is always recommended that you back up your data before performing any upgrades.
The MySQL Configuration Wizard helps automate the process of
configuring your server under Windows. The MySQL Configuration
Wizard creates a custom my.ini file by
asking you a series of questions and then applying your
responses to a template to generate a
my.ini file that is tuned to your
installation.
The MySQL Configuration Wizard is included with the MySQL server starting with MySQL version 4.1.5, but is designed to work with MySQL servers versions 4.1 and higher. The MySQL Configuration Wizard is currently available for Windows users only.
MySQL Configuration Wizard is to a large extent the result of feedback MySQL AB has received from many users over a period of several years. However, if you find it is lacking some feature important to you, or if you discover a bug, please use our MySQL Bug System to request features or report problems.
The MySQL Configuration Wizard is typically launched from the
MySQL Installation Wizard, as the MySQL Installation Wizard
exits. You can also launch the MySQL Configuration Wizard by
clicking the MySQL Server Instance Config Wizard entry in the
MySQL section of the Start menu.
In addition, you can navigate to the bin
directory of your MySQL installation and launch the
MySQLInstanceConfig.exe file directly.
If the MySQL Configuration Wizard detects an existing
my.ini file, you have the option of
either re-configuring your existing server, or removing the
server instance by deleting the my.ini
file and stopping and removing the MySQL service.
To reconfigure an existing server, choose the
Re-configure Instance option and click the
Next button. Your existing my.ini file is
renamed to my
, where
timestamp.ini.baktimestamp is the date and time the
existing my.ini file was created. To
remove the existing server instance, choose the
Remove Instance option and click the Next
button.
If you choose the Remove Instance option,
you advance to a confirmation window. Click the Execute button
and the MySQL Configuration Wizard stops and removes the MySQL
service and deletes the my.ini file. The
server installation and its data folder are
not removed.
If you choose the Re-configure Instance
option, you advance to the Configuration
Type dialog where you can choose the type of
installation you wish to configure.
When you start the MySQL Configuration Wizard for a new MySQL
installation, or choose the Re-configure
Instance option for an existing installation, you
advance to the Configuration Type dialog.
There are two configuration types available: Detailed
Configuration and Standard
Configuration. The Standard
Configuration option is intended for new users who
want to get started with MySQL quickly without having to make
a lot of decisions in regards to server configuration. The
Detailed Configuration option is intended
for advanced users who want more fine-grained control of
server configuration.
If you are new to MySQL and need a server configured as a
single-user developer machine the Standard
Configuration should suit your needs. Choosing the
Standard Configuration option causes the
MySQL Configuration Wizard to automatically set all
configuration options with the exception of the
Service Options and Security
Options.
The Standard Configuration sets options
that may be incompatible with systems where there are existing
MySQL installations. If you have an existing MySQL
installation on your system in addition to the installation
you wish to configure, the Detailed
Configuration option is recommended.
To complete the Standard Configuration,
please refer to the sections on Service
Options and Security Options,
located at Section 2.3.5.11, “The Service Options Dialog”, and
Section 2.3.5.12, “The Security Options Dialog”, respectively.
There are three different server types available to choose from, and the server type you choose affects the decisions the MySQL Configuration Wizard makes with regards to memory, disk, and processor usage.
: Choose this option for a typical desktop workstation where MySQL is intended only for personal use. It is assumed that many other desktop applications are running. The MySQL server is configured to use minimal system resources.
: Choose this option for a server machine where the MySQL server is running alongside other server applications such as FTP, email, and web servers. The MySQL server is configured to use a medium portion of the system resources.
: Choose this option for a server machine that is intended to run only the MySQL server. It is assumed that no other applications are running. The MySQL server is configured to use all available system resources.
The dialog allows you to
indicate the storage engines you expect to use when creating
MySQL tables. The option you choose determines whether the
InnoDB storage is available and what
percentage of the server resources are available to
InnoDB.
: This
option enables both the InnoDB and
MyISAM storage engines, and divides
resources evenly between the two. This option is
recommended for users who employ both table handlers on a
regular basis.
:
This option enables both the InnoDB and
MyISAM storage engines but dedicates
most server resources to the InnoDB
storage engine. This option is recommended for users who
employ InnoDB almost exclusively and
make only minimal use of MyISAM.
: This option disables the
InnoDB storage engine completely, and
dedicates all server resources to the
MyISAM storage engine. This option is
recommended for those who do not wish to use
InnoDB.
Some users may want to locate the InnoDB
tablespace files in a location other than the MySQL server
data directory. Placing the tablespace files in a separate
location can be desirable if your system has available a
storage device availablehas with higher capacity or higher
performance, such as a RAID storage system.
To change the default location for the
InnoDB tablespace files, choose a new drive
from the drop-down list of drive letters and choose a new path
from the drop-down list of paths. To create a custom path,
click the button.
If you are modifying the configuration of an existing server, you must click the button before you change the path. In this situation you must move existing tablespace files to the new location manually before starting the server.
It is important to set a limit to the number of concurrent connections to the MySQL server that can be established to prevent the server from running out of resources. The dialog allows you to choose the expected usage of your server, and sets the limit for concurrent connections accordingly. It is also possible to manually set the concurrent connection limit.
: Choose this option if the server does not require a large number of concurrent connections. The maximum number of connections is set at 100, with an average of 20 concurrent connections assumed.
: Choose this option if the server requires a large number of concurrent connections. The maximum number of connections is set at 500.
: Choose this option to set the maximum number of concurrent connections to the server manually. Choose the number of concurrent connections from the drop-down box provided, or type the maximum number of connections into the drop-down box if the number you desire is not listed.
Use the dialog to enable or disable TCP/IP networking and to configure the port number that is used to connect to the MySQL server.
TCP/IP networking is enabled by default. To disable TCP/IP networking, uncheck the box next to the option.
Port 3306 is used by default. To change the port used to access MySQL, choose a new port number from the drop-down box or type a new port number directly into the drop-down box. If the port number you choose is in use you are prompted to confirm your choice of port number.
Set the to either enable or disable strict mode. Enabling strict mode (default) will make MySQL behave more like other database management systems. If you run applications that rely on MySQL's old “forgiving” behavior make sure to either adapt those applications or to disable strict mode. For more information about strict mode, see Section 5.2.2, “The Server SQL Mode”.
The MySQL server supports multiple character sets and it is possible to set a default server character set that is applied to all tables, columns, and databases unless overridden. Use the dialog to change the default character set of the MySQL server.
: Choose
this option if you want to use Latin1
as the default server character set.
Latin1 is used for English and many
Western European languages.
: Choose this option if you
want to use UTF8 as the default server
character set. UTF8 can store
characters from many different languages in a single
character set.
: Choose this option if you want to pick the server's default character set manually. Choose the desired character set from the provided drop-down list.
On Windows NT based platforms, the MySQL server can be installed as a service. When installed as a service, the MySQL server can be started automatically during system startup, and even restarted automatically by Windows in the event of a service failure.
The MySQL Configuration Wizard installs the MySQL server as a
service by default, using the service name
MySQL. If you do not wish to install the
service, un-check the box next to the option. You can change the
service name by picking a new service name from the drop-down
box provided or by typing a new service name into the
drop-down box.
To install the MySQL server as a service but not have it started automatically at startup, un-check the box next to the option.
It is strongly recommended that you set a
root password for your MySQL
server, and the MySQL Configuration Wizard requires
by default that you do so. If you do not wish to set a
root password, un-check thebox next to the
option.
To set the root password, type the desired
password into both the and
boxes. If you are re-configuring an existing server, you also
need to enter the existing root password
into the box.
To prevent root logins from across the
network, check the box next to the option. This increases
the security of your root account.
To create an anonymous user account, check the box next to the option. Creating an anonymous account can decrease server security and cause login and permission difficulties and is not recommended.
The final dialog in the MySQL Configuration Wizard is the . To start the configuration process, click the button. To return to a previous dialog, click the button. To exit the MySQL Configuration Wizard without configuring the server, click the button.
After you click the button, the MySQL Configuration Wizard performs a series of tasks with the progress displayed onscreen as the tasks are performed.
The MySQL Configuration Wizard firsts determines various
configuration file options based on your choices using a
template prepared by MySQL AB developers and engineers. This
template is named my-template.ini and is
located in your server installation directory.
The MySQL Configuration Wizard then writes these options to a
my.ini file. The final location of the
my.ini file is displayed next to the
Write configuration file task.
If you chose to create a service for the MySQL server the MySQL Configuration Wizard creates and starts the service. If you are re-configuring an existing service, the MySQL Configuration Wizard restarts the service to apply your configuration changes.
If you chose to set a root password, the
MySQL Configuration Wizard connects to the server, sets your
new root password and applies any other
security settings you may have selected.
After the MySQL Configuration Wizard has completed its tasks, a summary is shown. Click the Finish button to exit the MySQL Configuration Wizard.
In MySQL installations prior to version 4.1.5 it was customary
to name the server configuration file
my.cnf or my.ini and
locate the file either at c:\my.cnf or
c:\Windows\my.ini.
The new MySQL Configuration Wizard places the
my.ini file in the installation directory
of the MySQL server. This helps associate configuration files
with particular server instances.
To ensure that the MySQL server knows where to look for the
my.ini file, an argument similar to this
is passed to the MySQL server as part of the service
installation: --defaults-file=",
where C:\Program
Files\MySQL\MySQL Server 4.1\my.ini"C:\Program Files\MySQL\MySQL Server
4.1 is replaced with the installation path to
the MySQL Server.
The --defaults-file instructs the MySQL
server to read the specified file for configuration options.
To modify the my.ini file, open it with a
text editor and make any necessary changes. You can also
modify the server configuration with the
MySQL
Administrator utility.
MySQL clients and utilities such as the
mysql command-line client and
mysqldump are not able to locate the
my.ini file located in the server
installation directory. To configure the client and utility
applications, create a new my.ini file in
the c:\Windows directory.
Users who are installing from the Noinstall package, or who are installing a version of MySQL prior to 4.1.5 can use the instructions in this section to manually install MySQL. If you are installing a version prior to 4.1.5 with an install package that includes a Setup program, substitute running the Setup program for extracting the archive.
The process for installing MySQL from a Zip archive is as follows:
Extract the archive to the desired install directory.
Create an option file.
Choose a MySQL server type.
Start the MySQL server.
Secure the default user accounts.
This process is described in the sections that follow.
To install MySQL manually, do the following:
If you are upgrading from a previous version please refer to Section 2.3.15, “Upgrading MySQL on Windows”, before beginning the upgrade process.
If you are using a Windows NT-based operating system such as Windows NT, Windows 2000, Windows XP, or Windows Server 2003, make sure that you are logged in as a user with administrator privileges.
Choose an installation location. Traditionally the MySQL
server is installed at C:\mysql, and
the new MySQL Installation Wizard installs MySQL to
C:\Program Files\MySQL. If you do not
install MySQL in C:\mysql, you must
specify the path to the install directory during startup or
in an option file. See
Section 2.3.8, “Creating an Option File”.
Extract the install archive to the chosen installation location using your preferred Zip archive tool. Some tools may extract the archive to a folder within your chosen installation location. If this occurs you can move the contents of the subfolder into the chosen installation location.
If you need to specify startup options when you run the server, you can indicate them on the command line or place them in an option file. For options that are used every time the server starts, you may find it most convenient to use an option file to specify your MySQL configuration. This is particularly true under the following circumstances:
The installation or data directory locations differ from the
default locations (C:\mysql and
C:\mysql\data).
You need to tune the server settings. For example, to use
the InnoDB transactional tables in MySQL
3.23, you must manually add some extra lines to the option
file, as described in
Section 15.4, “InnoDB Configuration”. (As of MySQL 4.0,
InnoDB creates its data files and log
files in the data directory by default. This means you need
not configure InnoDB explicitly. You may
still do so if you wish, and an option file is also useful
in this case.)
When the MySQL server starts on Windows, it looks for options in
two files: the my.ini file in the Windows
directory, and the C:\my.cnf file. The
Windows directory typically is named something like
C:\WINDOWS or
C:\WINNT. You can determine its exact
location from the value of the WINDIR
environment variable using the following command:
C:\> echo %WINDIR%
MySQL looks for options first in the my.ini
file, and then in the my.cnf file. However,
to avoid confusion, it is best if you use only one file. If your
PC uses a boot loader where the C: drive is
not the boot drive, your only option is to use the
my.ini file. Whichever option file you use,
it must be a plain text file.
You can also make use of the example option files included with
your MySQL distribution. Look in your installation directory for
files such as my-small.cnf,
my-medium.cnf,
my-large.cnf, and so on, which you can
rename and copy to the appropriate location for use as a base
configuration file.
An option file can be created and modified with any text editor,
such as the Notepad program. For example, if
MySQL is installed in E:\mysql and the data
directory is E:\mydata\data, you can create
the option file and set up a [mysqld] section
to specify values for the basedir and
datadir parameters:
[mysqld] # set basedir to your installation path basedir=E:/mysql # set datadir to the location of your data directory datadir=E:/mydata/data
Note that Windows pathnames are specified in option files using forward slashes rather than backslashes. If you do use backslashes, you must double them:
[mysqld] # set basedir to your installation path basedir=E:\\mysql # set datadir to the location of your data directory datadir=E:\\mydata\\data
On Windows, the MySQL installer places the data directory
directly under the directory where you install MySQL. If you
would like to use a data directory in a different location, you
should copy the entire contents of the data
directory to the new location. For example, by default, the
installer places MySQL in C:\mysql and the
data directory in C:\mysql\data. If you
want to use E:\mydata as the data
directory, you must do two things:
Move the data directory from
C:\mysql\data to
E:\mydata.
Use a --datadir option to specify the new
data directory location each time you start the server.
Starting with MySQL 3.23.38, the Windows distribution includes both the normal and the MySQL-Max server binaries.
Up through the early releases of MySQL 4.1, the servers included in Windows distributions are named like this:
| Binary | Description |
| mysqld | Compiled with full debugging and automatic memory allocation checking,
and InnoDB and BDB
tables. |
| mysqld-opt | Optimized binary. From version 4.0 on, InnoDB is
enabled. Before 4.0, this server includes no
transactional table support. |
| mysqld-nt | Optimized binary for Windows NT, 2000, and XP with support for named pipes. |
| mysqld-max | Optimized binary with support for InnoDB and
BDB tables. |
| mysqld-max-nt | Like mysqld-max, but compiled with support for named pipes. |
We have found that the server with the most generic name
(mysqld) is the one that many users are
likely to choose by default. However, that is also the server
that results in the highest memory and CPU use due to the
inclusion of full debugging support. The server named
mysqld-opt is a better general-use server
choice to make instead if you do not need debugging support and
do not want the maximal feature set offered by the
-max servers or named pipe support offered by
the -nt servers.
To make it less likely that the debugging server would be chosen inadvertently, some name changes were made from MySQL 4.1.2 to 4.1.4: mysqld has been renamed to mysqld-debug and mysqld-opt has been renamed to mysqld. Thus, the server that includes debugging support indicates that in its name, and the server named mysqld is an efficient default choice. The other servers still have their same names. The resulting servers are named like this:
| Binary | Description |
| mysqld-debug | Compiled with full debugging and automatic memory allocation checking,
and InnoDB and BDB
tables. |
| mysqld | Optimized binary with InnoDB support. |
| mysqld-nt | Optimized binary for Windows NT, 2000, and XP with support for named pipes. |
| mysqld-max | Optimized binary with support for InnoDB and
BDB tables. |
| mysqld-max-nt | Like mysqld-max, but compiled with support for named pipes. |
The name changes were not both instituted at the same time. If you have MySQL 4.1.2 or 4.1.3, it might be that you have a server named mysqld-debug but not one named mysqld. In this case, you should have a server mysqld-opt, which you should choose as your default server unless you need maximal features, named pipes, or debugging support.
All of the preceding binaries are optimized for modern Intel processors, but should work on any Intel i386-class or higher processor.
As of MySQL 4.0, all Windows servers have support for symbolic linking of database directories. Before MySQL 4.0, only the debugging and Max server versions include this feature.
MySQL supports TCP/IP on all Windows platforms. The
mysqld-nt and mysql-max-nt
servers support named pipes on Windows NT, 2000, XP, and 2003.
However, the default is to use TCP/IP regardless of the
platform. (Named pipes are slower than TCP/IP in many Windows
configurations.)
Use of named pipes is subject to these conditions:
Starting from MySQL 3.23.50, named pipes are enabled only if
you start the server with the
--enable-named-pipe option. It is necessary
to use this option explicitly because some users have
experienced problems shutting down the MySQL server when
named pipes were used.
Named pipe connections are allowed only by the mysqld-nt or mysqld-max-nt servers, and only if the server is run on a version of Windows that supports named pipes (NT, 2000, XP, 2003).
These servers can be run on Windows 98 or Me, but only if TCP/IP is installed; named pipe connections cannot be used.
These servers cannot be run on Windows 95.
Note: Most of the examples in reference manual use mysqld as the server name. If you choose to use a different server, such as mysqld-nt, make the appropriate substitutions in the commands that are shown in the examples.
On Windows 95, 98, or Me, MySQL clients always connect to the server using TCP/IP. (This allows any machine on your network to connect to your MySQL server.) Because of this, you must make sure that TCP/IP support is installed on your machine before starting MySQL. You can find TCP/IP on your Windows CD-ROM.
Note that if you are using an old Windows 95 release (for example, OSR2), it is likely that you have an old Winsock package; MySQL requires Winsock 2. You can get the newest Winsock from http://www.microsoft.com/. Windows 98 has the new Winsock 2 library, so it is unnecessary to update the library.
On NT-based systems such as Windows NT, 2000, XP, or 2003, clients have two options. They can use TCP/IP, or they can use a named pipe if the server supports named pipe connections. For MySQL to work with TCP/IP on Windows NT 4, you must install service pack 3 (or newer).
In MySQL versions 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
--protocol=memory option.
For information about which server binary to run, see Section 2.3.9, “Selecting a MySQL Server type”.
This section gives a general overview of starting the MySQL server. The following sections provide more specific information for starting the MySQL server from the command line or as a Windows service.
The examples in these sections assume that MySQL is installed
under the default location of C:\mysql.
Adjust the pathnames shown in the examples if you have MySQL
installed in a different location.
Testing is best done from a command prompt in a console window (a “DOS window”). This way you can have the server display status messages in the window where they are easy to see. If something is wrong with your configuration, these messages make it easier for you to identify and fix any problems.
To start the server, enter this command:
C:\> C:\mysql\bin\mysqld --console
For servers that include InnoDB support, you
should see the following messages as the server starts:
InnoDB: The first specified datafile c:\ibdata\ibdata1 did not exist: InnoDB: a new database to be created! InnoDB: Setting file c:\ibdata\ibdata1 size to 209715200 InnoDB: Database physically writes the file full: wait... InnoDB: Log file c:\iblogs\ib_logfile0 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile0 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280 InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: creating foreign key constraint system tables InnoDB: foreign key constraint system tables created 011024 10:58:25 InnoDB: Started
When the server finishes its startup sequence, you should see something like this, which indicates that the server is ready to service client connections:
mysqld: ready for connections Version: '4.0.14-log' socket: '' port: 3306
The server continues to write to the console any further diagnostic output it produces. You can open a new console window in which to run client programs.
If you omit the --console option, the server
writes diagnostic output to the error log in the data directory
(C:\mysql\data by default). The error log
is the file with the .err extension.
Note: The accounts that are listed in the MySQL grant tables initially have no passwords. After starting the server, you should set up passwords for them using the instructions in Section 2.9, “Post-Installation Setup and Testing”.
The MySQL server can be started manually from the command line. This can be done on any version of Windows.
To start the mysqld server from the command line, you should start a console window (a “DOS window”) and enter this command:
C:\> C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld
The path used in the preceding example may vary depending on the install location of MySQL on your system.
On non-NT versions of Windows, this starts mysqld in the background. That is, after the server starts, you should see another command prompt. If you start the server this way on Windows NT, 2000, XP, or 2003, the server runs in the foreground and no command prompt appears until the server exits. Because of this, you should open another console window to run client programs while the server is running.
You can stop the MySQL server by executing this command:
C:\> C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqladmin -u root shutdown
This invokes the MySQL administrative utility
mysqladmin to connect to the server and tell
it to shut down. The command connects as the MySQL
root user, which is the default
administrative account in the MySQL grant system. Note that
users in the MySQL grant system are wholly independent from any
login users under Windows.
If mysqld does not start, check the error log
to see whether the server wrote any messages there to indicate
the cause of the problem. The error log is located in the
C:\mysql\data directory. It is the file
with a suffix of .err. You can also try to
start the server as mysqld --console; in this
case, you may get some useful information on the screen that may
help solve the problem.
The last option is to start mysqld with
--standalone --debug. In this case,
mysqld writes a log file
C:\mysqld.trace that should contain the
reason why mysqld does not start. See
Section E.1.2, “Creating Trace Files”.
Use mysqld --verbose --help to display all
the options that mysqld understands. (Prior
to MySQL 4.1, omit the --verbose option.)
On the NT family (Windows NT, 2000, XP, 2003), the recommended way to run MySQL is to install it as a Windows service. With the MySQL server installed as a service, Windows starts and stops it server automatically when Windows starts and stops. A MySQL server installed as a service can also be controlled from the command line using NET commands, or with the graphical Services utility.
The Services utility (the Windows Service Control Manager) can be found in the Windows (under on Windows 2000, XP, and Server 2003). It is advisable to close the Services utility while performing server installation or removal operations from this command line. This prevents some odd errors.
Before installing MySQL as a Windows service, you should first stop the current server if it is running by using the following command:
C:\> C:\mysql\bin\mysqladmin -u root shutdown
This invokes the MySQL administrative utility
mysqladmin to connect to the server and tell
it to shut down. The command connects as the MySQL
root user, which is the default
administrative account in the MySQL grant system. Note that
users in the MySQL grant system are wholly independent from any
login users under Windows.
Install the server as a service using this command:
C:\> mysqld --install
If you have problems installing mysqld as a service using just the server name, try installing it using its full pathname. For example:
C:\> C:\mysql\bin\mysqld --install
The service-installation command does not start the server. Instructions for that are given later in this section.
Before MySQL 4.0.2, no command-line arguments can be given
following the --install option. MySQL 4.0.2 and
up offers limited support for additional arguments:
You can specify a service name immediately following the
--install option. The default service name
is MySQL.
As of MySQL 4.0.3, if a service name is given, it can be
followed by a single option. By convention, this should be
--defaults-file=
to specify the name of an option file from which the server
should read options when it starts.
file_name
It is possible to use a single option other than
--defaults-file, but this is discouraged.
--defaults-file is more flexible because it
enables you to specify multiple startup options for the
server by placing them in the named option file. Also, in
MySQL 5.0, use of an option different from
--defaults-file is not supported until
5.0.3.
As of MySQL 5.0.1, you can also specify a
--local-service option following the
service name. This causes the server to run using the
LocalService Windows account that has
limited system privileges. This account is available only
for Windows XP or newer. If both
--defaults-file and
--local-service are given following the
service name, they can be in any order.
For a MySQL server that is installed as a Windows service, the following rules determine the service name and option files that the server uses:
If the service-installation command specifies no service
name or the default service name (MySQL)
following the --install option, the server
uses the a service name of MySQL and
reads options from the [mysqld] group in
the standard option files.
If the service-installation command specifies a service name
other than MySQL following the
--install option, the server uses that
service name. It reads options from the group that has the
same name as the service, and reads options from the
standard option files.
As of MySQL 4.0.17, the server also reads options from the
[mysqld] group from the standard option
files. This allows you to use the
[mysqld] group for options that should be
used by all MySQL services, and an option group with the
same name as a service for use by the server installed with
that service name.
If the service-installation command specifies a
--defaults-file option after the service
name, the server reads options only from the
[mysqld] group of the named file and
ignores the standard option files.
As a more complex example, consider the following command:
C:\> C:\mysql\bin\mysqld --install MySQL --defaults-file=C:\my-opts.cnf
Here, the default service name (MySQL) is
given after the --install option. If no
--defaults-file option had been given, this
command would have the effect of causing the server to read the
[mysqld] group from the standard option
files. However, because the --defaults-file
option is present, the server reads options from the
[mysqld] option group, but only from the
named file.
You can also specify options in in the Windows Services utility before you start the MySQL service.
Note: Prior to MySQL 4.0.17, a
server installed as a Windows service has problems starting if
its pathname or the service name contains spaces. For this
reason, with older versions, avoid installing MySQL in a
directory such as C:\Program Files or using
a service name containing spaces.
Once a MySQL server has been installed as a service, Windows
starts the service automatically whenever Windows starts. The
service also can be started immediately from the
Services utility, or by using the command
NET START MySQL. The NET
command is not case sensitive.
When run as a service, mysqld has no access
to a console window, so no messages can be seen there. If
mysqld does not start, check the error log to
see whether the server wrote any messages there to indicate the
cause of the problem. The error log is located in the MySQL data
directory (for example, C:\mysql\data). It
is the file with a suffix of .err.
When a MySQL server has been installed as a service, and the
service is running, Windows stops the service automatically when
Windows shuts down. The server also can be stopped manually by
using the Services utility, the command
NET STOP MySQL, or the command
mysqladmin shutdown.
From MySQL 3.23.44 on, you have the choice of installing the
server as a Manual service if you do not
wish the service to be started automatically during the boot
process. To do this, use the --install-manual
option rather than the --install option:
C:\> C:\mysql\bin\mysqld --install-manual
To remove a server that is installed as a service, first stop it
if it is running. Then use the --remove option
to remove it:
C:\> C:\mysql\bin\mysqld --remove
For MySQL versions older than 3.23.49, one problem with
automatic MySQL service shutdown is that Windows waited only for
a few seconds for the shutdown to complete, and then killed the
database server process if the time limit was exceeded. This had
the potential to cause problems. (For example, the
InnoDB storage engine would have to perform
crash recovery at the next startup.) Starting from MySQL
3.23.49, Windows waits longer for the MySQL server shutdown to
complete. If you notice this still is not enough for your
installation, it is safest not to run the MySQL server as a
service. Instead, start it from the command-line prompt, and
stop it with mysqladmin shutdown.
This change to tell Windows to wait longer when stopping the
MySQL server works for Windows 2000 and XP. It does not work for
Windows NT, where Windows waits only 20 seconds for a service to
shut down, and after that kills the service process. You can
increase this default by opening the Registry
Editor
(\winnt\system32\regedt32.exe) and editing
the value of WaitToKillServiceTimeout at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
in the Registry tree. Specify the new larger value in
milliseconds. For example, the value 120000
tells Windows NT to wait up to 120 seconds.
If mysqld is not running as a service, you can start it from the command line. For instructions, see Section 2.3.11, “Starting MySQL from the Windows Command Line”.
Please see Section 2.3.14, “Troubleshooting a MySQL Installation Under Windows”, if you encounter difficulties during installation.
You can test whether the MySQL server is working by executing any of the following commands:
C:\>C:\mysql\bin\mysqlshowC:\>C:\mysql\bin\mysqlshow -u root mysqlC:\>C:\mysql\bin\mysqladmin version status procC:\>C:\mysql\bin\mysql test
If mysqld is slow to respond to TCP/IP
connections from client programs on Windows 9x/Me, there is
probably a problem with your DNS. In this case, start
mysqld with the
--skip-name-resolve option and use only
localhost and IP numbers in the
Host column of the MySQL grant tables.
You can force a MySQL client to use a named pipe connection
rather than TCP/IP by specifying the --pipe
option or by specifying . (period) as the
host name. Use the --socket option to specify
the name of the pipe. As of MySQL 4.1, you can use the
--protocol=PIPE option instead.
There are two versions of the MySQL command-line tool on Windows:
| Binary | Description |
| mysql | Compiled on native Windows, offering limited text editing capabilities. |
| mysqlc | Compiled with the Cygnus GNU compiler and libraries, which offers
readline editing.
mysqlc was intended for use primarily
with Windows 9x/Me. It does not support the updated
authentication protocol used beginning with MySQL 4.1,
and is not supported in MySQL 4.1 and above. Beginning
with MySQL 4.1.8, it is no longer included in MySQL
Windows distributions. |
To use mysqlc, you must have a copy of the
cygwinb19.dll library installed somewhere
that mysqlc can find it. If your distribution
does not have the cygwinb19.dll library in
the bin directory under the base directory
of your MySQL installation, look for it in the
lib directory and copy it to your Windows
system directory (\Windows\system or a
similar place).
When installing and running MySQL for the first time, you may encounter certain errors that prevent the MySQL server from starting. The purpose of this section is to help you diagnose and correct some of these errors.
Your first resource when troubleshooting server issues is the
error log. The MySQL server uses the error log to record
information relevant to the error that is preventing the server
from starting. The error log is located in the data directory
specified in your my.ini file. The default
data directory location is C:\mysql\data.
See Section 5.10.1, “The Error Log”.
Another source of information regarding possible errors is the console messages displayed when the MySQL service is starting. Use the NET START mysql command from the command line after installing mysqld as a service to see any error messages regarding the starting of the MySQL server as a service. See Section 2.3.12, “Starting MySQL as a Windows Service”.
The following are examples of some of the more common error messages you may encounter when installing MySQL and starting the server for the first time:
System error 1067 has occurred. Fatal error: Can't open privilege tables: Table 'mysql.host' does not exist
These messages occur when the MySQL server cannot find the
mysql privileges database or other
critical files. This error is often encountered when the
MySQL base or data directories are installed in different
locations than the default locations
(C:\mysql and
C:\mysql\data, respectively).
One situation when this may occur is when MySQL is upgraded and installed to a new location, but the configuration file is not updated to reflect the new install location. In addition there may be old and new configuration files that conflict, be sure to delete or rename any old configuration files when upgrading MySQL.
If you have installed MySQL to a directory other than
C:\mysql you need to ensure that the
MySQL server is aware of this through the use of a
configuration (my.ini) file. The
my.ini file needs to be located in your
Windows directory, typically located at
C:\WINNT or
C:\WINDOWS. You can determine its exact
location from the value of the WINDIR
environment variable by issuing the following command from
the command prompt:
C:\> echo %WINDIR%
An option file can be created and modified with any text
editor, such as the Notepad program. For
example, if MySQL is installed in
E:\mysql and the data directory is
D:\MySQLdata, you can create the option
file and set up a [mysqld] section to
specify values for the basedir and
datadir parameters:
[mysqld] # set basedir to your installation path basedir=E:/mysql # set datadir to the location of your data directory datadir=D:/MySQLdata
Note that Windows pathnames are specified in option files using forward slashes rather than backslashes. If you do use backslashes, you must double them:
[mysqld] # set basedir to your installation path basedir=C:\\Program Files\\mysql # set datadir to the location of your data directory datadir=D:\\MySQLdata
If you change the datadir value in your
MySQL configuration file, you must move the contents of the
existing MySQL data directory before restarting the MySQL
server.
Error: Cannot create Windows service for MySql. Error: 0
This error is encountered when you re-install or upgrade MySQL without first stopping and removing the exi