MySQL Reference Manual for version 4.0.20.


1 General Information

The MySQL (R) 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 trademark of MySQL AB.

The MySQL software is Dual Licensed. Users can choose to use the MySQL software as an Open Source/Free Software 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 section 1.4 MySQL Support and Licensing.

The MySQL Web site (http://www.mysql.com/) provides the latest information about the MySQL software.

The following list describes some sections of particular interest in this manual:

Important:

Reports of errors (often called ``bugs''), as well as questions and comments, should be sent to the general MySQL mailing list. See section 1.7.1.1 The MySQL Mailing Lists. See section 1.7.1.3 How to Report Bugs or Problems.

The mysqlbug script should be used to generate bug reports on Unix. (Windows distributions contain a file named `mysqlbug.txt' in the base directory that can be used as a template for a bug report.)

For source distributions, the mysqlbug script can be found in the `scripts' directory. For binary distributions, mysqlbug can be found in the `bin' directory (`/usr/bin' for the MySQL-server RPM package).

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.

1.1 About This Manual

This is the MySQL reference manual; it documents MySQL up to Version 4.0.20. Functional changes are always indicated with reference to the version, so this manual is also suitable if you are using an older version of the MySQL software (such as 3.23 or 4.0-production). There are also references for version 5.0 (development).

Being a reference manual, it does not provide general instruction on SQL or relational database concepts. It also will not teach you how to use your operating system or command line interpreter.

As the MySQL Database Software is under constant development, the manual is also updated frequently. The most recent version of this manual is available at http://dev.mysql.com/doc/ in many different formats, including HTML, PDF, and Windows HLP versions.

The primary document is the Texinfo file. The HTML version is produced automatically using a modified version of texi2html. The plain text and Info versions are produced with makeinfo. The PostScript version is produced using texi2dvi and dvips. The PDF version is produced with pdftex.

The index can assist you in finding information in the manual. For online use, you can try the searchable version of the manual available at http://dev.mysql.com/doc/.

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 initially written by David Axmark and Michael (Monty) Widenius. It is now maintained by the MySQL Documentation Team, consisting of Arjen Lentz, Paul DuBois, and Stefan Hinz. For the many other contributors, see section B Credits.

The copyright (2004) to this manual is owned by the Swedish company MySQL AB. See section 1.4.2 Copyrights and Licenses Used by MySQL.

1.1.1 Conventions Used in This Manual

This manual uses certain typographical conventions:

constant
Constant-width font is used for command names and options; SQL statements; database, table, and column names; C and Perl code; and environment variables. Example: ``To see how mysqladmin works, invoke it with the --help option.''
`filename'
Constant-width font with surrounding quotes is used for filenames and pathnames. Example: ``The distribution is installed under the `/usr/local/' directory.''
`c'
Constant-width font with surrounding quotes is also used to indicate character sequences. Example: ``To specify a wildcard, use the `%' character.''
italic
Italic font is used for emphasis, like this.
boldface
Boldface font is used in table headings and to convey especially strong emphasis.

When commands are shown that are meant to be executed by a particular program, the program is indicated by a prompt shown before the command. 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 here
mysql> type a mysql statement here

The ``shell'' is your command interpreter. On Unix, this is typically a program such as sh or csh. On Windows, the equivalent is command.com or cmd.exe, typically run in a Windows console.

Note that to enter a command or statement from an example, you do not type the prompt shown in the example.

Commands to set shell variables are shown using Bourne shell syntax. If you are using csh or tcsh, you will need to issue commands somewhat differently. For example, the sequence to set an environment variable and run a command looks like this in Bourne shell syntax:

shell> VARNAME=value some_command

For csh or tcsh, you would execute the sequence like this:

shell> setenv VARNAME value
shell> some_command

Database, table, and column names must often be substituted into commands. 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 uppercase or lowercase. This manual uses uppercase.

In syntax descriptions, square brackets (`[' and `]') are used to 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:

RESET reset_option [,reset_option] ...

1.2 Overview of the MySQL Database Management System

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, that builds its business by providing services around the MySQL database management system. See section 1.3 Overview of MySQL AB.

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 section 1.4.3 MySQL Licenses.
Why use the MySQL Database Server?
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.
The technical features of MySQL Server
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 a multi-threaded library that you can link into your application to get a smaller, faster, easier-to-manage product.
There is a large amount of contributed MySQL software available.
It is very likely that you will find that your favorite application or language already 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.

1.2.1 History of MySQL

We started out with the intention of using mSQL 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. Sakila 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 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.

1.2.2 The Main Features of MySQL

The following list describes some of the important characteristics of the MySQL Database Software. See section 1.5.1 MySQL 4.0 in a Nutshell.

Internals and Portability
Column Types
Commands and Functions
Security
Scalability and Limits
Connectivity
Localization
Clients and Tools

1.2.3 MySQL Stability

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 list, which is 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 Version 3.23 and 4.0 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 1.8.7 Known Errors and Design Deficiencies 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 -- Gamma
Large groups of servers using replication are in production use, with good results. Work on enhanced replication features is continuing in MySQL 5.x.
InnoDB tables -- Stable (in 3.23 from 3.23.49)
The InnoDB transactional storage engine has been declared stable in the MySQL 3.23 tree, starting from version 3.23.49. InnoDB is being used in large, heavy-load production systems.
BDB tables -- Gamma
The Berkeley DB code is very stable, but we are still improving the BDB transactional storage engine interface in MySQL Server, so it will take some time before this is as well tested as the other table types.
Full-text searches -- Beta
Full-text searching works but is not yet widely used. Important enhancements have been implemented in MySQL 4.0.
Connector/ODBC 3.51 (uses ODBC SDK 3.51) -- Stable
In wide production use. Some issues brought up appear to be application-related and independent of the ODBC driver or underlying database server.
Automatic recovery of MyISAM tables -- Gamma
This status applies only to the new code in the MyISAM storage engine that checks whether the table was closed properly on open and executes an automatic check or repair of the table if it wasn't.

Paying customers receive high-quality support directly from MySQL AB. MySQL AB also provides the MySQL mailing list as a community resource where anyone may ask questions.

Bugs are usually fixed right away with a patch. For serious bugs, there is almost always a new release.

1.2.4 How Big MySQL Tables Can Be

MySQL Version 3.22 had a 4GB (4 gigabyte) limit on table size. With the MyISAM storage engine in MySQL Version 3.23, the maximum table size was increased to 8 million terabytes (2 ^ 63 bytes). With this larger allowed table size, the maximum effective table size for MySQL databases now normally is 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:

Operating System File-size Limit
Linux-Intel 32-bit 2GB, much more when using LFS
Linux-Alpha 8TB (?)
Solaris 2.5.1 2GB (4GB possible with patch)
Solaris 2.6 4GB (can be changed with flag)
Solaris 2.7 Intel 4GB
Solaris 2.7 UltraSPARC 512GB
NetWare w/NSS filesystem 8TB

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. Most current Linux distributions are based on kernel 2.4 and already include all the required LFS patches. However, the maximum available file size still depends on several factors, one of them being the filesystem used to store MySQL tables.

For a very 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.

By default, MySQL creates MyISAM tables with an internal structure that allows a maximum size of about 4GB. You can check the maximum table size for a table with the SHOW TABLE STATUS command or with the myisamchk -dv tbl_name. See section 14.5.3 SET and SHOW Syntax.

If you need a MyISAM table that will be larger than 4GB in size (and your operating system supports large files), the CREATE TABLE statement allows AVG_ROW_LENGTH and MAX_ROWS options. See section 14.2.5 CREATE TABLE Syntax. You can also change these options with ALTER TABLE after the table has been created, to increase the table's maximum allowable size. See section 14.2.2 ALTER TABLE Syntax.

Other ways to work around file-size limits for MyISAM tables are as follows:

1.2.5 Year 2000 Compliance

The MySQL Server itself has no problems with Year 2000 (Y2K) compliance:

The following simple demonstration illustrates that MySQL Server doesn't have any problems with dates until after the year 2030:

mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE y2k (date DATE,
    ->                   date_time DATETIME,
    ->                   time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO y2k VALUES
    -> ('1998-12-31','1998-12-31 23:59:59',19981231235959),
    -> ('1999-01-01','1999-01-01 00:00:00',19990101000000),
    -> ('1999-09-09','1999-09-09 23:59:59',19990909235959),
    -> ('2000-01-01','2000-01-01 00:00:00',20000101000000),
    -> ('2000-02-28','2000-02-28 00:00:00',20000228000000),
    -> ('2000-02-29','2000-02-29 00:00:00',20000229000000),
    -> ('2000-03-01','2000-03-01 00:00:00',20000301000000),
    -> ('2000-12-31','2000-12-31 23:59:59',20001231235959),
    -> ('2001-01-01','2001-01-01 00:00:00',20010101000000),
    -> ('2004-12-31','2004-12-31 23:59:59',20041231235959),
    -> ('2005-01-01','2005-01-01 00:00:00',20050101000000),
    -> ('2030-01-01','2030-01-01 00:00:00',20300101000000),
    -> ('2050-01-01','2050-01-01 00:00:00',20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date       | date_time           | time_stamp     |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

The final TIMESTAMP column value is zero because the final year (2050) exceeds the TIMESTAMP maximum. The TIMESTAMP data type, which is used to store the current time, supports values that range from 19700101000000 to 20300101000000 on 32-bit machines (signed value). On 64-bit machines, TIMESTAMP handles values up to 2106 (unsigned value).

The example also shows that the DATE and DATETIME data types have no problems with the dates used. They handle dates through the year 9999.

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 12.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.

1.3 Overview of MySQL AB

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.

The developers of the MySQL server are all employed by the company. We are a virtual organization with people in a dozen countries around the world. We communicate extensively over the Internet every day with one another and with our users, supporters, and partners.

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 trademark, and this manual. See section 1.2 Overview of the MySQL Database Management System.

The MySQL core values show our dedication to MySQL and Open Source.

We want the MySQL Database Software to be:

MySQL AB and the people at MySQL AB:

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 US and Germany, respectively.

1.3.1 The Business Model and Services of MySQL AB

One of the most common questions we encounter is: ``How can you make a living from something you give away for free?'' This is how:

The company has been profitable since its inception. In October 2001, we accepted venture financing from leading Scandinavian investors and a handful of business angels. This investment is used to solidify our business model and build a basis for sustainable growth.

1.3.1.1 Support

MySQL AB is run and owned by the founders and main developers of the MySQL database. The developers are committed to providing support to customers and other users in order to stay in touch with their needs and problems. All our support is provided by qualified developers. Really tricky questions are answered by Michael Monty Widenius, principal author of the MySQL Server. See section 1.4.1 Support Offered by MySQL AB.

For more information and ordering support at various levels, see http://www.mysql.com/support/ or contact our sales staff at sales@mysql.com.

1.3.1.2 Training and Certification

MySQL AB delivers MySQL and related training worldwide. We offer both open courses and in-house courses tailored to the specific needs of your company. MySQL Training is also available through our partners, the Authorized MySQL Training Centers.

Our training material uses the same sample databases used in our documentation and our sample applications, and is always updated to reflect the latest MySQL version. Our trainers are backed by the development team to guarantee the quality of the training and the continuous development of the course material. This also ensures that no questions raised during the courses remain unanswered.

Attending our training courses will enable you to achieve your MySQL application goals. You will also:

If you are interested in our training as a potential participant or as a training partner, please visit the training section at http://www.mysql.com/training/ or contact us at: training@mysql.com.

For details about the MySQL Certification Program, please see http://www.mysql.com/certification/.

1.3.1.3 Consulting

MySQL AB and its Authorized Partners offer consulting services to users of MySQL Server and to those who embed MySQL Server in their own software, all over the world.

Our consultants can help you design and tune your databases, construct efficient queries, tune your platform for optimal performance, resolve migration issues, set up replication, build robust transactional applications, and more. We also help customers embed MySQL Server in their products and applications for large-scale deployment.

Our consultants work in close collaboration with our development team, which ensures the technical quality of our professional services. Consulting assignments range from two-day power-start sessions to projects that span weeks and months. Our expertise not only covers MySQL Server---it also extends into programming and scripting languages such as PHP, Perl, and more.

If you are interested in our consulting services or want to become a consulting partner, please visit the consulting section of our Web site at http://www.mysql.com/consulting/ or contact our consulting staff at consulting@mysql.com.

1.3.1.4 Commercial Licenses

The MySQL database is released under the GNU General Public License (GPL). This means that the MySQL software can be used free of charge under the GPL. If you do not want to be bound by the GPL terms (such as the requirement that your application must also be GPL), you may purchase a commercial license for the same product from MySQL AB; see https://order.mysql.com/. Since MySQL AB owns the copyright to the MySQL source code, we are able to employ Dual Licensing, which means that the same product is available under GPL and under a commercial license. This does not in any way affect the Open Source commitment of MySQL AB. For details about when a commercial license is required, please see section 1.4.3 MySQL Licenses.

We also sell commercial licenses of third-party Open Source GPL software that adds value to MySQL Server. A good example is the InnoDB transactional storage engine that offers ACID support, row-level locking, crash recovery, multi-versioning, foreign key support, and more. See section 16 The InnoDB Storage Engine.

1.3.1.5 Partnering

MySQL AB has a worldwide partner program that covers training courses, consulting and support, publications, plus reselling and distributing MySQL and related products. MySQL AB Partners get visibility on the http://www.mysql.com/ Web site and the right to use special versions of the MySQL trademarks to identify their products and promote their business.

If you are interested in becoming a MySQL AB Partner, please email partner@mysql.com.

The word MySQL and the MySQL dolphin logo are trademarks of MySQL AB. See section 1.4.4 MySQL AB Logos and Trademarks. These trademarks represent a significant value that the MySQL founders have built over the years.

The MySQL Web site (http://www.mysql.com/) is popular among developers and users. In December 2003, we served 16 million page views. Our visitors represent a group that makes purchase decisions and recommendations for both software and hardware. Twelve percent of our visitors authorize purchase decisions, and only nine percent are not involved in purchase decisions at all. More than 65% have made one or more online business purchases within the last half-year, and 70% plan to make one in the next few months.

1.3.2 Contact Information

The MySQL Web site (http://www.mysql.com/) provides the latest information about MySQL and MySQL AB.

For press services and inquiries not covered in our news releases (http://www.mysql.com/news-and-events/), please send email to press@mysql.com.

If you have a valid support contract with MySQL AB, you will get timely, precise answers to your technical questions about the MySQL software. For more information, see section 1.4.1 Support Offered by MySQL AB. On our Web site, see http://www.mysql.com/support/, or send an email message to sales@mysql.com.

For information about MySQL training, please visit the training section at http://www.mysql.com/training/. If you have restricted access to the Internet, please contact the MySQL AB training staff via email at training@mysql.com. See section 1.3.1.2 Training and Certification.

For information on the MySQL Certification Program, please see http://www.mysql.com/certification/. See section 1.3.1.2 Training and Certification.

If you're interested in consulting, please visit the consulting section of our Web site at http://www.mysql.com/consulting/. If you have restricted access to the Internet, please contact the MySQL AB consulting staff via email at consulting@mysql.com. See section 1.3.1.3 Consulting.

Commercial licenses may be purchased online at https://order.mysql.com/. There you will also find information on how to fax your purchase order to MySQL AB. More information about licensing can be found at http://www.mysql.com/products/licensing/. If you have questions regarding licensing or you want a quote for a high-volume license deal, please fill in the contact form on our Web site (http://www.mysql.com/) or send email to licensing@mysql.com (for licensing questions) or to sales@mysql.com (for sales inquiries). See section 1.4.3 MySQL Licenses.

If you represent a business that is interested in partnering with MySQL AB, please send email to partner@mysql.com. See section 1.3.1.5 Partnering.

For more information on the MySQL trademark policy, refer to http://www.mysql.com/company/trademark.html or send email to trademark@mysql.com. See section 1.4.4 MySQL AB Logos and Trademarks.

If you are interested in any of the MySQL AB jobs listed in our jobs section (http://www.mysql.com/company/jobs/), please send email to jobs@mysql.com. Please do not send your CV as an attachment, but rather as plain text at the end of your email message.

For general discussion among our many users, please direct your attention to the appropriate mailing list. See section 1.7.1 MySQL Mailing Lists.

Reports of errors (often called ``bugs''), as well as questions and comments, should be sent to the general MySQL mailing list. See section 1.7.1.1 The MySQL Mailing Lists. 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. See section 1.7.1.3 How to Report Bugs or Problems.

If you have benchmark results that we can publish, please contact us via email at benchmarks@mysql.com.

If you have suggestions concerning additions or corrections to this manual, please send them to the manual team via email at docs@mysql.com.

For questions or comments about the workings or content of the MySQL Web site (http://www.mysql.com/), please send email to webmaster@mysql.com.

MySQL AB has a privacy policy, which can be read at http://www.mysql.com/company/privacy.html. For any queries regarding this policy, please send email to privacy@mysql.com.

For all other inquires, please send an email to info@mysql.com.

1.4 MySQL Support and Licensing

This section describes MySQL support and licensing arrangements.

1.4.1 Support Offered by MySQL AB

Technical support from MySQL AB means individualized answers to your unique problems direct from the software engineers who code the MySQL database engine.

We try to take a broad and inclusive view of technical support. Almost any problem involving MySQL software is important to us if it's important to you. Typically customers seek help on how to get different commands and utilities to work, remove performance bottlenecks, restore crashed systems, understand the impact of operating system or networking issues on MySQL, set up best practices for backup and recovery, utilize APIs, and so on. Our support covers only the MySQL server and our own utilities, not third-party products that access the MySQL server, although we try to help with these where we can.

Detailed information about our various support options is given at http://www.mysql.com/support/, where support contracts can also be ordered online. If you have restricted access to the Internet, please contact our sales staff via email at sales@mysql.com.

Technical support is like life insurance. You can live happily without it for years. However, when your hour arrives, it becomes critically important, but it's too late to buy it. If you use MySQL Server for important applications and encounter sudden difficulties, it may be too time-consuming to figure out all the answers yourself. You may need immediate access to the most experienced MySQL troubleshooters available, those employed by MySQL AB.

1.4.2 Copyrights and Licenses Used by MySQL

MySQL AB owns the copyright to the MySQL source code, the MySQL logos and trademarks, and this manual. See section 1.3 Overview of MySQL AB. Several different licenses are relevant to the MySQL distribution:

  1. All the MySQL-specific source in the server, the mysqlclient library and the client, as well as the GNU readline library, are covered by the GNU General Public License. See section G GNU General Public License. The text of this license can be found as the file `COPYING' in the distribution.
  2. The GNU getopt library is covered by the GNU Lesser General Public License. See http://www.fsf.org/licenses/.
  3. Some parts of the source (the regexp library) are covered by a Berkeley-style copyright.
  4. Older versions of MySQL (3.22 and earlier) are subject to a stricter license (http://www.mysql.com/products/licensing/mypl.html). See the documentation of the specific version for information.
  5. The MySQL reference manual is currently not distributed under a GPL-style license. Use of the manual is subject to the following terms: Please send an email message to docs@mysql.com for more information or if you are interested in doing a translation.

For information about how the MySQL licenses work in practice, please refer to section 1.4.3 MySQL Licenses. Also see section 1.4.4 MySQL AB Logos and Trademarks.

1.4.3 MySQL Licenses

The MySQL software is released under the GNU General Public License (GPL), which is probably the best known Open Source license. The formal terms of the GPL license can be found at http://www.fsf.org/licenses/. See also http://www.fsf.org/licenses/gpl-faq.html and http://www.gnu.org/philosophy/enforcing-gpl.html.

Since the MySQL software is released under the GPL, it may often be used for free, but for certain uses you may want or need to buy commercial licenses from MySQL AB at https://order.mysql.com/. See http://www.mysql.com/products/licensing/ for more information.

Older versions of MySQL (3.22 and earlier) are subject to a stricter license (http://www.mysql.com/products/licensing/mypl.html). See the documentation of the specific version for information.

Please note that the use of the MySQL software under commercial license, GPL, or the old MySQL license does not automatically give you the right to use MySQL AB trademarks. See section 1.4.4 MySQL AB Logos and Trademarks.

1.4.3.1 Using the MySQL Software Under a Commercial License

The GPL license is contagious in the sense that when a program is linked to a GPL program, all the source code for all the parts of the resulting product must also be released under the GPL. If you do not follow this GPL requirement, you break the license terms and forfeit your right to use the GPL program altogether. You also risk damages.

You need a commercial license:

If you require a license, you will need one for each installation of the MySQL software. This covers any number of CPUs on a machine, and there is no artificial limit on the number of clients that connect to the server in any way.

For commercial licenses, please visit our Web site at http://www.mysql.com/products/licensing/. For support contracts, see http://www.mysql.com/support/. If you have special needs or you have restricted access to the Internet, please contact our sales staff via email at sales@mysql.com.

1.4.3.2 Using the MySQL Software for Free Under GPL

You can use the MySQL software for free under the GPL if you adhere to the conditions of the GPL. For additional details, including answers to common questions about the GPL, see the generic FAQ from the Free Software Foundation at http://www.fsf.org/licenses/gpl-faq.html. Common uses of the GPL include:

If your use of MySQL database software does not require a commercial license, we encourage you to purchase support from MySQL AB anyway. This way you contribute toward MySQL development and also gain immediate advantages for yourself. See section 1.4.1 Support Offered by MySQL AB.

If you use the MySQL database software in a commercial context such that you profit by its use, we ask that you further the development of the MySQL software by purchasing some level of support. We feel that if the MySQL database helps your business, it is reasonable to ask that you help MySQL AB. (Otherwise, if you ask us support questions, you are not only using for free something into which we've put a lot a work, you're asking us to provide free support, too.)

1.4.4 MySQL AB Logos and Trademarks

Many users of the MySQL database want to display the MySQL AB dolphin logo on their Web sites, books, or boxed products. We welcome and encourage this, although it should be noted that the word MySQL and the MySQL dolphin logo are trademarks of MySQL AB and may only be used as stated in our trademark policy at http://www.mysql.com/company/trademark.html.

1.4.4.1 The Original MySQL Logo

The MySQL dolphin logo was designed by the Finnish advertising agency Priority in 2001. The dolphin was chosen as a suitable symbol for the MySQL database management system, which is like a smart, fast, and lean animal, effortlessly navigating oceans of data. We also happen to like dolphins.

The original MySQL logo may only be used by representatives of MySQL AB and by those having a written agreement allowing them to do so.

1.4.4.2 MySQL Logos That May Be Used Without Written Permission

We have designed a set of special Conditional Use logos that may be downloaded from our Web site at http://www.mysql.com/press/logos.html and used on third-party Web sites without written permission from MySQL AB. The use of these logos is not entirely unrestricted but, as the name implies, subject to our trademark policy that is also available on our Web site. You should read through the trademark policy if you plan to use them. The requirements are basically as follows:

Contact us via email at trademark@mysql.com to inquire about special arrangements to fit your needs.

1.4.4.3 When You Need Written Permission to Use MySQL Logos

You need written permission from MySQL AB before using MySQL logos in the following cases:

Due to legal and commercial reasons, we monitor the use of MySQL trademarks on products, books, and other items. We usually require a fee for displaying MySQL AB logos on commercial products, since we think it is reasonable that some of the revenue is returned to fund further development of the MySQL database.

1.4.4.4 MySQL AB Partnership Logos

MySQL partnership logos may be used only by companies and persons having a written partnership agreement with MySQL AB. Partnerships include certification as a MySQL trainer or consultant. For more information, please see section 1.3.1.5 Partnering.

1.4.4.5 Using the Word MySQL in Printed Text or Presentations

MySQL AB welcomes references to the MySQL database, but it should be noted that the word MySQL is a trademark of MySQL AB. Because of this, you must append the trademark symbol (TM) to the first or most prominent use of the word MySQL in a text and, where appropriate, state that MySQL is a trademark of MySQL AB. For more information, please refer to our trademark policy at http://www.mysql.com/company/trademark.html.

1.4.4.6 Using the Word MySQL in Company and Product Names

Use of the word MySQL in product or company names or in Internet domain names is not allowed without written permission from MySQL AB.

1.5 MySQL Development Roadmap

This section provides a snapshot of the MySQL development roadmap, including major features implemented or planned for MySQL 4.0, 4.1, 5.0, and 5.1. The following sections provide information for each release series.

The production release series is MySQL 4.0, which was declared stable for production use as of Version 4.0.12, released in March 2003. This means that future 4.0 development will be limited only to making bugfixes. For the older MySQL 3.23 series, only critical bugfixes will be made.

Active MySQL development currently is taking place in the MySQL 4.1 and 5.0 release series. This means that new features are being added to MySQL 4.1 and MySQL 5.0. Both 4.1 and 5.0 are available now in alpha status.

Before upgrading from one release series to the next, please see the notes at section 2.5 Upgrading/Downgrading MySQL.

Plans for some of the most requested features are summarized in the following table.

Feature MySQL Version
Unions 4.0
Subqueries 4.1
R-trees 4.1 (for MyISAM tables)
Stored procedures 5.0
Views 5.0 or 5.1
Cursors 5.0
Foreign keys 5.1 (already implemented in 3.23 for InnoDB)
Triggers 5.1
Full outer join 5.1
Constraints 5.1

1.5.1 MySQL 4.0 in a Nutshell

Long awaited by our users, MySQL Server 4.0 is now available in production status.

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.

The major new features of MySQL Server 4.0 are geared toward our existing business and community users, enhancing the MySQL database software as the solution for mission-critical, heavy-load database systems. Other new features target the users of embedded databases.

1.5.1.1 Features Available in MySQL 4.0

Speed enhancements
Embedded MySQL Server introduced
InnoDB storage engine as standard
New functionality
Standards compliance, portability, and migration
Internationalization
Usability enhancements
In the process of implementing features for new users, we have not forgotten requests from our loyal community of existing users.

The news section of this manual includes a more in-depth list of features. See section C.3 Changes in release 4.0.x (Production).

1.5.1.2 The Embedded MySQL Server

The libmysqld embedded server library makes MySQL Server suitable for a vastly expanded realm of applications. By 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 behind the scenes in Internet appliances, public kiosks, turnkey hardware/software combination units, high performance Internet servers, self-contained databases distributed on CD-ROM, and so on.

Many users of libmysqld will benefit from the MySQL Dual Licensing. For those not wishing to be bound by the GPL, the software is also made available under a commercial license. The embedded MySQL library uses the same interface as the normal client library, so it is convenient and easy to use. See section 20.2.15 libmysqld, the Embedded MySQL Server Library.

1.5.2 MySQL 4.1 in a Nutshell

MySQL Server 4.0 laid the foundation for new features implemented in MySQL 4.1, such as subqueries and Unicode support, and for the work on stored procedures being done in version 5.0. These features come at the top of the wish list of many of our customers.

With these additions, critics of the MySQL Database Server have to be more imaginative than ever in pointing out deficiencies in the MySQL database management system. Already well-known for its stability, speed, and ease of use, MySQL Server will be able to fulfill the requirement checklists of very demanding buyers.

1.5.2.1 Features Available in MySQL 4.1

The features listed in this section are implemented in MySQL 4.1. A few other features are still planned for MySQL 4.1. See section 1.6.1 New Features Planned for 4.1.

Most new features being coded are or will be available in MySQL 5.0. See section 1.6.2 New Features Planned for 5.0.

Support for subqueries and derived tables
Speed enhancements
New functionality
Standards compliance, portability, and migration
Internationalization
Usability enhancements

The news section of this manual includes a more in-depth list of features. See section C.2 Changes in release 4.1.x (Alpha).

1.5.2.2 Stepwise Rollout

New features are being added to MySQL 4.1. The alpha version is already available for download. See section 1.5.2.3 Ready for Immediate Development Use.

The set of features that are being added to version 4.1 is mostly fixed. Additional development is already ongoing for version 5.0. MySQL 4.1 will go through the steps of Alpha (during which time new features might still be added/changed), Beta (when we have feature freeze and only bug corrections will be done), and Gamma (indicating that a production release is just weeks ahead). At the end of this process, MySQL 4.1 will become the new production release.

1.5.2.3 Ready for Immediate Development Use

MySQL 4.1 is currently in the alpha stage, 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 C.2 Changes in release 4.1.x (Alpha).

For those wishing to use the most recent development source for MySQL 4.1, we make our 4.1 BitKeeper repository publicly available. See section 2.3.3 Installing from the Development Source Tree.

1.5.3 MySQL 5.0: The Next Development Release

New development for MySQL is focused on the 5.0 release, featuring stored procedures and other new features. See section 1.6.2 New Features Planned for 5.0.

For those wishing to take a look at the bleeding edge of MySQL development, we make our BitKeeper repository for MySQL version 5.0 publicly available. See section 2.3.3 Installing from the Development Source Tree. As of December 2003, binary builds of version 5.0 are also available.

1.6 MySQL and the Future (the TODO)

This section summarizes the features that we plan to implement in MySQL Server. The items are ordered by release series. Within a list, items are shown in approximately the order they will be done.

Note: If you are an enterprise-level user with an urgent need for a particular feature, please contact sales@mysql.com to discuss sponsoring options. Targeted financing by sponsor companies allows us to allocate additional resources for specific purposes. One example of a feature sponsored in the past is replication.

1.6.1 New Features Planned for 4.1

The following features are not yet implemented in MySQL 4.1, but are planned for implementation before MySQL 4.1 moves into its beta phase. For a list what is already done in MySQL 4.1, see section 1.5.2.1 Features Available in MySQL 4.1.

1.6.2 New Features Planned for 5.0

The following features are planned for inclusion into MySQL 5.0. Some of the features such as stored procedures are complete and are included in MySQL 5.0 alpha, which is available now. Others such as cursors are only partially available. Expect these and other features to mature and be fully supported in upcoming releases.

Note that because we have many developers that are working on different projects, there will also be many additional features. There is also a small chance that some of these features will be added to MySQL 4.1. For a list what is already done in MySQL 4.1, see section 1.5.2.1 Features Available in MySQL 4.1.

For those wishing to take a look at the bleeding edge of MySQL development, we make our BitKeeper repository for MySQL version 5.0 publicly available. See section 2.3.3 Installing from the Development Source Tree. As of December 2003, binary builds of version 5.0 are also available.

Stored Procedures
New functionality
Standards compliance, portability and migration
Speed enhancements
Usability enhancements

The news section of this manual includes a more in-depth list of features. See section C.1 Changes in release 5.0.x (Development).

1.6.3 New Features Planned for 5.1

New functionality
Speed enhancements
Usability enhancements

1.6.4 New Features Planned for the Near Future

New functionality
Standards compliance, portability and migration
Speed enhancements
Internationalization
Usability enhancements
New operating systems

1.6.5 New Features Planned for the Mid-Term Future

1.6.6 New Features We Don't Plan to Implement

We aim toward full compliance with ANSI/ISO SQL, so there are no features we plan not to implement.

1.7 MySQL Information Sources

1.7.1 MySQL Mailing Lists

This section introduces you to the MySQL mailing lists and provides some guidelines as to how the lists should be used. When you subscribe to a mailing list, you will receive all postings to the list as email messages. You can also to send your own questions and answers to the list.

1.7.1.1 The MySQL Mailing Lists

To subscribe to or unsubscribe from any of the mailing lists described in this section, visit http://lists.mysql.com/. 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.
mysql-digest
This is the mysql list in digest form. Subscribing to this list means you will get all list messages, sent as one large mail message once a day.
bugs
This list will be of interest to you if you want to stay informed about issues reported since the last release of MySQL or if you want to be actively involved in the process of bug hunting and fixing. See section 1.7.1.3 How to Report Bugs or Problems.
bugs-digest
This is the bugs list in digest form.
internals
This list is for people who work on the MySQL code. This is also the forum for discussions on MySQL development and post patches.
internals-digest
This is the internals list in digest form.
mysqldoc
This list is for people who work on the MySQL documentation: people from MySQL AB, translators, and other community members.
mysqldoc-digest
This is the mysqldoc list in digest form.
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.
benchmarks-digest
This is the benchmarks list in digest form.
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.
packagers-digest
This is the packagers list in digest form.
java
This list is for discussions about the MySQL server and Java. It is mostly used to discuss JDBC drivers, including MySQL Connector/J.
java-digest
This is the java list in digest form.
win32
This list is for all topics concerning the MySQL software on Microsoft operating systems, such as Windows 9x, Me, NT, 2000, and XP.
win32-digest
This is the win32 list in digest form.
myodbc
This list is for all topics concerning connecting to the MySQL server with ODBC.
myodbc-digest
This is the myodbc list in digest form.
mysqlcc
This list is for all topics concerning the MySQL Control Center graphical client.
mysqlcc-digest
This is the mysqlcc list in digest form.
plusplus
This list is for all topics concerning programming with the C++ API to MySQL.
plusplus-digest
This is the plusplus list in digest form.
msql-mysql-modules
This list is for all topics concerning the Perl support for MySQL with msql-mysql-modules, which is now named DBD::mysql.
msql-mysql-modules-digest
This is the msql-mysql-modules list in digest form.

If you're unable to get an answer to your questions from a MySQL mailing list, one option is to purchase support from MySQL AB. This will put you in direct contact with MySQL developers. See section 1.4.1 Support Offered by MySQL AB.

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.
list@tinc.net
A Korean mailing list. Email subscribe mysql your@email.address to this list.
mysql-de-request@lists.4t2.com
A German mailing list. 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. Email subscribe mysql-br your@email.address to this list.
mysql-alta@elistas.net
A Spanish mailing list. Email subscribe mysql your@email.address to this list.

1.7.1.2 Asking Questions or Reporting Bugs

Before posting a bug report or question, please do the following:

If you can't find an answer in the manual or the archives, check with your local MySQL expert. If you still can't find an answer to your question, please follow the guidelines on sending mail to a MySQL mailing list, outlined in the next section, before contacting us.

1.7.1.3 How to Report Bugs or Problems

The normal place to report bugs is 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 will also be able to enter new reports.

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 will help you write your report correctly so that you don't waste your time doing things that may not help us much or at all.

We encourage everyone to use the mysqlbug script to generate a bug report (or a report about any problem). mysqlbug can be found in the `scripts' directory (source distribution) and in the `bin' directory under your MySQL installation directory (binary distribution). If you are unable to use mysqlbug (for example, if you are running on Windows), it is still vital that you include all the necessary information noted in this section (most importantly, a description of the operating system and the MySQL version).

The mysqlbug script 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. 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 on the included test case or by running the shell or Perl script that is included in the bug report.

All bugs posted in the bugs database at http://bugs.mysql.com/ will be corrected or documented in the next MySQL release. If only minor code changes are needed to correct a problem, we will also post a patch that fixes the problem.

If you have found a sensitive security bug in MySQL, please send an email to security@mysql.com.

If you have a repeatable bug report, please report it to the bugs database at http://bugs.mysql.com/. Note that even in this case it's good to run the mysqlbug script first to find information about your system. Any bug that we are able to repeat has a high chance of being fixed in the next MySQL release.

To report other problems, you can use one of the MySQL mailing lists.

Remember that it is possible for us to respond to a message 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 is this: 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 used, and (b) not fully describing the platform on which the MySQL server is installed (including the platform type and version number). This is highly relevant information, and in 99 cases out of 100, the bug report is useless without it. 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 already been fixed in newer MySQL versions. Sometimes the error is 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 use. Note that every compiling problem should be regarded as a bug and reported accordingly.

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 D.1.6 Making a Test Case If You Experience Table Corruption.

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 using programs, it is better that the error message reported exactly matches the one that the program produces. (Even the case should be observed.) You should never try to remember what the error message was; instead, copy and paste the entire message into your report.

If you have a problem with Connector/ODBC (MyODBC), please try to generate a MyODBC trace file and send it with your report. See section 20.3.7 Reporting Problems with MyODBC.

Please remember that many of the people who will read your report will do so using an 80-column display. When generating reports or examples using the mysql command-line tool, you should therefore use the --vertical option (or the \G statement terminator) for output that would exceed the available width for such a display (for example, with the EXPLAIN SELECT statement; see the example later in this section).

Please include the following information in your report:

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.

For information on reporting bugs in MyODBC, see section 20.3.4 How to Report Problems with MyODBC.

For solutions to some common problems, see section A Problems and Common Errors.

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.

1.7.1.4 Guidelines for Answering Questions on the Mailing List

If you consider your answer to have broad interest, you may want to post it to the mailing 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.

Please don't post mail messages from your browser with HTML mode turned on. Many users don't read mail with a browser.

1.7.2 MySQL Community Support on IRC (Internet Relay Chat)

In addition to the various MySQL mailing lists, you can find experienced community people on IRC (Internet Relay Chat). These are the best networks/channels currently known to us:

If you are looking for IRC client software to connect to an IRC network, take a look at X-Chat (http://www.xchat.org/). X-Chat (GPL licensed) is available for Unix as well as for Windows platforms.

1.8 MySQL Standards Compliance

This section describes how MySQL relates to the ANSI/ISO SQL standards. MySQL Server has many extensions to the SQL standard, and here you will find out what they are and how to use them. You will also find information about functionality missing from MySQL Server, and how to work around some differences.

Our goal is to not restrict MySQL Server usability for any usage without a very good reason for doing so. Even if we don't have the resources to perform development for every possible use, we are always willing to help and offer suggestions to people who are trying to use MySQL Server in new territories.

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 in MySQL Server 4.0 is an example of this strategy. See section 14.1.3 HANDLER Syntax.)

We will 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 size databases (10-100 million rows, or about 100MB per table) on small computer systems. Today MySQL Server handles terabyte-size 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.

We are currently not targeting realtime support, although the MySQL replication capabilities already offer significant functionality.

Database cluster support is planned through integration of our acquired NDB Cluster technology into a new storage engine, available early 2004.

We are also looking at providing XML support in the database server.

1.8.1 What Standards MySQL Follows

ODBC levels 0-3.51.

We are aiming toward supporting the full ANSI/ISO SQL standard, but without making concessions to speed and quality of the code.

1.8.2 Selecting SQL Modes

The MySQL server can operate in different SQL modes, and can apply these modes differentially for different clients. This allows applications to tailor server operation to their own requirements.

Modes define what SQL syntax MySQL should support and what kind of validation checks it should perform on the data. This makes it easier to use MySQL in a lot of 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="modes" option. Beginning with MySQL 4.1, you can also change the mode after startup time by setting the sql_mode variable with a SET [SESSION|GLOBAL] sql_mode='modes' statement.

For more information on setting the server mode, see section 5.2.2 The Server SQL Mode.

1.8.3 Running MySQL in ANSI Mode

You can tell mysqld to use the ANSI mode with the --ansi startup option. See section 5.2.1 mysqld Command-Line Options.

Running the server in ANSI mode is the same as starting it with these options:

--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY
--transaction-isolation=SERIALIZABLE

In MySQL 4.1, you can achieve the same effect with these two statements:

SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET GLOBAL sql_mode =
  'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY';

See section 1.8.2 Selecting SQL Modes.

In MySQL 4.1.1, the sql_mode options shown can be also be set with:

SET GLOBAL sql_mode='ansi';

In this case, the value of the sql_mode variable will be set to all options that are relevant for ANSI mode. You can check the result by doing:

mysql> SET GLOBAL sql_mode='ansi';
mysql> SELECT @@GLOBAL.sql_mode;
        -> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY,ANSI';

1.8.4 MySQL Extensions to the SQL Standard

MySQL Server includes some extensions that you probably will not find in other SQL databases. Be warned that if you use them, your code will not 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 form /*! ... */. In this case, MySQL Server will parse and execute the code within the comment as it would any other MySQL statement, but other SQL servers will ignore the extensions. For example:

SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...

If you add a version number after the '!' character, the syntax within the comment will be executed only if the MySQL version is equal to or newer than the specified version number:

CREATE /*!32302 TEMPORARY */ TABLE t (a INT);

This means that if you have Version 3.23.02 or newer, MySQL Server will use the TEMPORARY keyword.

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 tables within a database to filenames in the database directory. This has a few implications:
General language syntax
SQL statement syntax
Column types
Functions and operators

For a prioritized list indicating when new extensions will be added to MySQL Server, you should consult the online MySQL TODO list at http://dev.mysql.com/doc/mysql/en/TODO.html. That is the latest version of the TODO list in this manual. See section 1.6 MySQL and the Future (the TODO).

1.8.5 MySQL Differences Compared to Standard SQL

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:

1.8.5.1 Subqueries

MySQL Version 4.1 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 14.1.8 Subquery Syntax.

For MySQL versions older than 4.1, most subqueries can be rewritten using joins or other methods. See section 14.1.8.11 Rewriting Subqueries as Joins for Earlier MySQL Versions for examples that show how to do this.

1.8.5.2 SELECT INTO TABLE

MySQL Server doesn't support the Sybase SQL extension: SELECT ... INTO TABLE .... Instead, MySQL Server supports the standard SQL syntax INSERT INTO ... SELECT ..., which is basically the same thing. See section 14.1.4.1 INSERT ... SELECT Syntax.

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.

From version 5.0, MySQL supports SELECT ... INTO with user variables. The same syntax may also be used inside stored procedures using cursors and local variables. See section 19.1.6.3 SELECT ... INTO Statement.

1.8.5.3 Transactions and Atomic Operations

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. See section 15 MySQL 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.

With MySQL Server supporting 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 diskspace 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?

  1. 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.
  2. 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 you never will get an automatic abort from the server, which is a common problem with transactional database systems.
  3. Even a transactional system can lose data if the server goes down. The difference between different systems lies in just how small the time-lag is where they could lose data. No system is 100% secure, only ``secure enough.'' Even Oracle, reputed to be the safest of transactional database systems, is reported to sometimes lose data in such situations. To be safe with MySQL Server, whether or not using transactional tables, you only need to have backups and have binary logging turned on. With this 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, 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 will stall until any 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 new inserted records will not be seen by the client that has the read lock until it releases the lock. With INSERT DELAYED, you can queue inserts into a local queue, until the locks are released, without having the client wait for the insert to complete. See section 14.1.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 will never be an automatic rollback (which can happen with transactional tables if you are not very careful). MySQL Server also guarantees that there will not be any dirty reads.

Following are some techniques for working with non-transactional tables:

1.8.5.4 Stored Procedures and Triggers

Stored procedures are implemented in MySQL version 5.0. See section 19 Stored Procedures and Functions.

Triggers are scheduled for implementation in MySQL version 5.1. A ``trigger'' is effectively a type of stored procedure, one that is invoked when a particular event occurs. For example, you could set up a stored procedure that is triggered each time a record is deleted from a transactional table, and that stored procedure automatically deletes the corresponding customer from a customer table when all their transactions are deleted.

1.8.5.5 Foreign Keys

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 16.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:

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 table type instead, such as MyISAM. (For example, the MyISAM storage engine offers very fast performance for applications that perform only INSERT and SELECT operations, because 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:

Be aware that the use of foreign keys can in some instances lead to problems:

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 table1,table2 WHERE table1.id = table2.id;

See section 14.1.7.1 JOIN Syntax. See 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.

1.8.5.6 Views

Views are currently being implemented, and will appear in the 5.0 or 5.1 version of MySQL Server. Unnamed views (derived tables, a subquery in the FROM clause of a SELECT) are already implemented in version 4.1.

Historically, MySQL Server has been most used in applications and on Web systems where the application writer has full control over database usage. Usage has shifted over time, and so we find that an increasing number of users now regard views as an important feature.

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). One does not require views to restrict access to columns, because MySQL Server has a sophisticated privilege system. See section 5.4 The MySQL Access Privilege System.

Many DBMS don't allow updates to a view. Instead, you have to perform the updates on the individual tables. In designing an implementation of views, our goal, as much as is possible within the confines of SQL, is full compliance with ``Codd's Rule #6'' for relational database systems: All views that are theoretically updatable, should in practice also be updatable.

1.8.5.7 `--' as the Start of a Comment

Some other SQL databases use `--' to start comments. MySQL Server uses `#' as the start comment character. You can also use the C comment style /* this is a comment */ with MySQL Server. See section 10.5 Comment Syntax.

MySQL Server Version 3.23.3 and above support the `--' comment style, provided the comment is followed by a space (or by a control character such as a newline). The requirement for a space is to prevent problems with automatically generated SQL queries that have used something like the following code, where we automatically insert the value of the payment for !payment!:

UPDATE tbl_name SET credit=credit-!payment!

Think about what happens if the value of payment is a negative value such as -1:

UPDATE tbl_name SET credit=credit--1

credit--1 is a legal expression in SQL, but if -- 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 tbl_name 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 this method of commenting in MySQL Server Version 3.23.3 and up, credit--1 is actually safe.

Another safe feature is that the mysql command-line client removes all 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 program in a text file that contains `--' comments, you should use the replace utility as follows to convert the comments to use `#' characters:

shell> replace " --" " #" < text-file-with-funny-comments.sql \
         | mysql db_name

instead of the usual:

shell> mysql db_name < text-file-with-funny-comments.sql

You can also edit the command 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

1.8.6 How MySQL Deals with Constraints

MySQL allows you to work with both transactional tables that allow rollback and non-transactional tables that do not, so constraint handling is a bit different in MySQL than in other databases.

We have to handle the case when you have updated a lot of rows in a non-transactional table that cannot roll back when an error occurs.

The basic philosophy is to try to give an error for anything that we can detect at compile time but try to recover from any errors we get at runtime. We do this in most cases, but not yet for all. See section 1.6.4 New Features Planned for the Near Future.

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.

The following sections describe what happens for the different types of constraints.

1.8.6.1 Constraint PRIMARY KEY / UNIQUE

Normally you will get an error 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 will automatically roll back the transaction. If you are using a non-transactional storage engine, MySQL will stop at the incorrect row and leave any remaining rows unprocessed.

To make life easier, MySQL supports an IGNORE keyword for most commands that can cause a key violation (such as INSERT IGNORE and UPDATE IGNORE). In this case, MySQL will ignore any key violation and continue with processing the next row. You can get information about what MySQL did with the mysql_info() API function. See section 20.2.3.126 mysql_info(). In MySQL 4.1 and up, you also can use the SHOW WARNINGS statement. See section 14.5.3.20 SHOW WARNINGS Syntax.

Note that, for the moment, only InnoDB tables support foreign keys. See section 16.7.4 FOREIGN KEY Constraints. Foreign key support in MyISAM tables is scheduled for implementation in MySQL 5.1.

1.8.6.2 Constraint NOT NULL and DEFAULT Values

To be able to support easy handling of non-transactional tables, all columns in MySQL have default values.

If you insert an ``incorrect'' value in a column, such as a NULL in a NOT NULL column or a too-large numerical value in a numerical column, MySQL sets the column to the ``best possible value'' instead of producing an error. For numerical values, this is 0, the smallest possible value, or the largest possible value. For strings, this is either the empty string or the longest possible string that can be in the column.

This means that if you try to store NULL into a column that doesn't take NULL values, MySQL Server instead stores 0 or '' (the empty string). This last behavior can, for single-row inserts, be changed with the -DDONT_USE_DEFAULT_FIELDS compile option.) See section 2.3.2 Typical configure Options. This causes INSERT statements to generate an error unless you explicitly specify values for all columns that require a non-NULL value.

The reason for the preceding rules is that we can't check these conditions until the query has begun executing. We can't just roll back if we encounter a problem after updating a few rows, because the table type 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.

This means that you should generally not use MySQL to check column content. Instead, the application should ensure that is passes only legal values to MySQL.

In MySQL 5.0, we plan to improve this by providing warnings when automatic column conversions occur, plus an option to let you roll back statements that attempt to perform a disallowed column value assignment, as long as the statement uses only transactional tables.

1.8.6.3 Constraint ENUM and SET

In MySQL 4.x, ENUM is not a real constraint, but is a more efficient way to define columns that can contain only a given set of values. This is because of the same reasons NOT NULL is not honored. See section 1.8.6.2 Constraint NOT NULL and DEFAULT Values.

If you insert an incorrect value into an ENUM column, it will be set to the reserved enumeration value 0, which will be displayed as an empty string in string context. See section 12.4.3 The ENUM Type.

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'. See section 12.4.4 The SET Type.

1.8.7 Known Errors and Design Deficiencies in MySQL

1.8.7.1 Errors in 3.23 Fixed in a Later MySQL Version

The following known errors or bugs are not fixed in MySQL 3.23 because fixing them would involve changing a lot of code that could introduce other even worse bugs. The bugs are also classified as ``not fatal'' or ``bearable.''

1.8.7.2 Errors in 4.0 Fixed in a Later MySQL Version

The following known errors or bugs are not fixed in MySQL 4.0 because fixing them would involve changing a lot of code that could introduce other even worse bugs. The bugs are also classified as ``not fatal'' or ``bearable.''

1.8.7.3 Open Bugs and Design Deficiencies in MySQL

The following problems are known and fixing them is a high priority:

The following problems are known and will be fixed in due time:

The following are known bugs in earlier versions of MySQL:

For platform-specific bugs, see the sections about compiling and porting. See section 2.3 MySQL Installation Using a Source Distribution. See section D Porting to Other Systems.

2 Installing MySQL

This chapter describes how to obtain and install MySQL:

  1. 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.
  2. Choose a 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.
  3. 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.
  4. 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.3 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.5 Upgrading/Downgrading MySQL for information about upgrade procedures and about issues that you should consider before upgrading. If you encounter installation difficulties, see section 2.6 Operating System-Specific Notes for information on solving problems for particular platforms.
  5. Perform any necessary post-installation setup. After installing MySQL, read section 2.4 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.
  6. If you want to run the MySQL benchmark scripts, Perl support for MySQL must be available. See section 2.7 Perl Installation Notes.

2.1 General Installation Issues

Before installing MySQL, you should do the following:

  1. Determine whether or not MySQL runs on your platform.
  2. Choose a distribution to install.
  3. 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.

2.1.1 Operating Systems Supported by MySQL

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.

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:

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 will join the top club once the thread library is improved. We also hope that at some point we will be 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 will require 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.1 The 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.

2.1.2 Choosing Which MySQL Distribution to Install

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.

2.1.2.1 Choosing Which Version of MySQL to Install

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:

We don't 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 will not affect anything that's already 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.0. 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 don't want to take chances with 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 will be based.

The MySQL naming scheme uses release names that consist of three numbers and a suffix; for example, mysql-4.1.0-alpha. The numbers within the release name are interpreted like this:

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:

MySQL uses a naming scheme that is slightly different from most other products. In general, it's 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 22.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.

2.1.2.2 Choosing a Distribution Format

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:

Under some circumstances, you probably will be better off installing MySQL from a source distribution:

2.1.2.3 How and When Updates Are Released

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 extended email-supported customers want and try to help them out.

No one has to download a new release. The News section will tell you if the new release has something you really want. See section C MySQL Change History.

We use the following policy when updating MySQL:

2.1.2.4 Release Philosophy--No Known Bugs in Releases

We put a lot of time and effort into making our releases bug-free. To our knowledge, we have not 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 1.8.7 Known Errors and Design Deficiencies 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.

Here is a description of how our build process works:

2.1.2.5 MySQL Binaries Compiled by MySQL AB

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 of compressed tar files (.tar.gz files). See section 2.2 Standard MySQL Installation Using a Binary Distribution.

For Windows distributions, see section 2.2.1 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.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 --enable-assembler --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.6 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 OpenUnix 8.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
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-prefix=/usr/local/mysql --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 are no longer 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 2 4 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.1 The 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.

2.1.3 How to Get MySQL

Check the MySQL home page (http://www.mysql.com/) for information about the current version and for downloading instructions.

Our main mirror is located at http://mirrors.sunsite.dk/mysql/.

For a complete up-to-date list of MySQL download mirror sites, see http://dev.mysql.com/downloads/mirrors.html. There you will also find information about becoming a MySQL mirror site and how to report a bad or out-of-date mirror.

2.1.4 Verifying Package Integrity Using MD5 Checksums or GnuPG

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:

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.

2.1.4.1 Verifying the MD5 Checksum

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 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 is available from http://www.fourmilab.ch/md5/.

2.1.4.2 Signature Checking Using GnuPG

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 already 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 info 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.

2.1.4.3 Signature Checking Using RPM

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 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

2.1.5 Installation Layouts

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', which 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
`include' Include (header) files
`lib' Libraries
`/usr/share/mysql' Error message and character set files
`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:

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.

2.2 Standard MySQL Installation Using a Binary Distribution

This section covers 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.2.5 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.

2.2.1 Installing MySQL on Windows

The installation process for MySQL on Windows has the following steps:

  1. Obtain and install the distribution.
  2. Set up an option file if necessary.
  3. Select the server you want to use.
  4. Start the server.
  5. Assign passwords to the initial MySQL accounts.

MySQL for Windows is available in two distribution formats:

Generally speaking, you should use the binary distribution. It's 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.3.6 Installing MySQL from Source on Windows.

2.2.1.1 Windows System Requirements

To run MySQL on Windows, you need the following:

2.2.1.2 Installing a Windows Binary Distribution

To install MySQL on Windows using a binary distribution, follow this procedure:

  1. If you are working on a Windows NT, 2000, or XP machine, make sure that you have logged in as a user with administrator privileges.
  2. If you are doing an upgrade of an earlier MySQL installation, it is necessary to stop the current server. On Windows NT, 2000, or XP machines, if you are running the server as a Windows service, stop it as follows from the command prompt:
    C:\> NET STOP MySQL
    
    If you plan to use a different server after the upgrade (for example, if you want to run mysqld-max rather than mysqld), remove the existing service:
    C:\> C:\mysql\bin\mysqld --remove
    
    You can reinstall the service to use the proper server after upgrading. If you are not running the MySQL server as a service, stop it like this:
    C:\> C:\mysql\bin\mysqladmin -u root shutdown
    
  3. Exit the WinMySQLAdmin program if it is running.
  4. Unzip the distribution file to a temporary directory.
  5. Run the setup.exe program to begin the installation process. If you want to install MySQL into a location other than the default directory (`C:\mysql'), use the Browse button to specify your preferred directory. If you do not install MySQL into the default location, you will need to specify the location whenever you start the server. The easiest way to do this is to use an option file, as described in section 2.2.1.3 Preparing the Windows MySQL Environment.
  6. Finish the install process.

Important note: Early alpha Windows distributions for MySQL 4.1 do not contain an installer program. A 4.1 distribution is a ZIP file that you just unzip in the location where you want to install MySQL. For example, to install `mysql-4.1.1-alpha-win.zip' as `C:\mysql', unzip the distribution file on the C: drive, then rename the resulting `mysql-4.1.1-alpha' directory to `mysql'.

If you are upgrading to MySQL 4.1 from an earlier version, you will want to preserve your existing `data' directory that contains the grant tables in the mysql database and your own databases. Before installing 4.1, stop the server if it is running, and save your `data' directory to another location. Then either rename the existing `C:\mysql' directory or remove it. Install 4.1 as described in the preceding paragraph, and then replace its `data' directory with your old `data' directory. Start the new server and update the grant tables. This will avoid the loss of your current databases. See section 2.5.8 Upgrading the Grant Tables.

2.2.1.3 Preparing the Windows MySQL Environment

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 will be used every time the server starts, you will find it most convenient to use an option file to specify your MySQL configuration. This is true particularly under the following circumstances:

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 a data directory of `E:\mydata', you must do two things:

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, then in the `my.cnf' file. However, to avoid confusion, it's best if you use only one file. If your PC uses a boot loader where the C: drive isn't the boot drive, your only option is to use the `my.ini' file. Whichever one you use, it must be a plain text file.

An option file can be created and modified with any text editor, such as the Notepad program. For example, if MySQL is installed at `D:\mysql' and the data directory is located at `D:\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=D:/mysql
# set datadir to the location of your data directory
datadir=D:/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.

Another way to manage an option file is to use the WinMySQLAdmin tool. You can find WinMySQLAdmin in the `bin' directory of your MySQL installation, as well as a help file containing instructions for using it. WinMySQLAdmin has the capability of editing your option file, but note these points:

Now you are ready to start the server.

2.2.1.4 Selecting a Windows Server

Starting with MySQL 3.23.38, the Windows distribution includes both the normal and the MySQL-Max server binaries. Here is a list of the different MySQL servers from which you can choose:

Binary Description
mysqld Compiled with full debugging and automatic memory allocation checking, symbolic links, 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 symbolic links, and InnoDB and BDB tables.
mysqld-max-nt Like mysqld-max, but compiled with support for named pipes.

All of the preceding binaries are optimized for modern Intel processors, but should work on any Intel i386-class or higher processor.

MySQL supports TCP/IP on all Windows platforms. The mysqld-nt and mysql-max-nt servers support named pipes on NT, 2000, and XP. However, the default is to use TCP/IP regardless of the platform. (Named pipes are slower than TCP/IP in many Windows configurations.) Named pipe use is subject to these conditions:

Note: Most of the examples in the following sections use mysqld as the server name. If you choose to use a different server, such as mysqld-opt, make the appropriate substitutions in the commands that are shown in the examples. One good reason to choose a different server is that because mysqld contains full debugging support, it uses more memory and runs slower than the other Windows servers.

2.2.1.5 Starting the Server for the First Time

On Windows 95, 98, or Me, MySQL clients always connect to the server using TCP/IP. (This will allow 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's 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, or XP, clients have two options. They can use TCP/IP, or they can use a named pipe if the server supports named pipe connections.

For information about which server binary to run, see section 2.2.1.4 Selecting a Windows Server.

This section gives a general overview of starting the MySQL server. The following sections provide more specific information for particular versions of Windows.

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 will 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 will continue 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.4 Post-Installation Setup and Testing.

2.2.1.6 Starting MySQL from the Windows Command Line

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:\mysql\bin\mysqld

On non-NT versions of Windows, this will start 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, or XP, the server will run in the foreground and no command prompt will appear 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:\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 root, 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 doesn't 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 will write a log file `C:\mysqld.trace' that should contain the reason why mysqld doesn't start. See section D.1.2 Creating Trace Files.

Use mysqld --help to display all the options that mysqld understands!

2.2.1.7 Starting MySQL as a Windows Service

On the NT family (Windows NT, 2000, or XP), the recommended way to run MySQL is to install it as a Windows service. Then Windows starts and stops the MySQL server automatically when Windows starts and stops. A 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 Control Panel (under Administrative Tools on Windows 2000). It is advisable to close the Services utility while performing server installation or removal operations from this command line. This prevents some odd errors.

To get MySQL to work with TCP/IP on Windows NT 4, you must install service pack 3 (or newer)!

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 root, 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.

Now install the server as a service:

C:\> mysqld --install

If you have problems installing mysqld as a service using just the server name, try installing it using its full pathname:

C:\> C:\mysql\bin\mysqld --install

As of MySQL 4.0.2, you can specify a specific service name after the --install option. As of MySQL 4.0.3, you can in addition specify a --defaults-file option after the service name to indicate where the server should obtain options when it starts. The rules that determine the service name and option files the server uses are as follows:

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, avoid installing MySQL in a directory such as `C:\Program Files' or using a service name containing spaces.

In the usual case that you install the server with --install but no service name, the server is installed with a service name of MySQL.

As a more complex example, consider the following command (which should be entered on a single line):

C:\> C:\mysql\bin\mysqld --install mysql
           --defaults-file=C:\my-opts.cnf

Here, a service name 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 [mysql] group from the standard option files. (This would be a bad idea, because that option group is for use by the mysql client program.) However, because the --defaults-file option is present, the server reads options only from the named file, and only from the [mysqld] option group.

You can also specify options as ``Start parameters'' in the Windows Services utility before you start the MySQL service.

Once a MySQL server is installed as a service, Windows will start 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 doesn't 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'.

When mysqld is running as a service, it can be stopped by using the Services utility, the command NET STOP MySQL, or the command mysqladmin shutdown. If the service is running when Windows shuts down, Windows will stop the server automatically.

From MySQL version 3.23.44, you have the choice of installing the server as a Manual service if you don't 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, 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 had to perform crash recovery at the next startup.) Starting from MySQL version 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 you don't want to start mysqld as a service, you can start it from the command line the same way as for versions of Windows that are not based on NT. For instructions, see section 2.2.1.6 Starting MySQL from the Windows Command Line.

2.2.1.8 Running MySQL Client Programs on Windows

You can test whether the MySQL server is working by executing any of the following commands:

C:\> C:\mysql\bin\mysqlshow
C:\> C:\mysql\bin\mysqlshow -u root mysql
C:\> C:\mysql\bin\mysqladmin version status proc
C:\> 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 should use the --protocol=PIPE option.

There are two versions of the MySQL command-line tool:
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.

If you want to use mysqlc, you must have a copy of the `cygwinb19.dll' library installed somewhere that mysqlc can find it. Current distributions of MySQL include this library in the same directory as mysqlc (the `bin' directory under the base directory of your MySQL installation). If your distribution does not have the cygwinb19.dll library in the `bin' directory, look for it in the lib directory and copy it to your Windows system directory (`\Windows\system' or a similar place).

2.2.1.9 MySQL on Windows Compared to MySQL on Unix

MySQL for Windows has by now proven itself to be very stable. The Windows version of MySQL has the same features as the corresponding Unix version, with the following exceptions:

Windows 95 and threads
Windows 95 leaks about 200 bytes of main memory for each thread creation. Each connection in MySQL creates a new thread, so you shouldn't run mysqld for an extended time on Windows 95 if your server handles many connections! Other versions of Windows don't suffer from this bug.
Limited number of ports
Windows systems have about 4,000 ports available for client connections, and after a connection on a port closes, it takes two to four minutes before the port can be reused. In situations where clients connect to and disconnect from the server at a high rate, it is possible for all available ports to be used up before closed ports become available again. If this happens, the MySQL server will appear to have become unresponsive even though it is running. Note that ports may be used by other applications running on the machine as well, in which case the number of ports available to MySQL is lower.
Concurrent reads
MySQL depends on the pread() and pwrite() calls to be able to mix INSERT and SELECT. Currently we use mutexes to emulate pread()/pwrite(). We will, in the long run, replace the file level interface with a virtual interface so that we can use the readfile()/writefile() interface on NT, 2000, and XP to get more speed. The current implementation limits the number of open files MySQL can use to 1,024, which means that you will not be able to run as many concurrent threads on NT, 2000, and XP as on Unix.
Blocking read
MySQL uses a blocking read for each connection, which has the following implications: We plan to fix this problem when our Windows developers have figured out a nice workaround.
ALTER TABLE
While you are executing an ALTER TABLE statement, the table is locked from being used by other threads. This has to do with the fact that on Windows, you can't delete a file that is in use by another thread. In the future, we may find some way to work around this problem.
DROP TABLE
DROP TABLE on a table that is in use by a MERGE table will not work on Windows because the MERGE handler does the table mapping hidden from the upper layer of MySQL. Because Windows doesn't allow you to drop files that are open, you first must flush all MERGE tables (with FLUSH TABLES) or drop the MERGE table before dropping the table. We will fix this at the same time we introduce views.
DATA DIRECTORY and INDEX DIRECTORY
The DATA DIRECTORY and INDEX DIRECTORY options for CREATE TABLE are ignored on Windows, because Windows doesn't support symbolic links. These options also are ignored on systems that have a non-functional realpath() call.
DROP DATABASE
You cannot drop a database that is in use by some thread.
Killing MySQL from the Task Manager
You cannot kill MySQL from the Task Manager or with the shutdown utility in Windows 95. You must take it down with mysqladmin shutdown.
Case-insensitive names
Filenames are not case sensitive on Windows, so MySQL database and table names are also not case sensitive on Windows. The only restriction is that database and table names must be specified using the same case throughout a given statement. See section 10.2.2 Identifier Case Sensitivity.
The `\' pathname separator character
Pathname components in Windows 95 are separated by the `\' character, which is also the escape character in MySQL. If you are using LOAD DATA INFILE or SELECT ... INTO OUTFILE, use Unix-style filenames with `/' characters:
mysql> LOAD DATA INFILE 'C:/tmp/skr.txt' INTO TABLE skr;
mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
Alternatively, you must double the `\' character:
mysql> LOAD DATA INFILE 'C:\\tmp\\skr.txt' INTO TABLE skr;
mysql> SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;
Problems with pipes.
Pipes do not work reliably from the Windows command-line prompt. If the pipe includes the character ^Z / CHAR(24), Windows will think it has encountered end-of-file and abort the program. This is mainly a problem when you try to apply a binary log as follows:
C:\> mysqlbinlog binary-log-name | mysql --user=root
If you get a problem applying the log and suspect that it is because of a ^Z / CHAR(24), character you can use the following workaround:
C:\> mysqlbinlog binary-log-file --result-file=/tmp/bin.sql
C:\> mysql --user=root --execute "source /tmp/bin.sql"
The latter command also can be used to reliably read in any SQL file that may contain binary data.
Can't open named pipe error
If you use a MySQL 3.22 server on Windows NT with the newest MySQL client programs, you will get the following error:
error 2017: can't open named pipe to host: . pipe...
This happens because the release version of MySQL uses named pipes on NT by default. You can avoid this error by using the --host=localhost option to the new MySQL clients or create an option file `C:\my.cnf' that contains the following information:
[client]
host = localhost
Starting from 3.23.50, named pipes are enabled only if mysqld-nt or mysqld-max-nt is started with --enable-named-pipe.
Access denied for user error
If you attempt to run a MySQL client program to connect to a server running on the same machine, but get the error Access denied for user: 'some-user@unknown' to database 'mysql', this means that MySQL cannot resolve your hostname properly. To fix this, you should create a file named `\windows\hosts' containing with the following information:
127.0.0.1       localhost

Here are some open issues for anyone who might want to help us improve MySQL on Windows:

2.2.2 Installing MySQL on Linux

The recommended way to install MySQL on Linux is by using the RPM packages. The MySQL RPMs are currently built on a SuSE Linux 7.3 system, but should work on most versions of Linux that support rpm and use glibc. To obtain RPM packages, see section 2.1.3 How to Get MySQL.

Note: RPM distributions of MySQL often are provided by other vendors. Be aware that they may differ in features and capabilities from those built by MySQL AB, and that the instructions in this manual do not necessarily apply to installing them. The vendor's instructions should be consulted instead.

If you have problems with an RPM file (for example, if you receive the error ``Sorry, the host 'xxxx' could not be looked up''), see section 2.6.1.2 Linux Binary Distribution Notes.

In most cases, you only need to install the MySQL-server and MySQL-client packages to get a functional MySQL installation. The other packages are not required for a standard installation. If you want to run a MySQL-Max server that has additional capabilities, you should also install the MySQL-Max RPM. However, you should do so only after installing the MySQL-server RPM. See section 5.1.2 The mysqld-max Extended MySQL Server.

If you get a dependency failure when trying to install the MySQL 4.0 packages (for example, ``error: removing these packages would break dependencies: libmysqlclient.so.10 is needed by ...''), you should also install the package MySQL-shared-compat, which includes both the shared libraries for backward compatibility (libmysqlclient.so.12 for MySQL 4.0 and libmysqlclient.so.10 for MySQL 3.23).

Many Linux distributions still ship with MySQL 3.23 and they usually link applications dynamically to save disk space. If these shared libraries are in a separate package (for example, MySQL-shared), it is sufficient to simply leave this package installed and just upgrade the MySQL server and client packages (which are statically linked and do not depend on the shared libraries). For distributions that include the shared libraries in the same package as the MySQL server (for example, Red Hat Linux), you could either install our 3.23 MySQL-shared RPM, or use the MySQL-shared-compat package instead.

The following RPM packages are available:

To see all files in an RPM package (for example, a MySQL-server RPM), run:

shell> rpm -qpl MySQL-server-VERSION.i386.rpm

To perform a standard minimal installation, run:

shell> rpm -i MySQL-server-VERSION.i386.rpm
shell> rpm -i MySQL-client-VERSION.i386.rpm

To install just the client package, run:

shell> rpm -i MySQL-client-VERSION.i386.rpm

RPM provides a feature to verify the integrity and authenticity of packages before installing them. If you would like to learn more about this feature, see section 2.1.4 Verifying Package Integrity Using MD5 Checksums or GnuPG.

The server RPM places data under the `/var/lib/mysql' directory. The RPM also creates a login account for a user named mysql (if one does not already exist) to use for running the MySQL server, and creates the appropriate entries in `/etc/init.d/' to start the server automatically at boot time. (This means that if you have performed a previous installation and have made changes to its startup script, you may want to make a copy of the script so that you don't lose it when you install a newer RPM.) See section 2.4.2.2 Starting and Stopping MySQL Automatically for more information on how MySQL can be started automatically on system startup.

If you want to install the MySQL RPM on older Linux distributions that do not support initialization scripts in `/etc/init.d' (directly or via a symlink), you should create a symbolic link that points to the location where your initialization scripts actually are installed. For example, if that location is `/etc/rc.d/init.d', use these commands before installing the RPM to create `/etc/init.d' as a symbolic link that points there:

shell> cd /etc
shell> ln -s rc.d/init.d .

However, all current major Linux distributions should already support the new directory layout that uses `/etc/init.d', because it is required for LSB (Linux Standard Base) compliance.

If the RPM files that you install include MySQL-server, the mysqld server should be up and running after installation. You should now be able to start using MySQL.

If something goes wrong, you can find more information in the binary installation section. See section 2.2.5 Installing MySQL on Other Unix-Like Systems.

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.4 Post-Installation Setup and Testing.

2.2.3 Installing MySQL on Mac OS X

Beginning with MySQL 4.0.11, you can install MySQL on Mac OS X 10.2.x (``Jaguar'') and up using a Mac OS X binary package in PKG format instead of the binary tarball distribution. Please note that older versions of Mac OS X (for example, 10.1.x) are not supported by this package.

The package is located inside a disk image (.dmg) file that you first need to mount by double-clicking its icon in the Finder. It should then mount the image and display its contents.

To obtain MySQL, see section 2.1.3 How to Get MySQL.

Note: Before proceeding with the installation, be sure to shut down all running MySQL server instances by either using the MySQL Manager Application (on Mac OS X Server) or via mysqladmin shutdown on the command line.

To actually install the MySQL PKG file, double-click on the package icon. This launches the Mac OS X Package Installer, which will guide you through the installation of MySQL.

Due to a bug in the Mac OS X package installer, you may sometimes see this error message in the destination disk selection dialog:

You cannot install this software on this disk. (null)

If this error occurs, simply click the Go Back button once to return to the previous screen. Then click Continue to advance to the destination disk selection again, and you should be able to choose the destination disk correctly. We have reported this bug to Apple and it is investigating this problem.

The Mac OS X PKG of MySQL will install itself into `/usr/local/mysql-VERSION' and will also install a symbolic link, `/usr/local/mysql', pointing to the new location. If a directory named `/usr/local/mysql' already exists, it will be renamed to `/usr/local/mysql.bak' first. Additionally, it will install the grant tables in the mysql database by executing mysql_install_db after the installation.

The installation layout is similar to that of a tar file binary distribution; all MySQL binaries are located in the directory `/usr/local/mysql/bin'. The MySQL socket file is created as `/tmp/mysql.sock' by default. See section 2.1.5 Installation Layouts.

MySQL installation requires a Mac OS X user account named mysql. A user account with this name should exist by default on Mac OS X 10.2 and up.

If you are running Mac OS X Server, you already have a version of MySQL installed. The versions of MySQL that ship with Mac OS X Server versions are shown in the following table:

Mac OS X Server Version MySQL Version
10.2-10.2.2 3.23.51
10.2.3-10.2.6 3.23.53
10.3 4.0.14
10.3.2 4.0.16

This manual section covers the installation of the official MySQL Mac OS X PKG only. Make sure to read Apple's help information about installing MySQL: Run the ``Help View'' application, select ``Mac OS X Server'' help, do a search for ``MySQL,'' and read the item entitled ``Installing MySQL.''

For pre-installed versions of MySQL on Mac OS X Server, note especially that you should start mysqld with safe_mysqld instead of mysqld_safe if MySQL is older than version 4.0.

If you previously used Marc Liyanage's MySQL packages for Mac OS X from http://www.entropy.ch, you can simply follow the update instructions for packages using the binary installation layout as given on his pages.

If you are upgrading from Marc's 3.23.xx versions or from the Mac OS X Server version of MySQL to the official MySQL PKG, you also need to convert the existing MySQL privilege tables to the current format, because some new security privileges have been added. See section 2.5.8 Upgrading the Grant Tables.

If you would like to automatically start up MySQL during system startup, you also need to install the MySQL Startup Item. Starting with MySQL 4.0.15, it is part of the Mac OS X installation disk images as a separate installation package. Simply double-click the MySQLStartupItem.pkg icon and follow the instructions to install it.

Note that the Startup Item need be installed only once! There is no need to install it each time you upgrade the MySQL package later.

The Startup Item will be installed into `/Library/StartupItems/MySQLCOM'. (Before MySQL 4.1.2, the location was `/Library/StartupItems/MySQL', but that collided with the MySQL Startup Item installed by Mac OS X Server). Startup Item installation adds a variable MYSQLCOM=-YES- to the system configuration file `/etc/hostconfig'. If you would like to disable the automatic startup of MySQL, simply change this variable to MYSQLCOM=-NO-.

On Mac OS X Server, the default MySQL installation uses the variable MYSQL in the `/etc/hostconfig' file. The MySQL AB Startup Item installer disables this variable by setting it to MYSQL=-NO-. This avoids boot time conflicts with the MYSQLCOM variable used by the MySQL AB Startup Item. However, it does not shut down an already running MySQL server. You should do that yourself.

After the installation, you can start up MySQL by running the following commands in a terminal window. You must have administrator privileges to perform this task.

If you have installed the Startup Item:

shell> sudo /Library/StartupItems/MySQLCOM/MySQL start
(Enter your password, if necessary)
(Press Control-D or enter "exit" to exit the shell)

For versions of MySQL older than 4.1.2, substitute /Library/StartupItems/MySQLCOM/MySQL with /Library/StartupItems/MySQL/MySQL above.

If you don't use the Startup Item, enter the following command sequence:

shell> cd /usr/local/mysql
shell> sudo ./bin/mysqld_safe
(Enter your password, if necessary)
(Press Control-Z)
shell> bg
(Press Control-D or enter "exit" to exit the shell)

You should now be able to connect to the MySQL server, for example, by running `/usr/local/mysql/bin/mysql'.

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.4 Post-Installation Setup and Testing.

You might want to add aliases to your shell's resource file to make it easier to access commonly used programs such as mysql and mysqladmin from the command line. The syntax for tcsh is:

alias mysql /usr/local/mysql/bin/mysql
alias mysqladmin /usr/local/mysql/bin/mysqladmin

For bash, use:

alias mysql=/usr/local/mysql/bin/mysql
alias mysqladmin=/usr/local/mysql/bin/mysqladmin

Even better, add /usr/local/mysql/bin to your PATH environment variable. For example, add the following line to your `$HOME/.tcshrc' file if your shell is tcsh:

setenv PATH ${PATH}:/usr/local/mysql/bin

If no `.tcshrc' file exists in your home directory, create it with a text editor.

If you are upgrading an existing installation, please note that installing a new MySQL PKG does not remove the directory of an older installation. Unfortunately, the Mac OS X Installer does not yet offer the functionality required to properly upgrade previously installed packages.

To use your existing databases with the new installation, you'll need to copy the contents of the old data directory to the new data directory. Make sure that neither the old server nor the new one is running when you do this. After you have copied over the MySQL database files from the previous installation and have successfully started the new server, you should consider removing the old installation files to save disk space. Additionally, you should also remove older versions of the Package Receipt directories located in `/Library/Receipts/mysql-VERSION.pkg'.

2.2.4 Installing MySQL on NetWare

Porting MySQL to NetWare was an effort spearheaded by Novell. Novell customers will be pleased to note that NetWare 6.5 ships with bundled MySQL binaries, complete with an automatic commercial use license for all servers running that version of NetWare.

MySQL for NetWare is compiled using a combination of Metrowerks CodeWarrior for NetWare and special cross-compilation versions of the GNU autotools.

The latest binary packages for NetWare can be obtained at http://dev.mysql.com/downloads/. See section 2.1.3 How to Get MySQL.

In order to host MySQL, the NetWare server must meet these requirements:

To install MySQL for NetWare, use the following procedure:

  1. If you are upgrading from a prior installation, stop the MySQL server. This is done from the server console, using the following command:
    SERVER:  mysqladmin -u root shutdown
    
  2. Log on to the target server from a client machine with access to the location where you will install MySQL.
  3. Extract the binary package Zip file onto the server. Be sure to allow the paths in the Zip file to be used. It is safe to simply extract the file to `SYS:\'. If you are upgrading from a prior installation, you may need to copy the data directory (for example, `SYS:MYSQL\DATA') now, as well as `my.cnf', if you have customized it. You can then delete the old copy of MySQL.
  4. You might want to rename the directory to something more consistent and easy to use. We recommend using `SYS:MYSQL'; examples in this manual use this name to refer to the installation directory in general.
  5. At the server console, add a search path for the directory containing the MySQL NLMs. For example:
    SERVER:  SEARCH ADD SYS:MYSQL\BIN
    
  6. Initialize the data directory and the grant tables, if needed, by executing mysql_install_db at the server console.
  7. Start the MySQL server using mysqld_safe at the server console.
  8. To finish the installation, you should also add the following commands to autoexec.ncf. For example, if your MySQL installation is in `SYS:MYSQL' and you want MySQL to start automatically, you could add these lines:
    #Starts the MySQL 4.0.x database server
    SEARCH ADD SYS:MYSQL\BIN
    MYSQLD_SAFE
    
    If you are running MySQL on NetWare 6.0, we strongly suggest that you use the --skip-external-locking option on the command line:
    #Starts the MySQL 4.0.x database server
    SEARCH ADD SYS:MYSQL\BIN
    MYSQLD_SAFE --skip-external-locking
    
    It will also be necessary to use CHECK TABLE and REPAIR TABLE instead of myisamchk, because myisamchk makes use of external locking. External locking is known to have problems on NetWare 6.0; the problem has been eliminated in NetWare 6.5. mysqld_safe on NetWare provides a screen presence. When you unload (shut down) the mysqld_safe NLM, the screen does not by default go away. Instead, it prompts for user input:
    *<NLM has terminated; Press any key to close the screen>*
    
    If you want NetWare to close the screen automatically instead, use the --autoclose option to mysqld_safe. For example:
    #Starts the MySQL 4.0.x database server
    SEARCH ADD SYS:MYSQL\BIN
    MYSQLD_SAFE --autoclose
    

The behavior of mysqld_safe on NetWare is described further in section 5.1.3 The mysqld_safe Server Startup Script.

If there was an existing installation of MySQL on the server, be sure to check for existing MySQL startup commands in autoexec.ncf, and edit or delete them as necessary.

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.4 Post-Installation Setup and Testing.

2.2.5 Installing MySQL on Other Unix-Like Systems

This section covers the installation of MySQL binary distributions that are provided for various platforms in the form of compressed tar files (files with a .tar.gz extension). See section 2.1.2.5 MySQL Binaries Compiled by MySQL AB for a detailed list.

MySQL tar file binary distributions have names of the form `mysql-VERSION-OS.tar.gz', where VERSION is a number (for example, 4.0.17), and OS indicates the type of operating system for which the distribution is intended (for example, pc-linux-gnu-i586).

In addition to these generic packages, we also offer binaries in platform-specific package formats for selected platforms. See section 2.2 Standard MySQL Installation Using a Binary Distribution for more information on how to install these.

To obtain MySQL, see section 2.1.3 How to Get MySQL.

You need the following tools to install a MySQL tar file binary distribution:

If you run into problems, please always use mysqlbug when posting questions to a MySQL mailing list. Even if the problem isn't a bug, mysqlbug gathers system information that will help others solve your problem. By not using mysqlbug, you lessen the likelihood of getting a solution to your problem. You will find mysqlbug in the `bin' directory after you unpack the distribution. See section 1.7.1.3 How to Report Bugs or Problems.

The basic commands you must execute to install and use a MySQL binary distribution are:

shell> groupadd mysql
shell> useradd -g mysql mysql
shell> cd /usr/local
shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell> ln -s full-path-to-mysql-VERSION-OS mysql
shell> cd mysql
shell> scripts/mysql_install_db --user=mysql
shell> chown -R root  .
shell> chown -R mysql data
shell> chgrp -R mysql .
shell> bin/mysqld_safe --user=mysql &

For versions of MySQL older than 4.0, substitute bin/safe_mysqld for bin/mysqld_safe in the final command.

Note: This procedure does not set up any passwords for MySQL accounts. After following the procedure, proceed to section 2.4 Post-Installation Setup and Testing, for post-installation setup and testing.

A more detailed version of the preceding description for installing a binary distribution follows:

  1. Add a login user and group for mysqld to run as:
    shell> groupadd mysql
    shell> useradd -g mysql mysql
    
    These commands add the mysql group and the mysql user. The syntax for useradd and groupadd may differ slightly on different versions of Unix. They may also be called adduser and addgroup. You might want to call the user and group something else instead of mysql. If so, substitute the appropriate name in the following steps.
  2. Pick the directory under which you want to unpack the distribution, and change location into it. In the following example, we unpack the distribution under `/usr/local' (The instructions, therefore, assume that you have permission to create files and directories in `/usr/local'. If that directory is protected, you will need to perform the installation as root.)
    shell> cd /usr/local
    
  3. Obtain a distribution file from one of the sites listed in section 2.1.3 How to Get MySQL. For a given release, binary distributions for all platforms are built from the same MySQL source distribution.
  4. Unpack the distribution, which will create the installation directory. Then create a symbolic link to that directory:
    shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
    shell> ln -s full-path-to-mysql-VERSION-OS mysql
    
    The tar command creates a directory named `mysql-VERSION-OS'. The ln command makes a symbolic link to that directory. This lets you refer more easily to the installation directory as `/usr/local/mysql'. With GNU tar, no separate invocation of gunzip is necessary. You can replace the first line with the following alternative command to uncompress and extract the distribution:
    shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
    
  5. Change location into the installation directory:
    shell> cd mysql
    
    You will find several files and subdirectories in the mysql directory. The most important for installation purposes are the `bin' and `scripts' subdirectories.
    `bin'
    This directory contains client programs and the server. You should add the full pathname of this directory to your PATH environment variable so that your shell finds the MySQL programs properly. See section E Environment Variables.
    `scripts'
    This directory contains the mysql_install_db script used to initialize the mysql database containing the grant tables that store the server access permissions.
  6. If you haven't installed MySQL before, you must create the MySQL grant tables:
    shell> scripts/mysql_install_db --user=mysql
    
    If you run the command as root, you should use the --user option as shown. The value of the option should be the name of the login account that you created in the first step to use for running the server. If you run the command while logged in as that user, you can omit the --user option. Note that for MySQL versions older than 3.22.10, mysql_install_db left the server running after creating the grant tables. This is no longer true; you will need to restart the server after performing the remaining steps in this procedure.
  7. Change ownership of program binaries to root and ownership of the data directory to the user that you will run mysqld as. Assuming that you are located in the installation directory (`/usr/local/mysql'), the commands look like this:
    shell> chown -R root  .
    shell> chown -R mysql data
    shell> chgrp -R mysql .
    
    The first command changes the owner attribute of the files to the root user. The second changes the owner attribute of the data directory to the mysql user. The third changes the group attribute to the mysql group.
  8. If you would like MySQL to start automatically when you boot your machine, you can copy support-files/mysql.server to the location where your system has its startup files. More information can be found in the support-files/mysql.server script itself and in section 2.4.2.2 Starting and Stopping MySQL Automatically.
  9. You can set up new accounts using the bin/mysql_setpermission script if you install the DBI and DBD::mysql Perl modules. For instructions, see section 2.7 Perl Installation Notes.
  10. If you would like to use mysqlaccess and have the MySQL distribution in some non-standard place, you must change the location where mysqlaccess expects to find the mysql client. Edit the `bin/mysqlaccess' script at approximately line 18. Search for a line that looks like this:
    $MYSQL     = '/usr/local/bin/mysql';    # path to mysql executable
    
    Change the path to reflect the location where mysql actually is stored on your system. If you do not do this, you will get a Broken pipe error when you run mysqlaccess.

After everything has been unpacked and installed, you should test your distribution.

You can start the MySQL server with the following command:

shell> bin/mysqld_safe --user=mysql &

For versions of MySQL older than 4.0, substitute bin/safe_mysqld for bin/mysqld_safe in the command.

More information about mysqld_safe is given in section 5.1.3 The mysqld_safe Server Startup Script.

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.4 Post-Installation Setup and Testing.

2.3 MySQL Installation Using a Source Distribution

Before you proceed with the source installation, check first to see whether our binary is available for your platform and whether it will work for you. We put a lot of effort into making sure that our binaries are built with the best possible options.

To obtain a source distribution for MySQL, section 2.1.3 How to Get MySQL.

MySQL source distributions are provided as compressed tar archives and have names of the form `mysql-VERSION.tar.gz', where VERSION is a number like 4.0.20.

You need the following tools to build and install MySQL from source:

If you are using a recent version of gcc, recent enough to understand the -fno-exceptions option, it is very important that you use it. Otherwise, you may compile a binary that crashes randomly. We also recommend that you use -felide-constructors and -fno-rtti along with -fno-exceptions. When in doubt, do the following:

CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors \
       -fno-exceptions -fno-rtti" ./configure \
       --prefix=/usr/local/mysql --enable-assembler \
       --with-mysqld-ldflags=-all-static

On most systems, this will give you a fast and stable binary.

If you run into problems, please always use mysqlbug when posting questions to a MySQL mailing list. Even if the problem isn't a bug, mysqlbug gathers system information that will help others solve your problem. By not using mysqlbug, you lessen the likelihood of getting a solution to your problem. You will find mysqlbug in the `scripts' directory after you unpack the distribution. See section 1.7.1.3 How to Report Bugs or Problems.

2.3.1 Source Installation Overview

The basic commands you must execute to install a MySQL source distribution are:

shell> groupadd mysql
shell> useradd -g mysql mysql
shell> gunzip < mysql-VERSION.tar.gz | tar -xvf -
shell> cd mysql-VERSION
shell> ./configure --prefix=/usr/local/mysql
shell> make
shell> make install
shell> cp support-files/my-medium.cnf /etc/my.cnf
shell> cd /usr/local/mysql
shell> bin/mysql_install_db --user=mysql
shell> chown -R root  .
shell> chown -R mysql var
shell> chgrp -R mysql .
shell> bin/mysqld_safe --user=mysql &

For versions of MySQL older than 4.0, substitute bin/safe_mysqld for bin/mysqld_safe in the final command.

If you start from a source RPM, do the following:

shell> rpm --rebuild --clean MySQL-VERSION.src.rpm

This will make a binary RPM that you can install.

Note: This procedure does not set up any passwords for MySQL accounts. After following the procedure, proceed to section 2.4 Post-Installation Setup and Testing, for post-installation setup and testing.

A more detailed version of the preceding description for installing MySQL from a source distribution follows:

  1. Add a login user and group for mysqld to run as:
    shell> groupadd mysql
    shell> useradd -g mysql mysql
    
    These commands add the mysql group and the mysql user. The syntax for useradd and groupadd may differ slightly on different versions of Unix. They may also be called adduser and addgroup. You might want to call the user and group something else instead of mysql. If so, substitute the appropriate name in the following steps.
  2. Pick the directory under which you want to unpack the distribution, and move into it.
  3. Obtain a distribution file from one of the sites listed in section 2.1.3 How to Get MySQL.
  4. Unpack the distribution into the current directory:
    shell> gunzip < /path/to/mysql-VERSION.tar.gz | tar xvf -
    
    This command creates a directory named `mysql-VERSION'. With GNU tar, no separate invocation of gunzip is necessary. You can use the following alternative command to uncompress and extract the distribution:
    shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
    
  5. Change location into the top-level directory of the unpacked distribution:
    shell> cd mysql-VERSION
    
    Note that currently you must configure and build MySQL from this top-level directory. You cannot build it in a different directory.
  6. Configure the release and compile everything:
    shell> ./configure --prefix=/usr/local/mysql
    shell> make
    
    When you run configure, you might want to specify some options. Run ./configure --help for a list of options. section 2.3.2 Typical configure Options, discusses some of the more useful options. If configure fails and you are going to send mail to a MySQL mailing list to ask for assistance, please include any lines from `config.log' that you think can help solve the problem. Also include the last couple of lines of output from configure. Post the bug report using the mysqlbug script. See section 1.7.1.3 How to Report Bugs or Problems. If the compile fails, see section 2.3.4 Dealing with Problems Compiling MySQL, for help.
  7. Install the distribution:
    shell> make install
    
    If you want to set up an option file, use one of those present in the `support-files' directory as a template. For example:
    shell> cp support-files/my-medium.cnf /etc/my.cnf
    
    You might need to run these commands as root. If you want to configure support for InnoDB tables, you should edit the /etc/my.cnf file, remove the # character before the option lines that start with innodb_..., and modify the option values to be what you want. See section 4.3.2 Using Option Files and section 16.4 InnoDB Configuration.
  8. Change location into the installation directory:
    shell> cd /usr/local/mysql
    
  9. If you haven't installed MySQL before, you must create the MySQL grant tables:
    shell> bin/mysql_install_db --user=mysql
    
    If you run the command as root, you should use the --user option as shown. The value of the option should be the name of the login account that you created in the first step to use for running the server. If you run the command while logged in as that user, you can omit the --user option. Note that for MySQL versions older than 3.22.10, mysql_install_db left the server running after creating the grant tables. This is no longer true; you will need to restart the server after performing the remaining steps in this procedure.
  10. Change ownership of binaries to root and ownership of the data directory to the user that you will run mysqld as. Assuming that you are located in the installation directory (`/usr/local/mysql'), the commands look like this:
    shell> chown -R root  .
    shell> chown -R mysql var
    shell> chgrp -R mysql .
    
    The first command changes the owner attribute of the files to the root user. The second changes the owner attribute of the data directory to the mysql user. The third changes the group attribute to the mysql group.
  11. If you would like MySQL to start automatically when you boot your machine, you can copy support-files/mysql.server to the location where your system has its startup files. More information can be found in the support-files/mysql.server script itself and in section 2.4.2.2 Starting and Stopping MySQL Automatically.
  12. You can set up new accounts using the bin/mysql_setpermission script if you install the DBI and DBD::mysql Perl modules. For instructions, see section 2.7 Perl Installation Notes.

After everything has been installed, you should initialize and test your distribution using this command:

shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &

For versions of MySQL older than 4.0, substitute safe_mysqld for mysqld_safe in the command.

If that command fails immediately and prints mysqld ended, you can find some information in the file `host_name.err' in the data directory.

More information about mysqld_safe is given in section 5.1.3 The mysqld_safe Server Startup Script.

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.4 Post-Installation Setup and Testing.

2.3.2 Typical configure Options

The configure script gives you a great deal of control over how you configure a MySQL source distribution. Typically you do this using options on the configure command line. You can also affect configure using certain environment variables. See section E Environment Variables. For a list of options supported by configure, run this command:

shell> ./configure --help

Some of the more commonly used configure options are described here:

2.3.3 Installing from the Development Source Tree

Caution: You should read this section only if you are interested in helping us test our new code. If you just want to get MySQL up and running on your system, you should use a standard release distribution (either a binary or source distribution will do).

To obtain our most recent development source tree, use these instructions:

  1. Download BitKeeper from http://www.bitmover.com/cgi-bin/download.cgi. You will need Bitkeeper 3.0 or newer to access our repository.
  2. Follow the instructions to install it.
  3. After BitKeeper has been installed, first go to the directory you want to work from, and then use one of the following commands to clone the MySQL version branch of your choice: To clone the old 3.23 branch, use this command:
    shell> bk clone bk://mysql.bkbits.net/mysql-3.23 mysql-3.23
    
    To clone the 4.0 stable (production) branch, use this command:
    shell> bk clone bk://mysql.bkbits.net/mysql-4.0 mysql-4.0
    
    To clone the 4.1 alpha branch, use this command:
    shell> bk clone bk://mysql.bkbits.net/mysql-4.1 mysql-4.1
    
    To clone the 5.0 development branch, use this command:
    shell> bk clone bk://mysql.bkbits.net/mysql-5.0 mysql-5.0
    
    In the preceding examples, the source tree will be set up in the `mysql-3.23/', `mysql-4.0/', `mysql-4.1/', or `mysql-5.0/' subdirectory of your current directory. If you are behind a firewall and can only initiate HTTP connections, you can also use BitKeeper via HTTP. If you are required to use a proxy server, set the environment variable http_proxy to point to your proxy:
    shell> export http_proxy="http://your.proxy.server:8080/"
    
    Now, simply replace the bk:// with http:// when doing a clone. Example:
    shell> bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1
    
    The initial download of the source tree may take a while, depending on the speed of your connection. Please be patient.
  4. You will need GNU make, autoconf 2.53 (or newer), automake 1.5, libtool 1.5, and m4 to run the next set of commands. Even though many operating systems already come with their own implementation of make, chances are high that the compilation will fail with strange error messages. Therefore, it is highly recommended that you use GNU make (sometimes named gmake) instead. Fortunately, a large number of operating systems already ship with the GNU toolchain preinstalled or supply installable packages of these. In any case, they can also be downloaded from the following locations: If you are trying to configure MySQL 4.1 or later, you will also need GNU bison 1.75 or later. Older versions of bison may report this error:
    sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded
    
    Note: The maximum table size is not actually exceeded, the error is caused by bugs in older versions of bison. Versions of MySQL before version 4.1 may also compile with other yacc implementations (for example, BSD yacc 91.7.30). For later versions, GNU bison is required. The following example shows the typical commands required to configure a source tree. The first cd command changes location into the top-level directory of the tree; replace `mysql-4.0' with the appropriate directory name.
    shell> cd mysql-4.0
    shell> bk -r edit
    shell> aclocal; autoheader; autoconf; automake
    shell> (cd innobase; aclocal; autoheader; autoconf; automake)
    shell> (cd bdb/dist; sh s_all)
    shell> ./configure  # Add your favorite options here
    make
    
    The command lines that change directory into the `innobase' and `bdb/dist' directories are used to configure the InnoDB and Berkeley DB (BDB) storage engines. You can omit these command lines if you to not require InnoDB or BDB support. If you get some strange errors during this stage, verify that you really have libtool installed. A collection of our standard configuration scripts is located in the `BUILD/' subdirectory. You may find it more convenient to use the `BUILD/compile-pentium-debug' script than the preceding set of shell commands. To compile on a different architecture, modify the script by removing flags that are Pentium-specific.
  5. When the build is done, run make install. Be careful with this on a production machine; the command may overwrite your live release installation. If you have another installation of MySQL, we recommend that you run ./configure with different values for the --prefix, --with-tcp-port, and --unix-socket-path options than those used for your production server.
  6. Play hard with your new installation and try to make the new features crash. Start by running make test. See section 22.1.2 MySQL Test Suite.
  7. If you have gotten to the make stage and the distribution does not compile, please report it in our bugs database at http://bugs.mysql.com/. If you have installed the latest versions of the required GNU tools, and they crash trying to process our configuration files, please report that also. However, if you execute aclocal and get a command not found error or a similar problem, do not report it. Instead, make sure that all the necessary tools are installed and that your PATH variable is set correctly so that your shell can find them.
  8. After the initial bk clone operation to obtain the source tree, you should run bk pull periodically to get updates.
  9. You can examine the change history for the tree with all the diffs by using bk revtool. If you see some funny diffs or code that you have a question about, do not hesitate to send email to the MySQL internals mailing list. See section 1.7.1.1 The MySQL Mailing Lists. Also, if you think you have a better idea on how to do something, send an email message to the same address with a patch. bk diffs will produce a patch for you after you have made changes to the source. If you do not have the time to code your idea, just send a description.
  10. BitKeeper has a nice help utility that you can access via bk helptool.
  11. Please note that any commits (made via bk ci or bk citool) will trigger the posting of a message with the changeset to our internals mailing list, as well as the usual openlogging.org submission with just the changeset comments. Generally, you wouldn't need to use commit (since the public tree will not allow bk push), but rather use the bk diffs method described previously.

You can also browse changesets, comments, and source code online. For example, to browse this information for MySQL 4.1, go to http://mysql.bkbits.net:8080/mysql-4.1.

The manual is in a separate tree that can be cloned with:

shell> bk clone bk://mysql.bkbits.net/mysqldoc mysqldoc

There are also public BitKeeper trees for MySQL Control Center and Connector/ODBC. They can be cloned respectively as follows.

To clone MySQL Control center, use this command:

shell> bk clone http://mysql.bkbits.net/mysqlcc mysqlcc

To clone Connector/ODBC, use this command:

shell> bk clone http://mysql.bkbits.net/myodbc3 myodbc3

2.3.4 Dealing with Problems Compiling MySQL

All MySQL programs compile cleanly for us with no warnings on Solaris or Linux using gcc. On other systems, warnings may occur due to differences in system include files. See section 2.3.5 MIT-pthreads Notes for warnings that may occur when using MIT-pthreads. For other problems, check the following list.

The solution to many problems involves reconfiguring. If you do need to reconfigure, take note of the following:

To prevent old configuration information or object files from being used, run these commands before re-running configure:

shell> rm config.cache
shell> make clean

Alternatively, you can run make distclean.

The following list describes some of the problems when compiling MySQL that have been found to occur most often:

2.3.5 MIT-pthreads Notes

This section describes some of the issues involved in using MIT-pthreads.

On Linux, you should not use MIT-pthreads. Use the installed LinuxThreads implementation instead. See section 2.6.1 Linux Notes.

If your system does not provide native thread support, you will need to build MySQL using the MIT-pthreads package. This includes older FreeBSD systems, SunOS 4.x, Solaris 2.4 and earlier, and some others. See section 2.1.1 Operating Systems Supported by MySQL.

Beginning with MySQL 4.0.2, MIT-pthreads are no longer part of the source distribution. If you require this package, you need to download it separately from http://www.mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz

After downloading, extract this source archive into the top level of the MySQL source directory. It will create a new subdirectory mit-pthreads.

2.3.6 Installing MySQL from Source on Windows

These instructions describe how to build MySQL binaries from source for versions 4.1 and above on Windows. Instructions are provided for building binaries from a standard source distribution or from the BitKeeper tree that contains the latest development source.

Note: The instructions in this document are strictly for users who want to test MySQL on Windows from the latest source distribution or from the BitKeeper tree. For production use, MySQL AB does not advise using a MySQL server built by yourself from source. Normally, it is best to use precompiled binary distributions of MySQL that are built specifically for optimal performance on Windows by MySQL AB. Instructions for installing a binary distributions are available at section 2.2.1 Installing MySQL on Windows.

To build MySQL on Windows from source, you need the following compiler and resources available on your Windows system:

You'll also need a MySQL source distribution for Windows. There are two ways you can get a source distribution for MySQL version 4.1 and above:

  1. Obtain a source distribution packaged by MySQL AB for the particular version of MySQL in which you are interested. Prepackaged source distributions are available for released versions of MySQL and can be obtained from http://dev.mysql.com/downloads/.
  2. You can package a source distribution yourself from the latest BitKeeper developer source tree. If you plan to do this, you must create the package on a Unix system and then transfer it to your Windows system. (The reason for this is that some of the configuration and build steps require tools that work only on Unix.) The BitKeeper approach thus requires:

If you are using a Windows source distribution, you can go directly to section 2.3.6.1 Building MySQL Using VC++. To build from the BitKeeper tree, proceed to section 2.3.6.2 Creating a Windows Source Package from the Latest Development Source.

If you find something not working as expected, or you have suggestions about ways to improve the current build process on Windows, please send a message to the win32 mailing list. See section 1.7.1.1 The MySQL Mailing Lists.

2.3.6.1 Building MySQL Using VC++

Note: VC++ workspace files for MySQL 4.1 and above are compatible with Microsoft Visual Studio 6.0 and above (7.0/.NET) editions and tested by MySQL AB staff before each release.

Follow this procedure to build MySQL:

  1. Create a work directory (for example, `C:\workdir').
  2. Unpack the source distribution in the aforementioned directory using WinZip or other Windows tool that can read `.zip' files.
  3. Start the VC++ 6.0 compiler.
  4. In the File menu, select Open Workspace.
  5. Open the `mysql.dsw' workspace you find in the work directory.
  6. From the Build menu, select the Set Active Configuration menu.
  7. Click over the screen selecting mysqld - Win32 Debug and click OK.
  8. Press F7 to begin the build of the debug server, libraries, and some client applications.
  9. Compile the release versions that you want in the same way.
  10. Debug versions of the programs and libraries are placed in the `client_debug' and `lib_debug' directories. Release versions of the programs and libraries are placed in the `client_release' and `lib_release' directories. Note that if you want to build both debug and release versions, you can select the Build All option from the Build menu.
  11. Test the server. The server built using the preceding instructions will expect that the MySQL base directory and data directory are `C:\mysql' and `C:\mysql\data' by default. If you want to test your server using the source tree root directory and its data directory as the base directory and data directory, you will need to tell the server their pathnames. You can either do this on the command line with the --basedir and --datadir options, or place appropriate options in an option file (the `my.ini' file in your Windows directory or `C:\my.cnf'). If you have an existing data directory elsewhere that you want to use, you can specify its pathname instead.
  12. Start your server from the `client_release' or `client_debug' directory, depending on which server you want to use. The general server startup instructions are at section 2.2.1 Installing MySQL on Windows. You'll need to adapt the instructions appropriately if you want to use a different base directory or data directory.
  13. When the server is running in standalone fashion or as a service based on your configuration, try to connect to it from the mysql interactive command-line utility that exists in your `client_release' or `client_debug' directory.

When you are satisfied that the programs you have built are working correctly, stop the server. Then install MySQL as follows:

  1. Create the directories where you want to install MySQL. For example, to install into `C:\mysql', use these commands:
    C:\> mkdir C:\mysql
    C:\> mkdir C:\mysql\bin
    C:\> mkdir C:\mysql\data
    C:\> mkdir C:\mysql\share
    C:\> mkdir C:\mysql\scripts
    
    If you want to compile other clients and link them to MySQL, you should also create several additional directories:
    C:\> mkdir C:\mysql\include
    C:\> mkdir C:\mysql\lib
    C:\> mkdir C:\mysql\lib\debug
    C:\> mkdir C:\mysql\lib\opt
    
    If you want to benchmark MySQL, create this directory:
    C:\> mkdir C:\mysql\sql-bench
    
    Benchmarking requires Perl support.
  2. From the `workdir' directory, copy into the C:\mysql directory the following directories:
    C:\> cd \workdir
    C:\workdir> copy client_release\*.exe C:\mysql\bin
    C:\workdir> copy client_debug\mysqld.exe C:\mysql\bin\mysqld-debug.exe
    C:\workdir> xcopy scripts\*.* C:\mysql\scripts /E
    C:\workdir> xcopy share\*.* C:\mysql\share /E
    
    If you want to compile other clients and link them to MySQL, you should also copy several libraries and header files:
    C:\workdir> copy lib_debug\mysqlclient.lib C:\mysql\lib\debug
    C:\workdir> copy lib_debug\libmysql.* C:\mysql\lib\debug
    C:\workdir> copy lib_debug\zlib.* C:\mysql\lib\debug
    C:\workdir> copy lib_release\mysqlclient.lib C:\mysql\lib\opt
    C:\workdir> copy lib_release\libmysql.* C:\mysql\lib\opt
    C:\workdir> copy lib_release\zlib.* C:\mysql\lib\opt
    C:\workdir> copy include\*.h C:\mysql\include
    C:\workdir> copy libmysql\libmysql.def C:\mysql\include
    
    If you want to benchmark MySQL, you should also do this:
    C:\workdir> xcopy sql-bench\*.* C:\mysql\bench /E
    

Set up and start the server in the same way as for the binary Windows distribution. See section 2.2.1 Installing MySQL on Windows.

2.3.6.2 Creating a Windows Source Package from the Latest Development Source

To create a Windows source package from the current BitKeeper source tree, use the following instructions. Please note that this procedure must be performed on a system running a Unix or Unix-like operating system. For example, the procedure is known to work well on Linux.

  1. Clone the BitKeeper source tree for MySQL (version 4.1 or above, as desired). For more information on how to clone the source tree, see the instructions at section 2.3.3 Installing from the Development Source Tree.
  2. Configure and build the distribution so that you have a server binary to work with. One way to do this is to run the following command in the top-level directory of your source tree:
    shell> ./BUILD/compile-pentium-max
    
  3. After making sure that the build process completed successfully, run the following utility script from top-level directory of your source tree:
    shell> ./scripts/make_win_src_distribution
    
    This script creates a Windows source package to be used on your Windows system. You can supply different options to the script based on your needs. It accepts the following options:
    --help
    Show this help message.
    --debug
    Print information about script operations, do not create package.
    --tmp
    Specify the temporary location.
    --suffix
    Suffix name for the package.
    --dirname
    Directory name to copy files (intermediate).
    --silent
    Do not print verbose list of files processed.
    --tar
    Create `tar.gz' package instead of `.zip' package.
    By default, make_win_src_distribution creates a Zip-format archive with the name `mysql-VERSION-win-src.zip', where VERSION represents the version of your MySQL source tree.
  4. Copy or upload to your Windows machine the Windows source package that you have just created. To compile it, use the instructions in section 2.3.6.1 Building MySQL Using VC++.

2.3.7 Compiling MySQL Clients on Windows

In your source files, you should include `my_global.h' before `mysql.h':

#include <my_global.h>
#include <mysql.h>

`my_global.h' includes any other files needed for Windows compatibility (such as `windows.h') if you compile your program on Windows.

You can either link your code with the dynamic `libmysql.lib' library, which is just a wrapper to load in `libmysql.dll' on demand, or link with the static `mysqlclient.lib' library.

The MySQL client libraries are compiled as threaded libraries, so you should also compile your code to be multi-threaded.

2.4 Post-Installation Setup and Testing

After installing MySQL, there are some issues you should address. For example, on Unix, you should initialize the data directory and create the MySQL grant tables. On all platforms, an important security concern is that the initial accounts in the grant tables have no passwords. You should assign passwords to prevent unauthorized access to the MySQL server.

The following sections include post-installation procedures that are specific to Windows systems and to Unix systems. Another section, section 2.4.2.3 Starting and Troubleshooting the MySQL Server, applies to all platforms; it describes what to do if you have trouble getting the server to start. section 2.4.3 Securing the Initial MySQL Accounts also applies to all platforms. You should follow its instructions to make sure that you have properly protected your MySQL accounts by assigning passwords to them.

When you are ready to create additional user accounts, you can find information on the MySQL access control system and account management in section 5.4 The MySQL Access Privilege System and section 5.5 MySQL User Account Management.

2.4.1 Windows Post-Installation Procedures

On Windows, the data directory and the grant tables do not have to be created. MySQL Windows distributions include the grant tables already set up with a set of preinitialized accounts in the mysql database under the data directory. However, you should assign passwords to the accounts. The procedure for this is given in section 2.4.3 Securing the Initial MySQL Accounts.

Before setting up passwords, you might want to try running some client programs to make sure that you can connect to the server and that it is operating properly. Make sure the server is running (see section 2.2.1.5 Starting the Server for the First Time), then issue the following commands to verify that you can retrieve information from the server. The output should be similar to what is shown here:

C:\> C:\mysql\bin\mysqlshow
+-----------+
| Databases |
+-----------+
| mysql     |
| test      |
+-----------+

C:\> C:\mysql\bin\mysqlshow mysql
Database: mysql
+--------------+
|    Tables    |
+--------------+
| columns_priv |
| db           |
| func         |
| host         |
| tables_priv  |
| user         |
+--------------+

C:\> C:\mysql\bin\mysql -e "SELECT Host,Db,User FROM db" mysql
+------+-------+------+
| host | db    | user |
+------+-------+------+
| %    | test% |      |
+------+-------+------+

If you are running a version of WIndows that supports services and you want the MySQL server to run automatically when Windows starts, see section 2.2.1.7 Starting MySQL as a Windows Service.

2.4.2 Unix Post-Installation Procedures

After installing MySQL on Unix, you need to initialize the grant tables, start the server, and make sure that the server works okay. You may also wish to arrange for the server to be started and stopped automatically when your system starts and stops. You should also assign passwords to the accounts in the grant tables.

On Unix, the grant tables are set up by the mysql_install_db program. For some installation methods, this program is run for you automatically:

Otherwise, you'll need to run mysql_install_db yourself.

The following procedure describes how to initialize the grant tables (if that has not already been done) and then start the server. It also suggests some commands that you can use to test whether the server is accessible and working properly. For information about starting and stopping the server automatically, see section 2.4.2.2 Starting and Stopping MySQL Automatically.

After you complete the procedure and have the server running, you should assign passwords to the accounts created by mysql_install_db. Instructions for doing so are given in section 2.4.3 Securing the Initial MySQL Accounts.

In the examples shown here, the server runs under the user ID of the mysql login account. This assumes that such an account exists. Either create the account if it does not exist, or substitute the name of a different existing login account that you plan to use for running the server.

  1. Change location into the top-level directory of your MySQL installation, represented here by BASEDIR:
    shell> cd BASEDIR
    
    BASEDIR is likely to be something like `/usr/local/mysql' or `/usr/local'. The following steps assume that you are located in this directory.
  2. If necessary, run the mysql_install_db program to set up the initial MySQL grant tables containing the privileges that determine how users are allowed to connect to the server. You'll need to do this if you used a distribution type that doesn't run the program for you. Typically, mysql_install_db needs to be run only the first time you install MySQL, so you can skip this step if you are upgrading an existing installation, However, mysql_install_db does not overwrite any existing privilege tables, so it should be safe to run in any circumstances. To initialize the grant tables, use one of the following commands, depending on whether mysql_install_db is located in the bin or scripts directory:
    shell> bin/mysql_install_db --user=mysql
    shell> scripts/mysql_install_db --user=mysql
    
    The mysql_install_db script creates the data directory, the mysql database that holds all database privileges, and the test database that you can use to test MySQL. The script also creates privilege table entries for root accounts and anonymous-user accounts. The accounts have no passwords initially. A description of their initial privileges is given in section 2.4.3 Securing the Initial MySQL Accounts. Briefly, these privileges allow the MySQL root user to do anything, and allow anybody to create or use databases with a name of test or starting with test_. It is important to make sure that the database directories and files are owned by the mysql login account so that the server has read and write access to them when you run it later. To ensure this, the --user option should be used as shown if you run mysql_install_db as root. Otherwise, you should execute the script while logged in as mysql, in which case you can omit the --user option from the command. mysql_install_db creates several tables in the mysql database: user, db, host, tables_priv, columns_priv, func, and possibly others depending on your version of MySQL. If you don't want to have the test database, you can remove it with mysqladmin -u root drop test after starting the server. If you have problems with mysql_install_db, see section 2.4.2.1 Problems Running mysql_install_db. There are some alternatives to running the mysql_install_db script as it is provided in the MySQL distribution:
  3. Start the MySQL server:
    shell> bin/mysqld_safe --user=mysql &
    
    For versions of MySQL older than 4.0, substitute bin/safe_mysqld for bin/mysqld_safe in this command. It is important that the MySQL server be run using an unprivileged (non-root) login account. To ensure this, the --user option should be used as shown if you run mysql_safe as root. Otherwise, you should execute the script while logged in as mysql, in which case you can omit the --user option from the command. Further instructions for running MySQL as an unprivileged user are given in section A.3.2 How to Run MySQL as a Normal User. If you neglected to create the grant tables before proceeding to this step, the following message will appear in the error log file when you start the server:
    mysqld: Can't find file: 'host.frm'
    
    If you have other problems starting the server, see section 2.4.2.3 Starting and Troubleshooting the MySQL Server.
  4. Use mysqladmin to verify that the server is running. The following commands provide simple tests to check whether the server is up and responding to connections:
    shell> bin/mysqladmin version
    shell> bin/mysqladmin variables
    
    The output from mysqladmin version varies slightly depending on your platform and version of MySQL, but should be similar to that shown here:
    shell> bin/mysqladmin version
    mysqladmin  Ver 8.40 Distrib 4.0.18, for linux on i586
    Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
    This software comes with ABSOLUTELY NO WARRANTY. This is free software,
    and you are welcome to modify and redistribute it under the GPL license
    
    Server version          4.0.18-log
    Protocol version        10
    Connection              Localhost via Unix socket
    TCP port                3306
    UNIX socket             /tmp/mysql.sock
    Uptime:                 16 sec
    
    Threads: 1  Questions: 9  Slow queries: 0
    Opens: 7  Flush tables: 2  Open tables: 0
    Queries per second avg: 0.000
    Memory in use: 132K  Max memory used: 16773K
    
    To see what else you can do with mysqladmin, invoke it with the --help option.
  5. Verify that you can shut down the server:
    shell> bin/mysqladmin -u root shutdown
    
  6. Verify that you can restart the server. Do this by using mysqld_safe or by invoking mysqld directly. For example:
    shell> bin/mysqld_safe --user=mysql --log &
    
    If mysqld_safe fails, see section 2.4.2.3 Starting and Troubleshooting the MySQL Server.
  7. Run some simple tests to verify that you can retrieve information from the server. The output should be similar to what is shown here:
    shell> bin/mysqlshow
    +-----------+
    | Databases |
    +-----------+
    | mysql     |
    | test      |
    +-----------+
    
    shell> bin/mysqlshow mysql
    Database: mysql
    +--------------+
    |    Tables    |
    +--------------+
    | columns_priv |
    | db           |
    | func         |
    | host         |
    | tables_priv  |
    | user         |
    +--------------+
    
    shell> bin/mysql -e "SELECT Host,Db,User FROM db" mysql
    +------+--------+------+
    | host | db     | user |
    +------+--------+------+
    | %    | test   |      |
    | %    | test_% |      |
    +------+--------+------+
    
  8. There is a benchmark suite in the `sql-bench' directory (under the MySQL installation directory) that you can use to compare how MySQL performs on different platforms. The benchmark suite is written in Perl. It uses the Perl DBI module to provide a database-independent interface to the various databases, and some other additional Perl modules are required to run the benchmark suite. You must have the following modules installed:
    DBI
    DBD::mysql
    Data::Dumper
    Data::ShowTable
    
    These modules can be obtained from CPAN http://www.cpan.org/. See section 2.7.1 Installing Perl on Unix. The `sql-bench/Results' directory contains the results from many runs against different databases and platforms. To run all tests, execute these commands:
    shell> cd sql-bench
    shell> perl run-all-tests
    
    If you don't have the `sql-bench' directory, you probably installed MySQL using RPM files other than the source RPM. (The source RPM includes the `sql-bench' benchmark directory.) In this case, you must first install the benchmark suite before you can use it. Beginning with MySQL 3.22, there are separate benchmark RPM files named `mysql-bench-VERSION-i386.rpm' that contain benchmark code and data. If you have a source distribution, there are also tests in its `tests' subdirectory that you can run. For example, to run `auto_increment.tst', execute this command from the top-level directory of your source distribution:
    shell> mysql -vvf test < ./tests/auto_increment.tst
    
    The expected result of the test can be found in the `./tests/auto_increment.res' file.
  9. At this point, you should have the server running. However, none of the initial MySQL accounts have a password, so you should assign passwords using the instructions in section 2.4.3 Securing the Initial MySQL Accounts.

2.4.2.1 Problems Running mysql_install_db

The purpose of the mysql_install_db script is to generate new MySQL privilege tables. It will not overwrite existing MySQL privilege tables, and it will not affect any other data.

If you want to re-create your privilege tables, first stop the mysqld server if it's running. Then rename the `mysql' directory under the data directory to save it, and then run mysql_install_db. For example:

shell> mv mysql-data-directory/mysql mysql-data-directory/mysql-old
shell> mysql_install_db --user=mysql

This section lists problems you might encounter when you run mysql_install_db:

mysql_install_db doesn't install the grant tables
You may find that mysql_install_db fails to install the grant tables and terminates after displaying the following messages:
Starting mysqld daemon with databases from XXXXXX
mysqld ended
In this case, you should examine the error log file very carefully. The log should be located in the directory `XXXXXX' named by the error message, and should indicate why mysqld didn't start. If you don't understand what happened, include the log when you post a bug report. See section 1.7.1.3 How to Report Bugs or Problems.
There is already a mysqld process running
This indicates that the server is already running, in which case the grant tables probably have already been created. If so, you don't have to run mysql_install_db at all because it need be run only once (when you install MySQL the first time).
Installing a second mysqld server doesn't work when one server is running
This can happen when you already have an existing MySQL installation, but want to put a new installation in a different location. For example, you might have a production installation already, but you want to create a second installation for testing purposes. Generally the problem that occurs when you try to run a second server is that it tries to use a network interface that is already in use by the first server. In this case, you will see one of the following error messages:
Can't start server: Bind on TCP/IP port:
Address already in use
Can't start server: Bind on unix socket...
For instructions on setting up multiple servers, see section 5.9 Running Multiple MySQL Servers on the Same Machine.
You don't have write access to `/tmp'
If you don't have write access to create temporary files or a Unix socket file in the default location (the `/tmp' directory), an error will occur when you run mysql_install_db or the mysqld server. You can specify different temporary directory and Unix socket file locations by executing these commands prior to starting mysql_install_db or mysqld:
shell> TMPDIR=/some_tmp_dir/
shell> MYSQL_UNIX_PORT=/some_tmp_dir/mysql.sock
shell> export TMPDIR MYSQL_UNIX_PORT
`some_tmp_dir' should be the full pathname to some directory for which you have write permission. After this, you should be able to run mysql_install_db and start the server with these commands:
shell> scripts/mysql_install_db --user=mysql
shell> bin/mysqld_safe --user=mysql &
If mysql_install_db is located in `bin', modify the first command to use bin/mysql_install_db. See section A.4.5 How to Protect or Change the MySQL Socket File `/tmp/mysql.sock'. See section E Environment Variables.

2.4.2.2 Starting and Stopping MySQL Automatically

Generally, you start the mysqld server in one of these ways:

The mysql.server and mysqld_safe scripts and the Mac OS X Startup Item can be used to start the server manually, or automatically at system startup time. mysql.server and the Startup Item also can be used to stop the server.

To start or stop the server manually using the mysql.server script, invoke it with start or stop arguments:

shell> mysql.server start
shell> mysql.server stop

Before mysql.server starts the server, it changes location to the MySQL installation directory, and then invokes mysqld_safe. If you want the server to run as some specific user, add an appropriate user option to the [mysqld] group of the `/etc/my.cnf' option file, as shown later in this section. (It is possible that you'll need to edit mysql.server if you've installed a binary distribution of MySQL in a non-standard location. Modify it to cd into the proper directory before it runs mysqld_safe. If you do this, your modified version of mysql.server may be overwritten if you upgrade MySQL in the future, so you should make a copy of your edited version that you can reinstall.)

mysql.server stop brings down the server by sending a signal to it. You can also stop the server manually by executing mysqladmin shutdown.

To start and stop MySQL automatically on your server, you need to add start and stop commands to the appropriate places in your `/etc/rc*' files.

If you use the Linux server RPM package (MySQL-server-VERSION.rpm), the mysql.server script will already have been installed in the `/etc/init.d' directory with the name `mysql'. You need not install it manually. See section 2.2.2 Installing MySQL on Linux for more information on the Linux RPM packages.

Some vendors provide RPM packages that install a startup script under a different name such as mysqld.

If you install MySQL from a source distribution or using a binary distribution format that does not install mysql.server automatically, you can install it manually. The script can be found in the `support-files' directory under the MySQL installation directory or in a MySQL source tree.

To install mysql.server manually, copy it to the `/etc/init.d' directory with the name mysql, and then make it executable. Do this by changing location into the appropriate directory where mysql.server is located and executing these commands:

shell> cp mysql.server /etc/init.d/mysql
shell> chmod +x /etc/init.d/mysql

Older Red Hat systems use the `/etc/rc.d/init.d' directory rather than `/etc/init.d'. Adjust the preceding commands accordingly. Alternatively, first create `/etc/init.d' as a symbolic link that points to `/etc/rc.d/init.d':

shell> cd /etc
shell> ln -s rc.d/init.d .

After installing the script, the commands needed to activate it to run at system startup depend on your operating system. On Linux, you can use chkconfig:

shell> chkconfig --add mysql

On some Linux systems, the following command also seems to be necessary to fully enable the mysql script:

shell> chkconfig --level 345 mysql on

On FreeBSD, startup scripts generally should go in `/usr/local/etc/rc.d/'. The rc(8) manual page states that scripts in this directory are executed only if their basename matches the *.sh shell filename pattern. Any other files or directories present within the directory are silently ignored. In other words, on FreeBSD, you should install the `mysql.server' script as `/usr/local/etc/rc.d/mysql.server.sh' to enable automatic startup.

As an alternative to the preceding setup, some operating systems also use `/etc/rc.local' or `/etc/init.d/boot.local' to start additional services on startup. To start up MySQL using this method, you could append a command like the one following to the appropriate startup file:

/bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'

For other systems, consult your operating system documentation to see how to install startup scripts.

You can add options for mysql.server in a global `/etc/my.cnf' file. A typical `/etc/my.cnf' file might look like this:

[mysqld]
datadir=/usr/local/mysql/var
socket=/var/tmp/mysql.sock
port=3306
user=mysql

[mysql.server]
basedir=/usr/local/mysql

The mysql.server script understands the following options: basedir, datadir, and pid-file. If specified, they must be placed in an option file, not on the command line. mysql.server understands only start and stop as command-line arguments.

The following table shows which option groups the server and each startup script read from option files:

Script Option Groups
mysqld [mysqld], [server], [mysqld-major-version]
mysql.server [mysql.server], [mysqld]
mysqld_safe [mysqld], [server], [mysqld_safe]

[mysqld-major-version] means that groups with names like [mysqld-4.0], [mysqld-4.1], and [mysqld-5.0] will be read by servers having versions 4.0.x, 4.1.x, 5.0.x, and so forth. This feature was added in MySQL 4.0.14. It can be used to specify options that will be read only by servers within a given release series.

For backward compatibility, mysql.server also reads the [mysql_server] group and mysqld_safe also reads the [safe_mysqld] group. However, you should update your option files to use the [mysql.server] and [mysqld_safe] groups instead when you begin using MySQL 4.0 or later.

See section 4.3.2 Using Option Files.

2.4.2.3 Starting and Troubleshooting the MySQL Server

If you have problems starting the server, here are some things you can try:

Some storage engines have options that control their behavior. You can create a `my.cnf' file and set startup options for the engines you plan to use. If you are going to use storage engines that support transactional tables (InnoDB, BDB), be sure that you have them configured the way you want before starting the server:

When the mysqld server starts, it changes location to the data directory. This is where it expects to find databases and where it expects to write log files. On Unix, the server also writes the pid (process ID) file in the data directory.

The data directory location is hardwired in when the server is compiled. This is where the server looks for the data directory by default. If the data directory is located somewhere else on your system, the server will not work properly. You can find out what the default path settings are by invoking mysqld with the --verbose and --help options. (Prior to MySQL 4.1, omit the --verbose option.)

If the defaults don't match the MySQL installation layout on your system, you can override them by specifying options on the command line to mysqld or mysqld_safe. You can also list the options in an option file.

To specify the location of the data directory explicitly, use the --datadir option. However, normally you can tell mysqld the location of the base directory under which MySQL is installed and it will look for the data directory there. You can do this with the --basedir option.

To check the effect of specifying path options, invoke mysqld with those options followed by the --verbose and --help options. For example, if you change location into the directory where mysqld is installed, and then run the following command, it will show the effect of starting the server with a base directory of `/usr/local':

shell> ./mysqld --basedir=/usr/local --verbose --help

You can specify other options such as --datadir as well, but note that --verbose and --help must be the last options. (Prior to MySQL 4.1, omit the --verbose option.)

Once you determine the path settings you want, start the server without --verbose and --help.

If mysqld is currently running, you can find out what path settings it is using by executing this command:

shell> mysqladmin variables

Or:

shell> mysqladmin -h host_name variables

host_name is the name of the server host.

If you get Errcode 13 (which means Permission denied) when starting mysqld, this means that the access privileges of the data directory or its contents do not allow the server access. In this case, you change the permissions for the involved files and directories so that the server has the right to use them. You can also start the server as root, but this can raise security issues and should be avoided.

On Unix, change location into the data directory and check the ownership of the data directory and its contents to make sure the server has access. For example, if the data directory is `/usr/local/mysql/var', use these commands:

shell> cd /usr/local/mysql/var
shell> ls -l

If the data directory, or files or subdirectories are not owned by the account that you use for running the server, change their ownership to that account:

shell> chown -R mysql .
shell> chgrp -R mysql .

If the server fails to start up correctly, check the error log file to see if you can find out why. Log files are located in the data directory (typically `C:\mysql\data' on Windows, `/usr/local/mysql/data' for a Unix binary distribution, and `/usr/local/var' for a Unix source distribution). Look in the data directory for files with names of the form `host_name.err' and `host_name.log', where host_name is the name of your server host. (Older servers on Windows use `mysql.err' as the error log name.) Then check the last few lines of these files. On Unix, you can use tail to display the last few lines:

shell> tail host_name.err
shell> tail host_name.log

The error log contains information that indicates why the server couldn't start. For example, you might see something like this in the log:

000729 14:50:10  bdb:  Recovery function for LSN 1 27595 failed
000729 14:50:10  bdb:  warning: ./test/t1.db: No such file or directory
000729 14:50:10  Can't init databases

This means that you didn't start mysqld with the --bdb-no-recover option and Berkeley DB found something wrong with its own log files when it tried to recover your databases. To be able to continue, you should move away the old Berkeley DB log files from the database directory to some other place, where you can later examine them. The BDB log files are named in sequence beginning with `log.0000000001', where the number increases over time.

If you are running mysqld with BDB table support and mysqld dumps core at startup, this could be due to problems with the BDB recovery log. In this case, you can try starting mysqld with --bdb-no-recover. If that helps, then you should remove all BDB log files from the data directory and try starting mysqld again without the --bdb-no-recover option.

If either of the following errors occur, it means that some other program (perhaps another mysqld server) is already using the TCP/IP port or Unix socket file that mysqld is trying to use:

Can't start server: Bind on TCP/IP port: Address already in use
Can't start server: Bind on unix socket...

Use ps to determine whether you have another mysqld server running. If so, shut down the server before starting mysqld again. (If another server is running, and you really want to run multiple servers, you can find information about how to do so in section 5.9 Running Multiple MySQL Servers on the Same Machine.)

If no other server is running, try to execute the command telnet your-host-name tcp-ip-port-number. (The default MySQL port number is 3306.) Then press Enter a couple of times. If you don't get an error message like telnet: Unable to connect to remote host: Connection refused, some other program is using the TCP/IP port that mysqld is trying to use. You'll need to track down what program this is and disable it, or else tell mysqld to listen to a different port with the --port option. In this case, you'll also need to specify the port number for client programs when connecting to the server via TCP/IP.

Another reason the port might be inaccessible is that you have a firewall running that blocks connections to it. If so, modify the firewall settings to allow access to the port.

If the server starts but you can't connect to it, you should make sure that you have an entry in `/etc/hosts' that looks like this:

127.0.0.1       localhost

This problem occurs only on systems that don't have a working thread library and for which MySQL must be configured to use MIT-pthreads.

If you can't get mysqld to start, you can try to make a trace file to find the problem by using the --debug option. See section D.1.2 Creating Trace Files.

2.4.3 Securing the Initial MySQL Accounts

Part of the MySQL installation process is to set up the mysql database containing the grant tables:

The grant tables define the initial MySQL user accounts and their access privileges. These accounts are set up as follows:

As noted, none of the initial accounts have passwords. This means that your MySQL installation is unprotected until you do something about it:

The following instructions describe how to set up passwords for the initial MySQL accounts, first for the anonymous accounts and then for the root accounts. Replace ``newpwd'' in the examples with the actual password that you want to use. The instructions also cover how to remove the anonymous accounts, should you prefer not to allow anonymous access at all.

You might want to defer setting the passwords until later, so that you don't need to specify them while you perform additional setup or testing. However, be sure to set them before using your installation for any real production work.

To assign passwords to the anonymous accounts, you can use either SET PASSWORD or UPDATE. In both cases, be sure to encrypt the password using the PASSWORD() function.

To use SET PASSWORD on Windows, do this:

shell> mysql -u root
mysql> SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR ''@'%' = PASSWORD('newpwd');

To use SET PASSWORD on Unix, do this:

shell> mysql -u root
mysql> SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR ''@'host_name' = PASSWORD('newpwd');

In the second SET PASSWORD statement, replace host_name with the name of the server host. This is the name that is specified in the Host column of the non-localhost record for root in the user table. If you don't know what hostname this is, issue the following statement before using SET PASSWORD:

mysql> SELECT Host, User FROM mysql.user;

Look for the record that has root in the User column and something other than localhost in the Host column. Then use that Host value in the second SET PASSWORD statement.

The other way to assign passwords to the anonymous accounts is by using UPDATE to modify the user table directly. Connect to the server as root and issue an UPDATE statement that assigns a value to the Password column of the appropriate user table records. The procedure is the same for Windows and Unix. The following UPDATE statement assigns a password to both anonymous accounts at once:

shell> mysql -u root
mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd')
    ->     WHERE User = '';
mysql> FLUSH PRIVILEGES;

After you update the passwords in the user table directly using UPDATE, you must tell the server to re-read the grant tables with FLUSH PRIVILEGES. Otherwise, the change will go unnoticed until you restart the server.

If you prefer to remove the anonymous accounts instead, do so as follows:

shell> mysql -u root
mysql> DELETE FROM mysql.user WHERE User = '';
mysql> FLUSH PRIVILEGES;

The DELETE statement applies both to Windows and to Unix. On Windows, if you want to remove only the anonymous account that has the same privileges as root, do this instead:

shell> mysql -u root
mysql> DELETE FROM mysql.user WHERE Host='localhost' AND User='';
mysql> FLUSH PRIVILEGES;

This account allows anonymous access but has full privileges, so removing it improves security.

You can assign passwords to the root accounts in several ways. The following discussion demonstrates three methods:

To assign passwords using SET PASSWORD, connect to the server as root and issue two SET PASSWORD statements. Be sure to encrypt the password using the PASSWORD() function.

For Windows, do this:

shell> mysql -u root
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR 'root'@'%' = PASSWORD('newpwd');

For Unix, do this:

shell> mysql -u root
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR 'root'@'host_name' = PASSWORD('newpwd');

In the second SET PASSWORD statement, replace host_name with the name of the server host. This is the same hostname that you used when you assigned the anonymous account passwords.

To assign passwords to the root accounts using mysqladmin, execute the following commands:

shell> mysqladmin -u root password "newpwd"
shell> mysqladmin -u root -h host_name password "newpwd"

These commands apply both to Windows and to Unix. In the second command, replace host_name with the name of the server host. The double quotes around the password are not always necessary, but you should use them if the password contains spaces or other characters that are special to your command interpreter.

If you are using a server from a very old version of MySQL, the mysqladmin commands to set the password will fail with the message parse error near 'SET password'. The solution to this problem is to upgrade the server to a newer version of MySQL.

You can also use UPDATE to modify the user table directly. The following UPDATE statement assigns a password to both root accounts at once:

shell> mysql -u root
mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd')
    ->     WHERE User = 'root';
mysql> FLUSH PRIVILEGES;

The UPDATE statement applies both to Windows and to Unix.

After the passwords have been set, you must supply the appropriate password whenever you connect to the server. For example, if you want to use mysqladmin to shut down the server, you can do so using this command:

shell> mysqladmin -u root -p shutdown
Enter password: (enter root password here)

Note: If you forget your root password after setting it up, the procedure for resetting it is covered in section A.4.1 How to Reset the Root Password.

To set up new accounts, you can use the GRANT statement. For instructions, see section 5.5.2 Adding New User Accounts to MySQL.

2.5 Upgrading/Downgrading MySQL

As a general rule, we recommend that when upgrading from one release series to another, you should go to the next series rather than skipping a series. For example, if you currently are running MySQL 3.23 and wish to upgrade to a newer series, upgrade to MySQL 4.0 rather than to 4.1 or 5.0.

The following items form a checklist of things you should do whenever you perform an upgrade:

You can always move the MySQL format files and data files between different versions on the same architecture as long as you stay within versions for the same release series of MySQL. The current production release series is 4.0. If you change the character set when running MySQL, you must run myisamchk -r -q --set-character-set=charset on all MyISAM tables. Otherwise, your indexes may not be ordered correctly, because changing the character set may also change the sort order.

If you upgrade or downgrade from one release series to another, there may be incompatibilities in table storage formats. In this case, you can use mysqldump to dump your tables before upgrading. After upgrading, reload the dump file using mysql to re-create your tables.

If you are cautious about using new versions, you can always rename your old mysqld before installing a newer one. For example, if you are using MySQL 4.0.18 and want to upgrade to 4.1.1, rename your current server from mysqld to mysqld-4.0.18. If your new mysqld then does something unexpected, you can simply shut it down and restart with your old mysqld.

If, after an upgrade, you experience problems with recompiled client programs, such as Commands out of sync or unexpected core dumps, you probably have used old header or library files when compiling your programs. In this case, you should check the date for your `mysql.h' file and `libmysqlclient.a' library to verify that they are from the new MySQL distribution. If not, recompile your programs with the new headers and libraries.

If problems occur, such as that the new mysqld server doesn't want to start or that you can't connect without a password, verify that you don't have some old `my.cnf' file from your previous installation. You can check this with the -name --print-defaults option (for example, mysqld --print-defaults). If this displays anything other than the program name, you have an active `my.cnf' file that affects server or client operation.

It is a good idea to rebuild and reinstall the Perl DBD::mysql module whenever you install a new release of MySQL. The same applies to other MySQL interfaces as well, such as the Python MySQLdb module.

2.5.1 Upgrading from Version 4.1 to 5.0

In general, you should do the following when upgrading to MySQL 5.0 from 4.1:

2.5.2 Upgrading from Version 4.0 to 4.1

In general, you should do the following when upgrading to MySQL 4.1 from 4.0:

Several visible behaviors have changed between MySQL 4.0 and MySQL 4.1 to fix some critical bugs and make MySQL more compatible with the ANSI SQL standard. These changes may affect your applications.

Some of the 4.1 behaviors can be tested in 4.0 before performing a full upgrade to 4.1. We have added to later MySQL 4.0 releases (from 4.0.12 on) a --new startup option for mysqld. See section 5.2.1 mysqld Command-Line Options.

This option gives you the 4.1 behavior for the most critical changes. You can also enable these behaviors for a given client connection with the SET @@new=1 command, or turn them off if they are on with SET @@new=0.

If you believe that some of the 4.1 changes will affect you, we recommend that before upgrading to 4.1, you download the latest MySQL 4.0 version and run it with the --new option by adding the following to your config file:

[mysqld-4.0]
new

That way you can test the new behaviors in 4.0 to make sure that your applications work with them. This will help you have a smooth, painless transition when you perform a full upgrade to 4.1 later. Putting the --new option in the [mysqld-4.0] option group ensures that you don't accidentally later run the 4.1 version with the --new option.

The following lists describe changes that may affect applications and that you should watch out for when upgrading to version 4.1:

Server Changes:

Client Changes:

SQL Changes:

C API Changes:

Password-Handling Changes:

The password hashing mechanism has changed in 4.1 to provide better security, but this may cause compatibility problems if you still have clients that use the client library from 4.0 or earlier. (It is very likely that you will have 4.0 clients in situations where clients connect from remote hosts that have not yet upgraded to 4.1.) The following list indicates some possible upgrade strategies. They represent various tradeoffs between the goal of compatibility with old clients and the goal of security.

Further background on password hashing with respect to client authentication and password-changing operations may be found in section 5.4.9 Password Hashing in MySQL 4.1 and section A.2.3 Client does not support authentication protocol.

2.5.3 Upgrading from Version 3.23 to 4.0

In general, you should do the following when upgrading to MySQL 4.0 from 3.23:

MySQL 4.0 will work even if you don't perform the preceding actions, but you will not be able to use the new security privileges in MySQL 4.0 and you may run into problems when upgrading later to MySQL 4.1 or newer. The ISAM file format still works in MySQL 4.0, but is deprecated and is not compiled in by default as of MySQL 4.1. MyISAM tables should be used instead.

Old clients should work with a Version 4.0 server without any problems.

Even if you perform the preceding actions, you can still downgrade to MySQL 3.23.52 or newer if you run into problems with the MySQL 4.0 series. In this case, you must use mysqldump to dump any tables that use full-text indexes and reload the dump file into the 3.23 server. This is necessary because 4.0 uses a new format for full-text indexing.

The following lists describe changes that may affect applications and that you should watch out for when upgrading to version 4.0:

Server Changes:

SQL Changes:

C API Changes:

Other Changes:

2.5.4 Upgrading from Version 3.22 to 3.23

MySQL 3.22 and 3.21 clients will work without any problems with a MySQL 3.23 server.

When upgrading to MySQL 3.23 from an earlier version, note the following changes:

Table Changes:

Client Program Changes:

SQL Changes:

C API Changes:

2.5.5 Upgrading from Version 3.21 to 3.22

Nothing that affects compatibility has changed between versions 3.21 and 3.22. The only pitfall is that new tables that are created with DATE type columns will use the new way to store the date. You can't access these new columns from an old version of mysqld.

When upgrading to MySQL 3.23 from an earlier version, note the following changes:

2.5.6 Upgrading from Version 3.20 to 3.21

If you are running a version older than Version 3.20.28 and want to switch to Version 3.21, you need to do the following:

You can start the mysqld Version 3.21 server with the --old-protocol option to use it with clients from a Version 3.20 distribution. In this case, the server uses the old pre-3.21 password() checking rather than the new method. Also, the new client function mysql_errno() will not return any server error, only CR_UNKNOWN_ERROR. The function does work for client errors.

If you are not using the --old-protocol option to mysqld, you will need to make the following changes:

MySQL 3.20.28 and above can handle the new user table format without affecting clients. If you have a MySQL version earlier than 3.20.28, passwords will no longer work with it if you convert the user table. So to be safe, you should first upgrade to at least Version 3.20.28 and then upgrade to Version 3.21.

The new client code works with a 3.20.x mysqld server, so if you experience problems with 3.21.x, you can use the old 3.20.x server without having to recompile the clients again.

If you are not using the --old-protocol option to mysqld, old clients will be unable to connect and will issue the following error message:

ERROR: Protocol mismatch. Server Version = 10 Client Version = 9

The Perl DBI interface also supports the old mysqlperl interface. The only change you have to make if you use mysqlperl is to change the arguments to the connect() function. The new arguments are: host, database, user, and password (note that the user and password arguments have changed places).

The following changes may affect queries in old applications:

2.5.7 Upgrading MySQL Under Windows

When upgrading MySQL under Windows, please follow these steps:

  1. Download the latest Windows distribution of MySQL.
  2. Choose a time of day with low usage, where a maintenance break is acceptable.
  3. Alert the users who still are active about the maintenance break.
  4. Stop the running MySQL Server (for example, with NET STOP MySQL or with the Services utility if you are running MySQL as a service, or with mysqladmin shutdown otherwise).
  5. Exit the WinMySQLAdmin program if it is running.
  6. Run the installation script of the Windows distribution by clicking the Install button in WinZip and following the installation steps of the script. Important note: Early alpha Windows distributions for MySQL 4.1 do not contain an installer program. See section 2.2.1.2 Installing a Windows Binary Distribution for instructions on how to install such a distribution.
  7. You may either overwrite your old MySQL installation (usually located at `C:\mysql'), or install it into a different directory, such as C:\mysql4. Overwriting the old installation is recommended.
  8. Restart the server. For example, use NET START MySQL if you run MySQL as a service, or invoke mysqld directly otherwise.
  9. Update the grant tables. The procedure is described in section 2.5.8 Upgrading the Grant Tables.

Possible error situations:

A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.

This error means that your option file (by default `C:\my.cnf') contains an option that cannot be recognized by MySQL. You can verify that this is the case by trying to restart MySQL with the `my.cnf' file renamed to prevent the server from using it (for example, rename `C:\my.cnf' to `C:\my_cnf.old'). Once you have verified it, you need to identify which option is the culprit. Create a new `my.cnf' file and move parts of the old file to it (restarting the server after you move each part) until you determine which option causes server startup to fail.

2.5.8 Upgrading the Grant Tables

Some releases introduce changes to the structure of the grant tables (the tables in the mysql database) to add new privileges or features. To make sure that your grant tables are current when you update to a new version of MySQL, you should update your grant tables as well.

On Unix or Unix-like systems, update the grant tables by running the mysql_fix_privilege_tables script:

shell> mysql_fix_privilege_tables

You must run this script while the server is running. It attempts to connect to the server running on the local host as root. If your root account requires a password, indicate the password on the command line. For MySQL 4.1 and up, specify the password like this:

shell> mysql_fix_privilege_tables --password=root_password

Prior to MySQL 4.1, specify the password like this:

shell> mysql_fix_privilege_tables root_password

The mysql_fix_privilege_tables script performs any actions necessary to convert your grant tables to the current format. You might see some Duplicate column name warnings as it runs; you can ignore them.

After running the script, stop the server and restart it.

On Windows systems, there isn't an easy way to update the grant tables until MySQL 4.0.15. From version 4.0.15 on, MySQL distributions include a mysql_fix_privilege_tables.sql SQL script that you can run using the mysql client. If your MySQL installation is located at `C:\mysql', the commands look like this:

C:\> C:\mysql\bin\mysql -u root -p mysql
mysql> SOURCE C:\mysql\scripts\mysql_fix_privilege_tables.sql

If your installation is located in some other directory, adjust the pathnames appropriately.

The mysql command will prompt you for the root password; enter it when prompted.

As with the Unix procedure, you might see some Duplicate column name warnings as mysql processes the statements in the mysql_fix_privilege_tables.sql script; you can ignore them.

After running the script, stop the server and restart it.

2.5.9 Copying MySQL Databases to Another Machine

If you are using MySQL Version 3.23 or later, you can copy the `.frm', `.MYI', and `.MYD' files for MyISAM tables between different architectures that support the same floating-point format. (MySQL takes care of any byte-swapping issues.) See section 15.1 The MyISAM Storage Engine.

The MySQL ISAM data and index files (`.ISD' and `*.ISM', respectively) are architecture dependent and in some cases operating system dependent. If you want to move your applications to another machine that has a different architecture or operating system than your current machine, you should not try to move a database by simply copying the files to the other machine. Use mysqldump instead.

By default, mysqldump will create a file containing SQL statements. You can then transfer the file to the other machine and feed it as input to the mysql client.

Try mysqldump --help to see what options are available. If you are moving the data to a newer version of MySQL, you should use mysqldump --opt to take advantage of any optimizations that result in a dump file that is smaller and can be processed faster.

The easiest (although not the fastest) way to move a database between two machines is to run the following commands on the machine on which the database is located:

shell> mysqladmin -h 'other hostname' create db_name
shell> mysqldump --opt db_name \
        | mysql -h 'other hostname' db_name

If you want to copy a database from a remote machine over a slow network, you can use:

shell> mysqladmin create db_name
shell> mysqldump -h 'other hostname' --opt --compress db_name \
        | mysql db_name

You can also store the result in a file, then transfer the file to the target machine and load the file into the database there. For example, you can dump a database to a file on the source machine like this:

shell> mysqldump --quick db_name | gzip > db_name.contents.gz

(The file created in this example is compressed.) Transfer the file containing the database contents to the target machine and run these commands there:

shell> mysqladmin create db_name
shell> gunzip < db_name.contents.gz | mysql db_name

You can also use mysqldump and mysqlimport to transfer the database. For big tables, this is much faster than simply using mysqldump. In the following commands, DUMPDIR represents the full pathname of the directory you use to store the output from mysqldump.

First, create the directory for the output files and dump the database:

shell> mkdir DUMPDIR
shell> mysqldump --tab=DUMPDIR db_name

Then transfer the files in the DUMPDIR directory to some corresponding directory on the target machine and load the files into MySQL there:

shell> mysqladmin create db_name           # create database
shell> cat DUMPDIR/*.sql | mysql db_name   # create tables in database
shell> mysqlimport db_name DUMPDIR/*.txt   # load data into tables

Also, don't forget to copy the mysql database because that is where the user, db, and host grant tables are stored. You may have to run commands as the MySQL root user on the new machine until you have the mysql database in place.

After you import the mysql database on the new machine, execute mysqladmin flush-privileges so that the server reloads the grant table information.

2.6 Operating System-Specific Notes

2.6.1 Linux Notes

This section discusses issues that have been found to occur on Linux. The first few subsections describe general operating system-related issues, problems that can occur when using binary or source distributions, and post-installation issues. The remaining subsections discuss problems that occur with Linux on specific platforms.

Note that most of these problems occur on older versions of Linux. If you are running a recent version, you likely will see none of them.

2.6.1.1 Linux Operating System Notes

MySQL needs at least Linux Version 2.0.

Warning: We have seen some strange problems with Linux 2.2.14 and MySQL on SMP systems. We also have reports from some MySQL users that they have encountered serious stability problems using MySQL with kernel 2.2.14. If you are using this kernel, you should upgrade to 2.2.19 (or newer) or to a 2.4 kernel. If you have a multiple-CPU box, then you should seriously consider using 2.4 because it will give you a significant speed boost. Your system also will be more stable.

When using LinuxThreads, you will see a minimum of three mysqld processes running. These are in fact threads. There will be one thread for the LinuxThreads manager, one thread to handle connections, and one thread to handle alarms and signals.

2.6.1.2 Linux Binary Distribution Notes

The Linux-Intel binary and RPM releases of MySQL are configured for the highest possible speed. We are always trying to use the fastest stable compiler available.

The binary release is linked with -static, which means you do not normally need to worry about which version of the system libraries you have. You need not install LinuxThreads, either. A program linked with -static is slightly larger than a dynamically linked program, but also slightly faster (3-5%). However, one problem with a statically linked program is that you can't use user-defined functions (UDFs). If you are going to write or use UDFs (this is something for C or C++ programmers only), you must compile MySQL yourself using dynamic linking.

A known issue with binary distributions is that on older Linux systems that use libc (such as Red Hat 4.x or Slackware), you will get some non-fatal problems with hostname resolution. If your system uses libc rather than glibc2, you probably will encounter some difficulties with hostname resolution and getpwnam(). This happens because glibc unfortunately depends on some external libraries to implement hostname resolution and getpwent(), even when compiled with -static. These problems manifest themselves in two ways:

Another solution, which solves both problems, is to not use a binary distribution. Get a MySQL source distribution (in RPM or tar.gz format) and install that instead.

On some Linux 2.2 versions, you may get the error Resource temporarily unavailable when clients make a lot of new connections to a mysqld server over TCP/IP. The problem is that Linux has a delay between the time that you close a TCP/IP socket and the time that the system actually frees it. There is room for only a finite number of TCP/IP slots, so you will encounter the resource-unavailable error if clients attempt too many new TCP/IP connections during a short time. For example, you may see the error when you run the MySQL `test-connect' benchmark over TCP/IP.

We have inquired about this problem a few times on different Linux mailing lists but have never been able to find a suitable resolution. The only known ``fix'' is for the clients to use persistent connections, or, if you are running the database server and clients on the same machine, to use Unix socket file connections rather than TCP/IP connections.

2.6.1.3 Linux Source Distribution Notes

The following notes regarding glibc apply only to the situation when you build MySQL yourself. If you are running Linux on an x86 machine, in most cases it is much better for you to just use our binary. We link our binaries against the best patched version of glibc we can come up with and with the best compiler options, in an attempt to make it suitable for a high-load server. For a typical user, even for setups with a lot of concurrent connections or tables exceeding the 2GB limit, our binary is the best choice in most cases. After reading the following text, if you are in doubt about what to do, try our binary first to see whether it meets your needs. If you discover that it is not good enough, then you may want to try your own build. In that case, we would appreciate a note about it so that we can build a better binary next time.

MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL. You can get LinuxThreads at http://dev.mysql.com/downloads/os-linux.html.

Note that glibc versions before and including Version 2.1.1 have a fatal bug in pthread_mutex_timedwait() handling, which is used when you issue INSERT DELAYED statements. We recommend that you not use INSERT DELAYED before upgrading glibc.

Note that Linux kernel and the LinuxThread library can by default only have 1,024 threads. If you plan to have more than 1,000 concurrent connections, you will need to make some changes to LinuxThreads:

The page http://www.volano.com/linuxnotes.html contains additional information about circumventing thread limits in LinuxThreads.

There is another issue that greatly hurts MySQL performance, especially on SMP systems. The mutex implementation in LinuxThreads in glibc 2.1 is very bad for programs with many threads that hold the mutex only for a short time. This produces a paradoxical result: If you link MySQL against an unmodified LinuxThreads, removing processors from an SMP actually improves MySQL performance in many cases. We have made a patch available for glibc 2.1.3 to correct this behavior (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).

With glibc 2.2.2, MySQL 3.23.36 will use the adaptive mutex, which is much better than even the patched one in glibc 2.1.3. Be warned, however, that under some conditions, the current mutex code in glibc 2.2.2 overspins, which hurts MySQL performance. The likelihood that this condition will occur can be reduced by renicing the mysqld process to the highest priority. We have also been able to correct the overspin behavior with a patch, available at http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. It combines the correction of overspin, maximum number of threads, and stack spacing all in one. You will need to apply it in the linuxthreads directory with patch -p0 </tmp/linuxthreads-2.2.2.patch. We hope it will be included in some form in future releases of glibc 2.2. In any case, if you link against glibc 2.2.2, you still need to correct STACK_SIZE and PTHREAD_THREADS_MAX. We hope that the defaults will be corrected to some more acceptable values for high-load MySQL setup in the future, so that the commands needed to produce your own build can be reduced to ./configure; make; make install.

We recommend that you use these patches to build a special static version of libpthread.a and use it only for statically linking against MySQL. We know that the patches are safe for MySQL and significantly improve its performance, but we cannot say anything about other applications. If you link other applications that require LinuxThreads against the patched static version of the library, or build a patched shared version and install it on your system, you do so at your own risk.

If you experience any strange problems during the installation of MySQL, or with some common utilities hanging, it is very likely that they are either library or compiler related. If this is the case, using our binary will resolve them.

If you link your own MySQL client programs, you may see the following error at runtime:

ld.so.1: fatal: libmysqlclient.so.#:
open failed: No such file or directory

This problem can be avoided by one of the following methods:

If you are using the Fujitsu compiler (fcc/FCC), you will have some problems compiling MySQL because the Linux header files are very gcc oriented. The following configure line should work with fcc/FCC:

CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \
    -DCONST=const -DNO_STRTOLL_PROTO" \
CXX=FCC CXXFLAGS="-O -K fast -K lib \
    -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE \
    -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \
    '-D_EXTERN_INLINE=static __inline'" \
./configure \
    --prefix=/usr/local/mysql --enable-assembler \
    --with-mysqld-ldflags=-all-static --disable-shared \
    --with-low-memory

2.6.1.4 Linux Post-Installation Notes

mysql.server can be found in the `support-files' directory under the MySQL installation directory or in a MySQL source tree. You can install it as `/etc/init.d/mysql' for automatic MySQL startup and shutdown. See section 2.4.2.2 Starting and Stopping MySQL Automatically.

If MySQL can't open enough files or connections, it may be that you haven't configured Linux to handle enough files.

In Linux 2.2 and onward, you can check the number of allocated file handles as follows:

shell> cat /proc/sys/fs/file-max
shell> cat /proc/sys/fs/dquot-max
shell> cat /proc/sys/fs/super-max

If you have more than 16MB of memory, you should add something like the following to your init scripts (for example, `/etc/init.d/boot.local' on SuSE Linux):

echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max

You can also run the echo commands from the command line as root, but these settings will be lost the next time your computer restarts.

Alternatively, you can set these parameters on startup by using the sysctl tool, which is used by many Linux distributions (SuSE has added it as well, beginning with SuSE Linux 8.0). Just put the following values into a file named `/etc/sysctl.conf':

# Increase some values for MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024

You should also add the following to `/etc/my.cnf':

[mysqld_safe]
open-files-limit=8192

This should allow the server a limit of 8,192 for the combined number of connections and open files.

The STACK_SIZE constant in LinuxThreads controls the spacing of thread stacks in the address space. It needs to be large enough so that there will be plenty of room for each individual thread stack, but small enough to keep the stack of some threads from running into the global mysqld data. Unfortunately, as we have experimentally discovered, the Linux implementation of mmap() will successfully unmap an already mapped region if you ask it to map out an address already in use, zeroing out the data on the entire page instead of returning an error. So, the safety of mysqld or any other threaded application depends on ``gentlemanly'' behavior of the code that creates threads. The user must take measures to make sure that the number of running threads at any time is sufficiently low for thread stacks to stay away from the global heap. With mysqld, you should enforce this behavior by setting a reasonable value for the max_connections variable.

If you build MySQL yourself, you can patch LinuxThreads for better stack use. See section 2.6.1.3 Linux Source Distribution Notes. If you do not want to patch LinuxThreads, you should set max_connections to a value no higher than 500. It should be even less if you have a large key buffer, large heap tables, or some other things that make mysqld allocate a lot of memory, or if you are running a 2.2 kernel with a 2GB patch. If you are using our binary or RPM version 3.23.25 or later, you can safely set max_connections at 1500, assuming no large key buffer or heap tables with lots of data. The more you reduce STACK_SIZE in LinuxThreads the more threads you can safely create. We recommend values between 128KB and 256KB.

If you use a lot of concurrent connections, you may suffer from a ``feature'' in the 2.2 kernel that attempts to prevent fork bomb attacks by penalizing a process for forking or cloning a child. This causes MySQL not to scale well as you increase the number of concurrent clients. On single-CPU systems, we have seen this manifested as very slow thread creation: It may take a long time to connect to MySQL (as long as one minute), and it may take just as long to shut it down. On multiple-CPU systems, we have observed a gradual drop in query speed as the number of clients increases. In the process of trying to find a solution, we have received a kernel patch from one of our users who claimed it made a lot of difference for his site. The patch is available at http://www.mysql.com/Downloads/Patches/linux-fork.patch. We have now done rather extensive testing of this patch on both development and production systems. It has significantly improved MySQL performance without causing any problems and we now recommend it to our users who still run high-load servers on 2.2 kernels.

This issue has been fixed in the 2.4 kernel, so if you are not satisfied with the current performance of your system, rather than patching your 2.2 kernel, it might be easier to upgrade to 2.4. On SMP systems, upgrading also will give you a nice SMP boost in addition to fixing the fairness bug.

We have tested MySQL on the 2.4 kernel on a two-CPU machine and found MySQL scales much better. There was virtually no slowdown on query throughput all the way up to 1,000 clients, and the MySQL scaling factor (computed as the ratio of maximum throughput to the throughput for one client) was 180%. We have observed similar results on a four-CPU system: Virtually no slowdown as the number of clients was increased up to 1,000, and a 300% scaling factor. Based on these results, for a high-load SMP server using a 2.2 kernel, we definitely recommend upgrading to the 2.4 kernel at this point.

We have discovered that it is essential to run the mysqld process with the highest possible priority on the 2.4 kernel to achieve maximum performance. This can be done by adding a renice -20 $$ command to mysqld_safe. In our testing on a four-CPU machine, increasing the priority resulted in a 60% throughput increase with 400 clients.

We are currently also trying to collect more information on how well MySQL performs with a 2.4 kernel on four-way and eight-way systems. If you have access such a system and have done some benchmarks, please send an email message to benchmarks@mysql.com with the results. We will review them for inclusion in the manual.

If you see a dead mysqld server process with ps, this usually means that you have found a bug in MySQL or you have a corrupted table. See section A.4.2 What to Do If MySQL Keeps Crashing.

To get a core dump on Linux if mysqld dies with a SIGSEGV signal, you can start mysqld with the --core-file option. Note that you also probably need to raise the core file size by adding ulimit -c 1000000 to mysqld_safe or starting mysqld_safe with --core-file-size=1000000. See section 5.1.3 The mysqld_safe Server Startup Script.

2.6.1.5 Linux x86 Notes

MySQL requires libc Version 5.4.12 or newer. It's known to work with libc 5.4.46. glibc Version 2.0.6 and later should also work. There have been some problems with the glibc RPMs from Red Hat, so if you have problems, check whether there are any updates. The glibc 2.0.7-19 and 2.0.7-29 RPMs are known to work.

If you are using Red Hat 8.0 or a new glibc 2.2.x library, you may see mysqld die in gethostbyaddr(). This happens because the new glibc library requires a stack size greater than 128KB for this call. To fix the problem, start mysqld with the --thread-stack=192K option. (Use -O thread_stack=192K before MySQL 4.) This stack size is now the default on MySQL 4.0.10 and above, so you should not see the problem.

If you are using gcc 3.0 and above to compile MySQL, you must install the libstdc++v3 library before compiling MySQL; if you don't do this, you will get an error about a missing __cxa_pure_virtual symbol during linking.

On some older Linux distributions, configure may produce an error like this:

Syntax error in sched.h. Change _P to __P in the
/usr/include/sched.h file.
See the Installation chapter in the Reference Manual.

Just do what the error message says. Add an extra underscore to the _P macro name that has only one underscore, then try again.

You may get some warnings when compiling. Those shown here can be ignored:

mysqld.cc -o objs-thread/mysqld.o
mysqld.cc: In function `void init_signals()':
mysqld.cc:315: warning: assignment of negative value `-1' to
`long unsigned int'
mysqld.cc: In function `void * signal_hand(void *)':
mysqld.cc:346: warning: assignment of negative value `-1' to
`long unsigned int'

If mysqld always dumps core when it starts, the problem may be that you have an old `/lib/libc.a'. Try renaming it, then remove `sql/mysqld' and do a new make install and try again. This problem has been reported on some Slackware installations.

If you get the following error when linking mysqld, it means that your `libg++.a' is not installed correctly:

/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'

You can avoid using `libg++.a' by running configure like this:

shell> CXX=gcc ./configure

If mysqld crashes immediately and you are running Red Hat Version 5.0 with a version of glibc older than 2.0.7-5, you should make sure that you have installed all glibc patches. There is a lot of information about this in the MySQL mail archives, available online at http://lists.mysql.com/.

2.6.1.6 Linux SPARC Notes

In some implementations, readdir_r() is broken. The symptom is that the SHOW DATABASES statement always returns an empty set. This can be fixed by removing HAVE_READDIR_R from `config.h' after configuring and before compiling.

2.6.1.7 Linux Alpha Notes

MySQL 3.23.12 is the first MySQL version that is tested on Linux-Alpha. If you plan to use MySQL on Linux-Alpha, you should ensure that you have this version or newer.

We have tested MySQL on Alpha with our benchmarks and test suite, and it appears to work nicely.

We currently build the MySQL binary packages on SuSE Linux 7.0 for AXP, kernel 2.4.4-SMP, Compaq C compiler (V6.2-505) and Compaq C++ compiler (V6.3-006) on a Compaq DS20 machine with an Alpha EV6 processor.

You can find the preceding compilers at http://www.support.compaq.com/alpha-tools/. By using these compilers rather than gcc, we get about 9-14% better MySQL performance.

Note that until MySQL version 3.23.52 and 4.0.2, we optimized the binary for the current CPU only (by using the -fast compile option). This means that for older versions, you can use our Alpha binaries only if you have an Alpha EV6 processor.

For all following releases, we added the -arch generic flag to our compile options, which makes sure that the binary runs on all Alpha processors. We also compile statically to avoid library problems. The configure command looks like this:

CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \
CXXFLAGS="-fast -arch generic -noexceptions -nortti" \
./configure --prefix=/usr/local/mysql --disable-shared \
    --with-extra-charsets=complex --enable-thread-safe-client \
    --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared

If you want to use egcs, the following configure line worked for us:

CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \
CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \
    -fno-exceptions -fno-rtti" \
./configure --prefix=/usr/local/mysql --disable-shared

Some known problems when running MySQL on Linux-Alpha:

2.6.1.8 Linux PowerPC Notes

MySQL should work on MkLinux with the newest glibc package (tested with glibc 2.0.7).

2.6.1.9 Linux MIPS Notes

To get MySQL to work on Qube2 (Linux Mips), you need the newest glibc libraries. glibc-2.0.7-29C2 is known to work. You must also use the egcs C++ compiler (egcs-1.0.2-9, gcc 2.95.2 or newer).

2.6.1.10 Linux IA-64 Notes

To get MySQL to compile on Linux IA-64, we use the following configure command for building with gcc 2.96:

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-comment=Official MySQL binary" \
    --with-extra-charsets=complex

On IA-64, the MySQL client binaries use shared libraries. This means that if you install our binary distribution at a location other than `/usr/local/mysql', you need to add the path of the directory where you have `libmysqlclient.so' installed either to the `/etc/ld.so.conf' file or to the value of your LD_LIBRARY_PATH environment variable.

See section A.3.1 Problems Linking to the MySQL Client Library.

2.6.2 Mac OS X Notes

On Mac OS X, tar cannot handle long filenames. If you need to unpack a `.tar.gz' distribution, use gnutar instead.

2.6.2.1 Mac OS X 10.x (Darwin)

MySQL should work without any problems on Mac OS X 10.x (Darwin).

Our binary for Mac OS X is compiled on Darwin 6.3 with the following configure line:

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

See section 2.2.3 Installing MySQL on Mac OS X.

2.6.2.2 Mac OS X Server 1.2 (Rhapsody)

For current versions of Mac OS X Server, no operating system changes are necessary before compiling MySQL. Compiling for the Server platform is the same as for the client version of Mac OS X. (However, note that MySQL comes preinstalled on Mac OS X Server, so you need not build it yourself.)

For older versions (Mac OS X Server 1.2, a.k.a. Rhapsody), you must first install a pthread package before trying to configure MySQL.

See section 2.2.3 Installing MySQL on Mac OS X.

2.6.3 Solaris Notes

On Solaris, you may run into trouble even before you get the MySQL distribution unpacked! Solaris tar can't handle long file names, so you may see an error like this when you unpack MySQL:

x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,
informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks
tar: directory checksum error

In this case, you must use GNU tar (gtar) to unpack the distribution. You can find a precompiled copy for Solaris at http://dev.mysql.com/downloads/os-solaris.html.

Sun native threads work only on Solaris 2.5 and higher. For Version 2.4 and earlier, MySQL automatically uses MIT-pthreads. See section 2.3.5 MIT-pthreads Notes.

If you get the following error from configure, it means that you have something wrong with your compiler installation:

checking for restartable system calls... configure: error can not
run test programs while cross compiling

In this case, you should upgrade your compiler to a newer version. You may also be able to solve this problem by inserting the following row into the `config.cache' file:

ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}

If you are using Solaris on a SPARC, the recommended compiler is gcc 2.95.2 or 3.2. You can find this at http://gcc.gnu.org/. Note that egcs 1.1.1 and gcc 2.8.1 don't work reliably on SPARC!

The recommended configure line when using gcc 2.95.2 is:

CC=gcc CFLAGS="-O3" \
CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \
./configure --prefix=/usr/local/mysql --with-low-memory \
    --enable-assembler

If you have an UltraSPARC system, you can get 4% better performance by adding -mcpu=v8 -Wa,-xarch=v8plusa to the CFLAGS and CXXFLAGS environment variables.

If you have Sun's Forte 5.0 (or newer) compiler, you can run configure like this:

CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt" \
CXX=CC CXXFLAGS="-noex -mt" \
./configure --prefix=/usr/local/mysql --enable-assembler

To create a 64-bit binary with Sun's Forte compiler, use the following configuration options:

CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt -xarch=v9" \
CXX=CC CXXFLAGS="-noex -mt -xarch=v9" ASFLAGS="-xarch=v9" \
./configure --prefix=/usr/local/mysql --enable-assembler

To create a 64-bit Solaris binary using gcc, add -m64 to CFLAGS and CXXFLAGS. This works only with MySQL 4.0 and up; MySQL 3.23 does not include the required modifications to support this.

In the MySQL benchmarks, we got a 4% speedup on an UltraSPARC when using Forte 5.0 in 32-bit mode compared to using gcc 3.2 with the -mcpu flag.

If you create a 64-bit mysqld binary, it is 4% slower than the 32-bit binary, but can handle more threads and memory.

If you get a problem with fdatasync or sched_yield, you can fix this by adding LIBS=-lrt to the configure line

For compilers older than WorkShop 5.3, you might have to edit the configure script. Change this line:

#if !defined(__STDC__) || __STDC__ != 1

To this:

#if !defined(__STDC__)

If you turn on __STDC__ with the -Xc option, the Sun compiler can't compile with the Solaris `pthread.h' header file. This is a Sun bug (broken compiler or broken include file).

If mysqld issues the following error message when you run it, you have tried to compile MySQL with the Sun compiler without enabling the -mt multi-thread option:

libc internal error: _rmutex_unlock: rmutex not held

Add -mt to CFLAGS and CXXFLAGS and recompile.

If you are using the SFW version of gcc (which comes with Solaris 8), you must add `/opt/sfw/lib' to the environment variable LD_LIBRARY_PATH before running configure.

If you are using the gcc available from sunfreeware.com, you may have many problems. To avoid this, you should recompile gcc and GNU binutils on the machine where you will be running them.

If you get the following error when compiling MySQL with gcc, it means that your gcc is not configured for your version of Solaris:

shell> gcc -O3 -g -O2 -DDBUG_OFF  -o thr_alarm ...
./thr_alarm.c: In function `signal_hand':
./thr_alarm.c:556: too many arguments to function `sigwait'

The proper thing to do in this case is to get the newest version of gcc and compile it with your current gcc compiler. At least for Solaris 2.5, almost all binary versions of gcc have old, unusable include files that will break all programs that use threads, and possibly other programs!

Solaris doesn't provide static versions of all system libraries (libpthreads and libdl), so you can't compile MySQL with --static. If you try to do so, you will get one of the following errors:

ld: fatal: library -ldl: not found
undefined reference to `dlopen'
cannot find -lrt

If you link your own MySQL client programs, you may see the following error at runtime:

ld.so.1: fatal: libmysqlclient.so.#:
open failed: No such file or directory

This problem can be avoided by one of the following methods:

If you have problems with configure trying to link with -lz when you don't have zlib installed, you have two options:

If you are using gcc and have problems with loading user-defined functions (UDFs) into MySQL, try adding -lgcc to the link line for the UDF.

If you would like MySQL to start automatically, you can copy `support-files/mysql.server' to `/etc/init.d' and create a symbolic link to it named `/etc/rc3.d/S99mysql.server'.

If too many processes try to connect very rapidly to mysqld, you will see this error in the MySQL log:

Error in accept: Protocol error

You might try starting the server with the --back_log=50 option as a workaround for this. (Use -O back_log=50 before MySQL 4.)

Solaris doesn't support core files for setuid() applications, so you can't get a core file from mysqld if you are using the --user option.

2.6.3.1 Solaris 2.7/2.8 Notes

Normally, you can use a Solaris 2.6 binary on Solaris 2.7 and 2.8. Most of the Solaris 2.6 issues also apply f