MySQL Reference Manual for version 3.22.14b-gamma.

1 General Information about MySQL

This is the MySQL reference manual; it documents MySQL version 3.22.14b-gamma.

MySQL is a very fast, multi-threaded, multi-user and robust SQL database server.

For Unix/OS2 platforms MySQL is basically free, for Microsoft platforms you must get a MySQL license after a trial time of 30 days. See section 3 Licensing or When do I have/want to pay for MySQL?.

The MySQL home page provides the latest information about MySQL.

For a discussion of MySQL's capabilities, see section 1.4 The main features of MySQL.

For installation instructions, see section 4 Installing MySQL. For tips on porting MySQL to new machines or operating systems, see section G Comments on porting to other systems.

See section 4.15.1 Upgrading from a 3.21 version to 3.22, for information about upgrading from a 3.21 release.

For examples of SQL and benchmarking information, see the `bench' directory.

For a history of new features and bug fixes, see section D MySQL change history.

For a list of currently known bugs and misfeatures, see section E Known errors and design deficiencies in MySQL.

For future plans, see section F List of things we want to add to MySQL in the future (The TODO).

For a list of all the contributors to this product, see section C Contributors to MySQL.

IMPORTANT:

Send bug (error) reports, questions and comments to the mailing list at

For source distributions, the mysqlbug script can be found in the `scripts' directory. For binary distributions, mysqlbug can be found in the `bin' directory.

If you have any suggestions concerning additions or corrections to this manual, please send them to the MySQL mailing list (mysql@tcx.se) with the following subject line: documentation suggestion: [Insert Topic Here]. See section 2.1 The MySQL mailing lists.

1.1 What is MySQL?

MySQL is a true multi-user, multi-threaded SQL (Structured Query Language) database server. SQL is the most popular database language in the world. MySQL is a client/server implementation that consists of a server daemon mysqld and many different client programs and libraries.

The main goals of MySQL are speed, robustness and ease of use. MySQL was originally developed because we at TcX needed a SQL server that could handle very large databases an order of magnitude faster than what any database vendor could offer to us. We have now been using MySQL since 1996 in an environment with more than 40 databases containing 10,000 tables, of which more than 500 have more than 7 million rows. This is about 100 gigabytes of mission-critical data.

The base upon which MySQL is built is a set of routines that have been used in a highly demanding production environment for many years. While MySQL is still in development, it already offers a rich and highly useful function set.

The official way to pronounce MySQL is "My Ess Que Ell" (Not MY-SEQUEL).

1.2 About this manual

This manual is currently available in TeXInfo, plain text, Info and HTML versions. Because of their size, PostScript and PDF versions are available for separate download.

The primary document is the TeXInfo file. The HTML version is produced automatically with 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 the Ghostscript utility ps2pdf.

This manual is written and maintained by David Axmark, Michael (Monty) Widenius, Paul DuBois and Kim Aldale. For other contributors, see section C Contributors to MySQL.

1.2.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 might be 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 for access privilege names (e.g., "do not grant the process privilege lightly") and occasionally to convey especially strong emphasis.

When commands are shown that are meant to be executed by a particular program, the prompt for the command indicates the program. For example, shell> indicates a command that you execute from your login shell, and mysql> indicates a command that you execute from the mysql client:

shell> type a shell command here
mysql> type a mysql command here

Shell commands are given using Bourne shell syntax. If you are using a csh-style shell, you may need to issue commands slightly 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, you would execute the sequence like this:

shell> setenv VARNAME value
shell> some_command

Database, table and column names often must be substituted into commands. To indicate that such substitution is necessary, this manual uses db_name, tbl_name and col_name. For example, if you see this:

mysql> SELECT col_name FROM db_name.tbl_name;

It means that were you 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 statements may be entered in uppercase or lowercase. When this manual shows a SQL statement, uppercase is used for particular keywords if those keywords are under discussion (to emphasize them) and lowercase for the rest of the statement. So you might see the following in a discussion of the SELECT statement:

mysql> SELECT count(*) FROM tbl_name;

On the other hand, in a discussion of the COUNT() function, the statement would be written like this:

mysql> select COUNT(*) from tbl_name;

If no particular emphasis is intended, all keywords are written in uppercase.

In syntax descriptions, square brackets (`[' and `]') are used to indicate optional words or clauses:

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. When one member from a set of choices must be chosen, the alternatives are listed within braces (`{' and `}'):

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)
{DESCRIBE | DESC} tbl_name {col_name | wild}

1.3 History of MySQL

We once started off with the intention to use mSQL to connect to our own fast low-level (ISAM) tables. 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 chosen to ease porting of third-party code.

The derivation of the name MySQL is not perfectly clear. Our base directory and a large number of our libraries and tools have had the prefix "my" for well over 10 years. However, Monty's daughter (some years younger) is also named My. So which of the two gave its name to MySQL is still a mystery, even for us.

1.4 The main features of MySQL

• Fully multi-threaded using kernel threads. That means it easily can use multiple CPUs if available.
• C, C++, Java, Perl, Python and TCL API's. See section 18 MySQL client tools and API's.
• Works on many different platforms. See section 4.2 Operating systems supported by MySQL.
• Many column types: signed/unsigned integers 1, 2, 3, 4 and 8 bytes long, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, DATETIME, TIMESTAMP, YEAR, SET and ENUM types. See section 7.2 Column types.
• Very fast joins using an optimized one-sweep multi-join.
• Full operator and function support in the SELECT and WHERE parts of queries. Example:

  mysql> SELECT CONCAT (first_name, " ", last_name) from tbl_name
             WHERE income/dependents > 10000 AND age > 30;
  

• SQL functions are implemented through a highly-optimized class library and should be as fast as they can get! Usually there shouldn't be any memory allocation at all after the query initialization.
• Full support for SQL GROUP BY and ORDER BY clauses. Support for group functions (COUNT(), AVG(), STD(), SUM(), MAX() and MIN()).
• Support for LEFT OUTER JOIN with ANSI SQL and ODBC syntax.
• You can mix tables from different databases in the same query (as of version 3.22).
• A privilege and password system which is very flexible and secure, and which allows host-based verification. Passwords are secure since all password traffic when connecting to a server is encrypted.
• ODBC (Open-DataBase-Connectivity) for Windows95 (with source). All ODBC 2.5 functions and many others. You can, for example, use Access to connect to your MySQL server. See section 15 MySQL ODBC Support.
• Very fast B-tree disk tables with index compression.
• 16 indexes per table are allowed. Each index may consist of 1 to 15 columns or parts of columns. The maximum index length is 256 bytes (this may be changed when compiling MySQL). An index may use a prefix of a CHAR or VARCHAR field.
• Fixed-length and variable-length records.
• In-memory hash tables which are used as temporary tables.
• Handles large databases. We are using MySQL with some databases that contain 50,000,000 records.
• All columns have default values; you can use INSERT to insert a subset of a table's columns and columns that were not explicitly given values will be set to their default values.
• Uses GNU Automake, Autoconf, and libtool for portability.
• Written in C and C++. Tested with a broad range of different compilers.
• A very fast thread-based memory allocation system.
• No memory leaks. Tested with a commercial memory leakage detector (purify).
• Includes isamchk, a very fast table check, optimize and repair utility. See section 13 Using isamchk for table maintenance and crash recovery.
• All data are saved in ISO-8859-1 Latin1 format. All comparisons for normal string columns are case insensitive.
• Full support for the ISO-8859-1 Latin1 character set. For example, the Scandinavian characters @ringaccent{a}, @"a and @"o are allowed in table and column names.
• Sorts according to the ISO-8859-1 Latin1 character set (the Swedish way at the moment). It is possible to change this in the source by adding new sort order arrays. To see an example of very advanced sorting, look at the Czech sorting code. MySQL supports many different character sets that can be specified at compile time.
• Aliases on tables and columns as in the SQL92 standard.
• DELETE, INSERT, REPLACE, and UPDATE return how many rows were affected.
• Function names do not clash with table or column names. For example, ABS is a valid column name. The only restriction is that for a function call, no spaces are allowed between the function name and the `(' that follows it. See section 7.30 Is MySQL picky about reserved words?.
• All MySQL programs can be invoked with the --help or -? options to obtain online assistance.
• The server can provide error messages to clients in many languages. See section 9.1 What languages are supported by MySQL?.
• Clients connect to the MySQL server using a TCP/IP connection or Unix socket.
• The MySQL-specific SHOW command can be used to retrieve information about databases, tables and indexes. The EXPLAIN command can be used to check how the optimizer resolves a query.

1.5 How stable is MySQL?

This section addresses the questions, "how stable is MySQL?" and, "can I depend on MySQL in this project?"

At TcX, MySQL has worked without any problems in our projects since mid-1996. When MySQL was released to a wider public, we noticed that there were some pieces of "untested code" that were quickly found by the new users who made queries in a different manner. Each new release has had fewer portability problems than the previous one, even though each has had many new features, and we hope that it will be possible to label one of the next releases "stable".

Each release of MySQL has been usable and there have been problems only when users start to use code from "the gray zones". Naturally, outside users can't know what the gray zones are; this section attempts to indicate those that are currently known.

Here we will try to clarify some issues and to answer some of the more important questions that seem to concern many people. This section has been put together from information gathered from the mailing list (which is very active in reporting bugs).

The descriptions deal with the 3.21.x version of MySQL. All known and reported bugs are fixed in the latest version, with the exception of the bugs listed in the BUGS file which are things that are "design"-related.

MySQL is written in multiple layers and different independent modules. Here is a list of the different modules and how well-tested each of them is:

The ISAM table handler -- Stable

This is how all the data are stored. In all MySQL releases there hasn't been a single (reported) bug in this code. The only known way to get a corrupted table is to kill the server in the middle of an update. Even that is unlikely to destroy any data beyond rescue, because all data are flushed to disk between each query. There hasn't been a single bug report about lost data because of bugs in MySQL, either.

The parser and lexical analyser -- Stable

There hasn't been a single reported bug in this system for a long time.

The C client code -- Stable

No known problems. In early 3.20 releases, there were some limitations in the send/receive buffer size. In 3.21.x, the send/receive buffer is now dynamic up to a default of 512K.

mysql, mysqladmin and mysqlshow, mysqldump,

and mysqlimport -- Stable

Basic SQL -- Stable

The basic SQL function system and string classes and dynamic memory handling. Not a single reported bug on this system.

Query optimizer -- Gamma

Range optimizer -- Stable

Join optimizer -- Stable

Locking -- Gamma

This is very system-dependent. On some systems there are big problems using standard OS locking (fcntl()). In these cases, you should run the MySQL daemon with the --skip-locking flag. Problems are known to occur on some Linux systems and on SunOS when using NFS-mounted file systems.

Linux threads -- Gamma

The only problem found has been with the fcntl() call, which is fixed by using the --skip-locking option to mysqld. Some people have reported lockup problems with the 0.5 release.

Solaris 2.5+ pthreads -- Stable

We use this for all our production work.

MIT-pthreads (Other systems) -- Gamma

There have been no reported bugs since 3.20.15 and no known bugs since 3.20.16. On some systems, there is a "misfeature" where some operations are quite slow (a 1/20 second sleep is done between each query). Of course, MIT-pthreads may slow down everything a bit, but index-based SELECT statements are usually done in one time frame so there shouldn't be a mutex locking/thread juggling.

Other thread implementions -- Alpha - Beta

The ports to other systems are still very new and may have bugs, possibly in MySQL, but most often in the thread implementation itself.

LOAD DATA ..., INSERT ... SELECT -- Stable

Some people have thought they have found bugs here, but these have turned out to be misunderstandings. So check the manual before reporting bugs!

ALTER TABLE -- Gamma

Small changes in 3.22.12

DBD -- Gamma

Now maintained by Jochen Wiedmann

mysqlaccess -- Gamma

Written and maintained by Yves Carlier

GRANT -- Alpha

Big changes done in MySQL 3.22.12.

MyODBC (uses ODBC SDK 2.5) -- Beta

It seems to work well with some programs.

TcX provides email support for paying customers, but the MySQL mailing list usually provides answers to common questions. Bugs are usually fixed right away with a patch; for serious bugs, there is almost always a new release.

1.6 Year 2000 compliance

MySQL itself has no problems with Year 2000 compliance:

• MySQL uses Unix time functions and has no problems with dates until 2069; all 2-digit years are regarded to be in the range 1970 to 2069, which means that if you store 01 in a year column, MySQL treats it as 2001.
• All MySQL date functions are stored in one file `sql/time.cc' and coded very carefully to be year 2000-safe.
• In MySQL 3.22 and later versions, the new YEAR column type can store years 0 and 1901 to 2155 in 1 byte and display them using 2 or 4 digits.

You may run into problems with applications that use MySQL in a way that is not Year 2000-safe. For example, many old applications store or manipulate years using 2-digit values (which are ambiguous) rather than 4-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, since different applications may be written by different programmers, each of whom may use a different set of conventions and date-handling functions.

Here is a simple test that shows that MySQL doesn't have any problems with dates until 2030 !

mysql> DROP TABLE IF EXISTS y2k;
mysql> CREATE TABLE y2k (date date, date_time datetime, time_stamp timestamp);
mysql> INSERT INTO y2k VALUES ("1998-12-31","1998-12-31 23:59:59",19981231235959);
mysql> INSERT INTO y2k VALUES ("1999-01-01","1999-01-01 00:00:00",19990101000000);
mysql> INSERT INTO y2k VALUES ("1999-09-09","1999-09-09 23:59:59",19990909235959);
mysql> INSERT INTO y2k VALUES ("2000-01-01","2000-01-01 00:00:00",20000101000000);
mysql> INSERT INTO y2k VALUES ("2000-02-28","2000-02-28 00:00:00",20000228000000);
mysql> INSERT INTO y2k VALUES ("2000-02-29","2000-02-29 00:00:00",20000229000000);
mysql> INSERT INTO y2k VALUES ("2000-03-01","2000-03-01 00:00:00",20000301000000);
mysql> INSERT INTO y2k VALUES ("2000-12-31","2000-12-31 23:59:59",20001231235959);
mysql> INSERT INTO y2k VALUES ("2001-01-01","2001-01-01 00:00:00",20010101000000);
mysql> INSERT INTO y2k VALUES ("2004-12-31","2004-12-31 23:59:59",20041231235959);
mysql> INSERT INTO y2k VALUES ("2005-01-01","2005-01-01 00:00:00",20050101000000);
mysql> INSERT INTO y2k VALUES ("2030-01-01","2030-01-01 00:00:00",20300101000000);
mysql> INSERT INTO y2k VALUES ("2050-01-01","2050-01-01 00:00:00",20500101000000);
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 | 19981231000000 |
| 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)
mysql> DROP TABLE y2k;

This shows that the DATE and DATETIME types are Date Data compliant, while the TIMESTAMP type, that is used to store the current time, only has a range up to 2030-01-01. TIMESTAMP has a range of 1970 to 2030 on 32-bit machines.

1.7 General SQL information and tutorials

This book has been recommended by a several people on the MySQL mailing list:

Judith S. Bowman, Sandra L. Emerson and Marcy Darnovsky
The Practical SQL Handbook: Using Structured Query Language
Second Edition
Addison-Wesley
ISBN 0-201-62623-3
http://www.awl.com

This book has also received some recommendations on the mailing list:

Martin Gruber
Understanding SQL
ISBN 0-89588-644-8
Publisher Sybex 510 523 8233
Alameda, CA USA

A SQL tutorial is available on the net at http://w3.one.net/~jhoffman/sqltut.htm.

1.8 Useful MySQL-related links

1.8.1 Web development tools that support MySQL

• PHP: A server-side HTML-embedded scripting language
• A JDBC driver for MySQL
• MySQL + PHP demos
• WWW-SQL: Display database information
• Minivend: A Web shopping cart
• HeiTML: A server-side extension of HTML and a 4GL language at the same time
• Metahtml: A Dynamic Programming Language for WWW Applications
• VelocityGen for Perl and TCL
• Hawkeye Internet Server Suite
• Network Database Connection For Linux
• WDB: Web browser as a universal front end to databases
• WebGroove Script: HTML compiler and server-side scripting language
• A server-side web site scripting language
• Visual Basic class generator for Active X
• How to use MySQL with Coldfusion on Solaris

1.8.2 Web servers with MySQL tools

• An Apache authentication module
• The Roxen Challenger Web server

1.8.3 Examples and source

• Examples using MySQL,
• A Contact Database using MySQL and PHP
• Web based interface and Community Calender with PHP
• Perl package to generate html from a SQL table structure and for generating SQL statements from an html form.
• Basic telephone database using DBI/DBD.
• TmySQL; A library to use MySQL with Delphi

1.8.4 Other MySQL-related links

• Links about using MySQL in Japan/Asia
• Commercial Web defect tracking system
• PTS: Project Tracking System
• Job and software tracking system
• Support for BIND (The Internet Domain Name Server)
• Registry of Web providers who support MySQL
• Full-text search engine using MySQL
• ExportSQL: A script to export data from Access95+
• SAL (Scientific Applications on Linux) MySQL entry
• MySQL Apps and Utilities Listing
• A consulting company which mentions MySQL in the right company
• PMP Computer Solutions. Database developers using MySQL and mSQL
• Airborne Early Warning Association
• MySQL UDF Registry

1.8.5 SQL and database interfaces

• The JDBC database access API
• MySQL binding to Free Pascal
• Patch for mSQL TCL
• EasySQL: An ODBC-like driver manager
• A REXX interface to SQL databases
• TCL interface
• Example of storing/retrieving images with MySQL and CGI

1.8.6 General database links

• Database Jump Site
• Homepage of the webdb-l (Web Databases) mailing list.
• Perl DBI/DBD modules homepage
• Cygwin tools (MySQL +Apache + PHP under Win32

There are also many web pages that use MySQL. See section A Some MySQL users. Send any additions to this list to

2 MySQL mailing lists and how to ask questions or report errors (bugs)

2.1 The MySQL mailing lists

Requests to be added to or dropped from the main MySQL mailing list should be sent to the electronic mail address mdomo@tcx.se. Sending a one-line message saying either subscribe mysql or unsubscribe mysql suffices. If your reply address is not valid, you may specify your address explicitly using subscribe mysql your-name@your.domain or unsubscribe mysql your-name@your.domain.

Please do not send mail about subscribing or unsubscribing to forwarded automatically to hundreds of other users.

Your local site may have many subscribers to mysql@tcx.se. If so, it may have a local mailing list, so that a single message from tcx.se is sent to the site and propagated to the local list. In such cases, please contact your system administrator to be added to or dropped from the local MySQL list.

Mail to mdomo@tcx.se is handled automatically by the Majordomo mailing list processor.

The following MySQL mailing lists exist:

mysql-announce

This is for announcement of new versions of MySQL and related programs. This is a low volume list that we think all MySQL users should be on.

mysql

The main list for general MySQL discussion. Please note that some things should go to the more-specialized lists. It you post to the wrong list, you may not get an answer!

mysql-digest

The mysql list in digest form. That means you get all individual messages, sent as one large mail message once a day.

mysql-Java

Discussion about MySQL and Java. Mostly about the JDBC drivers.

mysql-win32

All things concerning MySQL on Microsoft operating systems like Windows/NT.

myodbc

All things concerning connecting to MySQL with ODBC.

msql-mysql-modules

A list about the Perl support in MySQL.

msql-mysql-modules-digest

A digest version of the msql-mysql-modules list.

mysql-developer

A list for people who work on the MySQL code.

You subscribe or unsubscribe to all lists in the same way as described above. In your subscribe or unsubscribe request, just put the appropriate mailing list name rather than mysql.

2.2 Asking questions or reporting bugs

Before you ask a question on the mailing list, it is a good idea to check this manual. If you can't find an answer here, check with your local MySQL expert. If you still can't find an answer to your question, go ahead and read the next section about how to send mail to

2.3 How to report bugs / problems

Before posting a bug report / question, please start by searching the MySQL online manual http://www.mysql.com/Manual_chapter/manual_toc.html and in the MySQL mail archives. We try to keep the manual up to date and we constantly update this with solutions to new found problems! You can find the some search able mail archives at http://www.mysql.com/doc.html. You can also use http://www.mysql.com/search.html to search all the web pages (including the manual) at http://www.mysql.com.

Writing a good bug report takes patience, but doing it right at once saves time from us and from you. This section will help you writing your report right and prevents consuming your time doing things that may not help us much or at all.

We encourage everyone to use script mysqlbug to generate a bug report, or a report about any problem, if possible. The mysqlbug can be found from the `scripts' in the distribution or in the `bin' directory, where you have installed MySQL. If you are unable to use it, you should still include all the necessary information from this section.

The mysqlbug will help you making the report by automatically finding a lot of the following information, but if something important is missing, please include it with your message! Please read carefully this section and make sure you have all the information described here included in your report.

Remember that it is possible to answer a letter with too much information, but not the one with too little. Often people omit facts, because they think they know what is the reason for the problem and assume that some details don't matter. A good principle is: if you are in doubt to state something, state it! It is a thousand times faster and less troublesome to read a couple of lines more than to be forced to ask again and wait for the answer.

Most common errors are that people don't tell the MySQL version number they are using, or don't tell on what platform they have MySQL installed on, including the version number of the platform. This is very relevant information and in 99 cases out of 100 the bug report is useless without this information! Very often we get questions like 'Why doesn't this work for me?' and then we found that the quested feature wasn't yet implemented to that MySQL version, or there was a bug which was already fixed in the newer MySQL versions. Sometimes the error is platform depended and it is next to impossible to fix anything without knowing the operating system and the version number of the platform.

Remember also to give information about your compiler, if it is related to the problem. Often people found bugs in compilers and think the problem is MySQL related. Most compilers are under development all the time and become better version by version too. To verify, if the problem depends on compiler, we need to know what compiler is used. Note that every compiling problem should be regarded as a bug report and reported according to it.

Most helpful is when a good description of the problem is given. That is, a good example of all the things one did that leaded to the problem and the problem itself exactly described. The best bug reports are those that includes a full example how to reproduce the bug or problem.

If a program gives an error message, please include it. If we try to search something from the archives using programs, it is better that the error message is exactly the one that the program gave. (Even the case sensitivity should be observed!) This is the reason why >>cut'n'paste>> is the only right principle here!

• Version number of the MySQL you are using (for example, MySQL 3.22.12). You can find out which version you are running by executing mysqladmin version. mysqladmin can be found from the `bin' directory where MySQL is installed.
• The manufacturer and model of the machine you are working on.
• The operating system name and version. For most operating systems, you can get this by executing a Unix command uname -a.
• Sometimes the amount of memory is relevant. (real and virtual) If in doubt, include them.
• If one has the source distribution of MySQL, the information about the compiler used is needed. The name and the version number. If one has a binary distribution, the distribution name is needed.
• If the problem occurs during a compilation, include the exact error message(s) and also a few lines around the offending code in the file where the error occurred.
• Include the output from mysqldump --no-data database table1 table2..., if any table is related to the problem. This is very easy and a powerful way to get information about any table in a database and we will be able to create a situation that matches the one you have.
• In speed related bugs/problems with selects, one should always include the output of 'explain select ...' and at least the number of rows that the 'select ...' gives.
• If a problem / bug occurs while running MySQL, an input script, which will reproduce the bug, is needed. This script should include all the necessary source files, if any. The closer to the real situation the script will make, the better.
• If you think that MySQL gives a strange result from a query, include not only the result, but also your opinion what the result should be and some account for why.
• When giving an example of the problem, it's better to use same variable names, table names, etc. those exist in the real situation than come up with new names. The problem could be even a variable, table etc. name related! Rare case perhaps, but better safe than sorry. After all it should be easier for you to use the same situation in your example that you really had and it is by all means better for us. In case you have some data you don't want to show to others, you can use ftp to transfer the data to ftp://www.mysql.com/pub/mysql/secret. If the data is really top secret and you don't want to show it even to us, then go ahead and make an example using other variable names, etc., but please regard it as the last choice.
• If a program gives an error message, it is very important to state it! One should never try to remember what the error message was, but copy and paste the whole error message into the mail!
• Include all the options given to the relevant programs, if possible. For example, the options to the mysqld daemon and to any MySQL client programs. The options to mysqld ,mysql or to configure script are often keys to answers and very relevant! It is never a bad idea to include them anyway! If you use any modules, like Perl or PHP, please include the version number(s) of these.
• If you can't produce a test case in a few rows, or if the test table is too big to be mailed to everyone (more than 10 rows), you should dump your tables using mysqldump and create a `README' file that describes your problem. Use tar and gzip or zip on the files and use ftp to transfer the archive to ftp://www.mysql.com/pub/mysql/secret. Then send a short description of the problem to mysql@tcx.se.
• If your question is related to the privilege system, please include the output of mysqlaccess (can be found from the scripts directory), the output of mysqladmin reload and all the error messages you get when trying to connect! You should do all the tests in the order above!
• If you have a patch for a bug, it's good. If the patch is good, then very good. Still, don't expect that we will use the patch anyway and omit some necessary information, like a test case, thinking that the patch is all we need. We might found problems with your patch or don't understand it at all and if so, we don't use the patch. If we can't verify what the patch is exactly meant for, we don't use it. A test case will help us here. Show that the patch will handle all the situations that may happen. If we found, even a rare borderline case, there the patch won't work, the patch may be useless.
• A guess about what the bug is, why it occurs, or what it depends on, is usually wrong. Even we can't guess such things without first using a debugger to find out where the bug really comes from.
• Indicate in your mail message that you have checked the reference manual and mail archive so others know that you have tried to solve your problem yourself.
• If you get a parse error please check your syntax closely! If you can't find something wrong with it, it's extremely likely that your current version of MySQL doesn't support the query you are using! In this case you should check the MySQL change history for when the syntax was implemented! See section D MySQL change history If the manual at http://www.mysql.com/doc.html doesn't cover the query syntax you are using, this means that MySQL doesn't yet support this! In this case your only options are to implement this yourself or email
• If possible download the newest MySQL version and test if your problem is solved in this! All MySQL versions are throughly tested and should work without problems! We believe in making everything as backward compatible as possible and you should be able to switch MySQL version in minutes! See section 4.3 Which MySQL version to use.

If you are a support customer, please cross post the bug report to well as to the appropriate mailing list to see if someone else has experienced (and perhaps solved) the problem.

For information on reporting bugs in MyODBC, see section 15.2 How to report problems with MyODBC.

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 to that others may have the benefit of the responses you received that helped you solve your problem!.

2.3.1 What to do if MySQL keeps crashing

Since it is very hard to know why something is crashing, first try to check whether or not things that work for others crash for you. Please try the following things:

• Have you tried the benchmarks? This should test MySQL rather well. You can also add code that simulates your application!
• Try fork_test.pl and fork2_test.pl.
• If you configure MySQL for debugging, it will be much easier to find out possible errors if something goes wrong. See section 19.10 Debugging MySQL.
• Reconfigure MySQL with the --with-debug option to configure and then recompile. This causes a safe memory allocator to be included that can find some errors. It also provides a lot of output about what is happening.
• Use mysqld --log and try to determine from the information in the log whether or not some specific query kills the server. 95% of all bugs are related to some specific query!
• Have you applied the latest patches for your operating system?
• Use the --skip-locking option to mysqld. On some systems, the lockd lock manager does not work properly; the --skip-locking option tells mysqld not to use external locking. (This means that you cannot run 2 mysqld servers on the same data and you must be careful when using isamchk, but it may be instructive to try the option as a test.)
• Have you tried mysqladmin -u root processlist when mysqld appears to be dead? Sometimes mysqld is not dead even though you might think so. The problem may be that all connections are in use, or there may be some internal lock problem. mysqladmin processlist will usually be able to make a connection even in these cases, and can provide useful information about the current number of connections and their status.
• Run the command mysqladmin -i 5 status in a separate window to output statistics.
• Try the following:
  1. Start mysqld from gdb (or another debugger).
  2. Run your test scripts.
  3. Do back (or the backtrace command in your debugger) when mysqld core dumps.
• Try to simulate your application with a Perl script to force MySQL to crash or misbehave.
• Or send a normal bug report. See section 2.3 How to report bugs / problems. But be even more detailed than usual. Since MySQL works for many people it may be that the crash results from something that exists only on your computer (for example, an error that is related to your particular system libraries).

2.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, but don't feel obliged to quote the whole question.

Please don't post mails from your browser with HTML mode turned on! Many users doesn't read mails with a browser!

3 Licensing or When do I have/want to pay for MySQL?

The basic licensing issues are:

• The easiest way to pay for MySQL is to use the license form at TcX's secure server at https://www.tcx.se/license.htmy.
• We hope everybody understands that you only have to pay if you are selling MySQL directly, selling a product which includes the MySQL server or installing and maintaining a MySQL server at some client site. You may not include MySQL in a distribution if you charge for some part of the distribution. For internal use, you do not have to pay us if you do not want to.
• There is no restriction in the number of clients that connects to a MySQL server or the number of MySQL servers that runs on one machine!
• You do not need a license to include client code in commercial programs. The client access part of MySQL is in the public domain. The command line client (mysql) includes parts that are under the GNU Public License (readline).
• We may add some additional functionality in the commercial version. The likely test candidate for this is the ability to create fast compressed read-only databases. The current server includes support to read such databases but not the packing tool used to create them. If we get enough revenue from support, we will probably release this under the same license as the other stuff.
• But if you like MySQL and want to encourage further development you are welcome to purchase a license or support.

See section J The MySQL server license for non Microsoft operating systems.

3.1 How much MySQL costs

For normal use on Unix or OS/2, MySQL costs nothing. When you sell MySQL, directly or as a part of another product, you have to pay for it. See section J The MySQL server license for non Microsoft operating systems.

For use on Win95/Win98/NT you will need a MySQL license after a trial time of 30 days. You can of course first try the shareware version before buying! http://www.mysql.com/mysql_w32.htmy,MySQL -Win32

Some examples about when you need a MySQL license on Unix / OS/2.

•

If you use MySQL to store data for www server you don't have to pay for a license.

•

If a customer sets and administrates a MySQL server on your machine for himself, neither you or he needs a MySQL license.

•

If you set up a MySQL server for a paying client you will need a license for the machine that runs the mysqld server. This is because you are in this case selling a system with MySQL. Note that the single MySQL license will cover any number of users/customers on this machine!

•

If you on install MySQL on a clients machine and any money changes hands (directly or indirectly) then you must buy a MySQL license!

•

If you sell a product, that will be installed at the customers machine, that REQUIRES MySQL to work, you will need a license. See section 3.7 Selling a product that can be configured to use MySQL.

If your use of MySQL requires a license (see section 3 Licensing or When do I have/want to pay for MySQL?), you only need to get a license for each machine that runs the mysqld server. A multi-CPU machine counts as one machine. There is no restriction on the number of concurrent users connected to a machine running a mysqld server.

Our current license prices are shown below. All prices are in US Dollars. If you pay by credit card, the currency is EURO (European Union Euro) so the prices will differ slightly.

For high volume (OEM) purchases, the following prices apply:

For OEM purchases, you must act as a middle-man for eventual problems or extension requests from users. We also require OEM customers to have a support contract.

If you have a low-margin high-volume product, you can always talk to us about other terms (for example, a percent of the sale price). If you do, please be informative about your product, pricing, market and any other information that may be relevant.

3.2 How to get commercial support

A full-price license includes really basic support. This means that we try to answer any relevant question. If the answer is in the documentation, we will direct you to the appropriate section. If you do not have a license or support, we probably will not answer at all.

If you discover what we consider a real bug, we are likely to fix it in any case. But if you pay for support we will notify you about the fix status instead of just fixing it in a later release.

More comprehensive support is sold separately. Costs for the various types of commercial support are shown below, and the following sections describe what each level of support includes. You are entitled to upgrade from any lower level of support to a higher level of support for the difference between the prices of the two support levels.

Support level prices are in EURO (European Union Euro). One EURO is about 1.17 USD.

3.2.1 Basic email support

Basic email support includes the following types of service:

• For MySQL-specific questions that don't belong on the MySQL mailing list (mysql@tcx.se), you can contact registration number and expiration date to ensure a quick response from mysql-support@tcx.se. You can also crosspost your questions to any of the standard MySQL mailing lists, as someone else may already have experienced and solved the problem/question you have.
• If your question is already answered in the manual, we will inform you of the correct section in which you can find the answer. If the answer is not in the manual, we will point you in the right direction to solve your problem.
• We guarantee a timely answer for your email messages. We can't guarantee that we can solve any problem, but at least you will receive an answer if we can contact you by email.
• We will help with unexpected problems when you install MySQL from a binary distribution on supported platforms. This level of support does not cover installing MySQL from a source distribution.
• We will help you with bugs and missing features. Any bugs that are found are fixed for the next MySQL release. If the bug is critical for you, we will mail you a patch for it as soon the bug is fixed. Critical bugs always have the highest priority for us, to ensure that they are fixed as soon as possible.
• Your suggestions for the further development of MySQL will be taken into consideration. By taking email support you have already helped the further development of MySQL. If you want to have more input, upgrade to a higher level of support.
• If you want us to help optimize your system, you have to upgrade to a higher level of support.

Basic email support is a very inexpensive support option and should be thought of more as a way to support our development of MySQL than as a real support option.

3.2.2 Extended email support

Extended basic support includes everything in basic email support with these additions:

• Your email will be dealt with before mail from basic email support users and non-registered users.
• Your suggestions for the further development of MySQL will receive strong consideration. Simple extensions that suit the basic goals of MySQL are implemented in a matter of days. By taking extended email support you have already helped the further development of MySQL.
• We include a binary version of the pack_isam tool that supports fast compressed read-only databases (no BLOB or TEXT types yet). The current server includes support to read such databases but not the packing tool.
• Typical questions that are covered by extended email support are:
  • We will answer and (within reason) solve questions that relate to possible bugs in MySQL. As soon as the bug is found and corrected, we will mail a patch for it.
  • We will help with unexpected problems when you install MySQL from a source or binary distribution on supported platforms.
  • We will answer questions about missing features and offer hints how to work around them.
  • We will provide hints on optimizing mysqld for your situation.
• You are allowed to influence the priority of items on the MySQL TODO. This will ensure that the features you really need will be implemented sooner than they might be otherwise.

3.2.3 Login support

Login support includes everything in extended basic email support with these additions:

• Your email will be dealt with even before mail from extended support users.
• Your suggestions for the further development of MySQL will be taken into very high consideration. Realistic extensions that can be implemented in a couple of hours and that suit the basic goals of MySQL will be implemented as soon as possible.
• If you have a very specific problem, we can try to log in on your system to solve the problem "in place".
• Like any database vendor, we can't guarantee that we can rescue any data from crashed tables, but if the worst happens we will help you rescue as much as possible. MySQL has proven itself very reliable, but anything is possible due to circumstances beyond our control (for example, if your system crashes or someone kills the server with kill -9).
• We will provide hints on optimizing your system and your queries.
• You are allowed to call a MySQL developer (in moderation) and discuss your MySQL-related problems.

3.2.4 Extended login support

Extended login support includes everything in login support with these additions:

• Your email has the highest possible priority.
• We will actively examine your system and help you optimize it and your queries. We may also optimize and/or extend MySQL to better suit your needs.
• You may also request special extensions just for you. For example:

  mysql> select MY_CALCULATION(col_name1,col_name2) from tbl_name;
  

• We will provide a binary distribution of all important MySQL releases for your system, as long as we can get an account on a similar system. In the worst case, we may require access to your system to be able to create a binary distribution.
• If you can provide accommodations and pay for traveler fares, you can even get a MySQL developer to visit you and offer you help with your troubles. Extended login support entitles you to one personal encounter per year, but we are as always very flexible towards our customers!

3.3 How to pay for licenses or support

Currently we can take SWIFT payments, cheques or credit cards.

Payment should be made to:

Postgirot Bank AB
105 06 STOCKHOLM, SWEDEN

T.C.X DataKonsult AB
BOX 6434
11382 STOCKHOLM, SWEDEN

SWIFT address: PGSI SESS
Account number: 96 77 06 - 3

Specify: license and/or support and your name and email address.

In Europe and Japan you can use EuroGiro (that should be less expensive) to the same account.

If you want to pay by cheque, make it payable to "Monty Program KB" and mail it to the address below:

T.C.X DataKonsult AB
BOX 6434
11382 STOCKHOLM, SWEDEN

If you want to pay with credit card over the Internet, you can use TCX's secure license form.

You can also print a copy of the above page, fill it in and send it by fax to:

+46-8-729 69 05

If you want us to bill you, you can use the license form and write "bill us" in the comment field. You can also mail a message to to bill you.

3.4 Who to contact for more information about licensing or support

For commercial licensing, or if you have any questions about any of the information in this section, please contact:

David Axmark
Detron HB
Kungsgatan 65 B
753 21 UPPSALA
SWEDEN
Voice Phone +46-18-10 22 80     (Swedish and English spoken)
Fax +46-8-729 69 05             (Email *much* preferred)
E-Mail: mysql-licensing@tcx.se

3.5 What copyrights MySQL uses

There are several different copyrights on the MySQL distribution:

1. The MySQL-specific source needed to build the mysqlclient library and programs in the `client' directory is in the public domain. Each file that is in the public domain has a header which clearly states so. This includes everything in the `client' directory and some parts of the mysys, mystring and dbug libraries.
2. Some small parts of the source (GNU getopt) are covered by the "GNU LIBRARY LIBRARY GENERAL PUBLIC LICENSE". See the `mysys/COPYING.LIB' file.
3. Some small parts of the source (GNU readline) are covered by the "GNU GENERAL PUBLIC LICENSE". See the `readline/COPYING' file.
4. Some parts of the source (the regexp library) are covered by a Berkeley style copyright.
5. The other source needed for the MySQL server on Unix platforms is covered by the "MySQL FREE PUBLIC LICENSE", which is based on the "Aladdin FREE PUBLIC LICENSE." See section J The MySQL server license for non Microsoft operating systems. When running MySQL on any Microsoft operating system, other licensing applies. See section K The MySQL license for Microsoft operating systems

The following points set forth the philosophy behind our copyright policy:

• The SQL client library should be totally free so that it can be included in commercial products without limitations.
• People who want free access to the software we have put a lot of work into can have it, so long as they do not try to make money directly by distributing it for profit.
• People who want the right to keep their own software proprietary, but also want the value from our work, can pay for the privilege.
• That means normal in-house use is FREE. But if you use it for something important to you, you may want to support further development of MySQL by purchasing a support contract.

3.6 When you may distribute MySQL commercially without a fee

This is a clarification of the information in the "MySQL FREE PUBLIC LICENSE" (FPL). See section J The MySQL server license for non Microsoft operating systems.

MySQL may be used freely, including by commercial entities for evaluation or unsupported internal use. However, distribution for commercial purposes of MySQL, or anything containing or derived from MySQL in whole or in part, requires a written commercial license from TcX AB, the sole entity authorized to grant such licenses.

You may not include MySQL "free" in a package containing anything for which a charge is being made, except as noted below.

The intent of the exception provided in the second clause of the license is to allow commercial organizations operating an FTP server or a bulletin board to distribute MySQL freely from it, provided that:

1. The organization complies with the other provisions of the FPL, which include among other things a requirement to distribute the full source code of MySQL and of any derived work, and to distribute the FPL itself along with MySQL;
2. The only charge for downloading MySQL is a charge based on the distribution service and not one based on the content of the information being retrieved (i.e., the charge would be the same for retrieving a random collection of bits of the same size);
3. The server or BBS is accessible to the general public, i.e., the phone number or IP address is not kept secret, and anyone may obtain access to the information (possibly by paying a subscription or access fee that is not dependent on or related to purchasing anything else).

If you want to distribute software in a commercial context that incorporates MySQL and you do not want to meet these conditions, you should contact TcX AB to find out about commercial licensing. Commercial licenses involve a payment, and include support and other benefits. These are the only ways you legally can distribute MySQL or anything containing MySQL: either by distributing MySQL under the requirements of the FPL, or by getting a commercial license from TcX AB.

3.7 Selling a product that can be configured to use MySQL

If you want to sell a product that can be configured to use MySQL although your customer is responsible for obtaining/installing MySQL (or some other supported alternative), does one of you owe us money if your customer chooses to use MySQL?

If your product REQUIRES MySQL to work, you would have to buy a license. If MySQL just added some new features, it should fall inside normal use. For example, if using MySQL added logging to a database rather than to a text file, it would not require a license. This would, of course, mean that the user bears the responsibility of obtaining and installing MySQL. If the program is (almost) useless without MySQL you would have to get a MySQL license to sell your product.

3.8 Running a commercial web server using MySQL

If you run a commercial web server that uses MySQL, you are not selling MySQL itself and need not purchase a license. However, in this case we would like you to purchase MySQL support. That is either your support of MySQL or our support of you (the latter is more expensive since our time is limited).

3.9 Selling commercial Perl/Tcl/PHP/etc. applications

These are the questions you should ask to determine whether or not you need a MySQL license when selling your application: Is your application designed for MySQL alone? Does it require MySQL to function at all? Or is it designed more generally for "a database" and can run under MySQL, PostgreSQL, or something else?

If you've designed it strictly around MySQL then you've really made a commercial product that requires the engine, so you need to buy a license.

If, however, you can support any database with a base level of functionality (and you don't rely on anything that only MySQL supports) you probably DO NOT have to pay.

It also depends on what you're doing for the client. Are you tying into a database you expect to already exist by the time your software is purchased? Then you probably don't have to pay. Or do you plan to distribute MySQL or give them detailed instructions on installing it with your software? Then you probably do.

One thing I'd like to suggest, folks. Look, development won't last forever if nobody pays. I agree that buying a copy for every software user is prohibitive compared to other products available, but would it not be courtesy for commercial developers to register their OWN copy that they develop with?

3.10 Possible future changes in the licensing

We may choose to distribute older versions of MySQL with the GPL in the future. However, these versions will be identified as GNU MySQL. Also, all copyright notices in the relevant files will be changed to the GPL.

4 Installing MySQL

4.1 How to get MySQL

Check the MySQL home page for information about the current version and for downloading instructions.

However, the Internet connection at TcX is not so fast; we would prefer that you do the actual downloading from one of the mirror sites listed below.

Please report bad or out of date mirrors to webmaster@tcx.se.

Europe:

• Austria [Univ. of Technology/Vienna] WWW FTP
• Bulgaria [Naturella] FTP
• Czech Republic [CESNET] WWW
• Denmark [Ake] WWW
• Denmark [SunSITE] WWW FTP
• Estonia [Tradenet] WWW
• Germany [Bonn University, Bonn] WWW FTP
• Germany [Wolfenbuettel] WWW FTP
• Germany [Staufen] WWW
• Greece [NTUA, Athens] WWW FTP
• Hungary [Xenia] WWW
• Israel [Netvision] WWW
• Italy [Matrice] WWW
• Poland [Sunsite] WWW FTP
• Russia [DirectNet] WWW
• Russia [Cityline] FTP WWW
• Romania [Timisoara] WWW FTP
• Romania [Bucharest] WWW FTP
• Sweden [Sunet] WWW FTP
• UK [Omnipotent/UK] WWW FTP
• UK [PLiG/UK] WWW FTP
• UK [SunSITE] WWW FTP
• Ukraine [PACO] WWW FTP

North America:

• Canada [Polaris Computing] WWW
• Canada [Tryc] WWW
• Canada [Cyberus] WWW FTP
• USA [Hurricane Electric/San Jose] WWW
• USA [Buoy/New York] WWW
• USA [Netcasting/West Coast] FTP
• USA [Circle Net/North Carolina] WWW
• USA [Gina net/Florida] WWW
• USA [DIGEX] FTP

South America:

• Chile [Amerikanclaris] WWW FTP

Asia:

• Korea [KREONet] WWW
• Japan [Soft Agency] WWW
• Japan [Nagoya Syouka University] WWW FTP
• Japan [HappySize] WWW FTP
• Singapore [Com5 Productions] WWW FTP
• Taiwan [NCTU] WWW

Australia:

• Australia [AARNet/Queensland] WWW FTP
• Australia [Tas] WWW FTP
• Australia [Blue Planet/Melbourne] WWW FTP

Africa:

• South-Africa [The Internet Solution/Johannesburg] FTP

4.2 Operating systems supported by MySQL

We use GNU Autoconf so it is possible to port MySQL to all modern systems with working Posix threads and a C++ compiler. The client code requires C++ but not threads. We use and develop the software ourselves primarily on Sun Solaris (versions 2.5 & 2.6) and to a lesser extent on RedHat Linux 5.0.

MySQL has been reported to compile sucessfully on the following operating system/thread package combinations. Note that for many operating systems, the native thread support works only in the latest versions.

• Solaris 2.5, 2.6 and 2.7 with native threads on sparc and x86
• SunOS 4.x with the included MIT-pthreads package
• BSDI 2.x with the included MIT-pthreads package
• BSDI 3.0 and 3.1 with native threads
• SGI IRIX 6.x with native threads
• AIX 4.x with native threads
• DEC UNIX 4.x with native threads
• Linux 2.0+ with LinuxThreads 0.7.1 or glibc 2.0.7
• FreeBSD 2.x with the included MIT-pthreads package
• FreeBSD 3.x with native threads
• SCO OpenServer with a recent port of the FSU-threads package
• SCO UnixWare 7.0.1
• NetBSD 1.3 Intel and NetBSD 1.3 Alpha
• OpenBSD 2.x with the included MIT-pthreads package
• HP-UX 10.20 with the included MIT-pthreads package
• Win95 and NT (The newest version is currently available only for users with a MySQL license or MySQL email support). We have released an older http://www.mysql.com/mysql_w32.htmy,MySQL version (3.21.29) as shareware for those who like to test before they buy.
• OS/2

4.3 Which MySQL version to use

The first decision to make is whether you want to use the latest development release or the last stable release.

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 development release. This is because there are usually no really bad bugs in the development release, and you can easily test it on your machine with the crash-me and benchmark tests. See section 11 The MySQL benchmark suite.

Otherwise, if you are running an old system and want to upgrade, but don't want to take chances with 3.22, you should upgrade to 3.21.33. We have tried to fix only fatal bugs and make small, relatively safe changes in this version.

The second decision to make is whether you want to use a source distribution or a binary distribution:

• If you want to run MySQL on a platform for which a current binary distribution exists, use that. It generally will be easier to install than a source distribution.
• If you want to read (and/or modify) the C and C++ code that makes up MySQL, you should get a source distribution. The source code is always the ultimate manual. Source distributions also contain more tests and examples than binary distributions.

In the MySQL naming scheme, release numbers consist of three numbers and a suffix. For example, a release name like mysql-3.21.17-beta is interpreted like this:

• The first number (3) describes the file format. All version 3 releases have the same file format. When a version 4 appears, every table will have to be converted to the new format (nice tools for this will be included, of course).
• The second number (21) is the release level. Normally there are two to choose from. One is the release/stable branch and the other is the development branch. Normally both are stable but the development version may have quirks, missing documentation or may fail to compile on some systems.
• The third number (17) is the version number within the release level. This is incremented for each new distribution. Usually you want the latest version for the release level you have choosen.
• The suffix (beta) indicates the stability level of the release:
  • alpha means that some new large code section exists which hasn't been 100% tested. Known bugs should be documented in the News section (usually there are none). See section D MySQL change history. There are also new commands and extensions in most alpha releases.
  • beta means that all new code has been tested. No major new things are added. There should be no known bugs.
  • gamma is a beta that has been around a while and seems to work fine. This is what many other companies call a release.
  • If there is no suffix, it means that the version has been run for a while at many different sites with no reports of bugs other than platform-specific bugs.

All versions of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Since the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better.

Note that all releases have been tested at least with:

An internal test suite

This is part of a production system for a customer. It has many tables with hundreds of megabytes of data.

The MySQL benchmark suite

This 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 11 The MySQL benchmark suite.

The crash-me test

This tries to determine what features the database supports and what its capabilities and limitations are. See section 11 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 100 gigabytes of data to work with.

4.4 How and when updates are released

Well, MySQL is evolving quite rapidly here at TcX and we want to share this with other MySQL users. We try to make a release when we have a very useful feature that others seem to have a need for.

We also try to help out users who request features that are easy to implement. We also take note on what our licensed users want to have and we especially take notes 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 D MySQL change history.

We use the following policy when updating MySQL:

• 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.
• Stable tested releases are meant to appear about 1-2 times a year, but if small bugs are found, a release with only bug-fixes will be released.
• Working releases are meant to appear about every 1-8 weeks.
• Binary distributions for some platforms will be made by us for major releases. Other people may make binary distributions for other systems but probably less frequently.
• We usually make patches available as soon as we have located and fixed small bugs.
• For non-critical but annoying bugs, we will make patches available if they are sent to us. Otherwise we will combine many of them into a bigger patch.
• If there is, by any chance, a fatal bug in a release we will make a new release as soon as possible. We would like other companies to do this, too. :)

The 3.21.x version incorporates major portability changes for many different systems. When the 3.21 release is stable, we will remove the alpha/beta suffix and move active development to 3.22. Bugs will still be fixed in the stable version. We don't believe in a complete freeze, as this also leaves out bug fixes 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".

4.5 Installation layouts

This section describes the default layout of the directories created by installing binary and source distributions.

A binary distribution is installed by unpacking it at the installation location you choose and creates the following directories in the location you choose (typically `/usr/local/mysql'):

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:

The layout of a source installation differs from that of a binary installation in the following ways:

• The mysqld server is installed in the `/usr/local/libexec' directory rather than in `/usr/local/mysql/bin'.
• The data directory is `/usr/local/var' rather than `/usr/local/mysql/data'.
• mysql_install_db is installed in the `/usr/local/bin' directory rather than in `/usr/local/mysql/scripts'.

4.6 Installing a MySQL binary distribution

The basic commands you have to do to use a MySQL binary distribution are:

shell> bin/mysql_install_db
shell> bin/safe_mysqld &

Here follows a more detailed description:

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

• GNU gunzip to uncompress the distribution.
• A reasonable tar to unpack the distribution. GNU tar is known to work.

If you run into problems, PLEASE ALWAYS USE mysqlbug when posting questions to mysql@tcx.se. 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 2.3 How to report bugs / problems.

To install a binary distribution, follow the steps below, then proceed to section 4.14 Post-installation setup and testing, for post-installation setup and testing.

1. Pick the directory under which you want to unpack the distribution, and move into it. In the example below, we unpack the distribution under `/usr/local' and create a directory `/usr/local/mysql' into which MySQL is installed. (The following instructions therefore assume you have permission to create files in `/usr/local'. If that directory is protected, you will need to perform the installation as root.)
2. Obtain a distribution file from one of the sites listed in section 4.1 How to get MySQL. MySQL binary distributions are provided as compressed tar archives and have names like `mysql-VERSION-OS.tar.gz', where VERSION is a number (e.g., 3.21.15), and OS indicates the type of operating system for which the distribution is intended (e.g., pc-linux-gnu-i586).
3. Unpack the distribution and create the installation directory:

   shell> gunzip < mysql-VERSION-OS.tar.gz | tar xvf -
   shell> ln -s mysql-VERSION-OS mysql
   

   The first command creates a directory named `mysql-VERSION-OS'. The second command makes a symbolic link to that directory. This lets you refer more easily to the installation directory as `/usr/local/mysql'.
4. Change 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.

   `scripts'

   This directory contains the mysql_install_db script used to initialize the server access permissions

5. If you would like to use mysqlaccess and have the MySQL distribution in some nonstandard 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.
6. If you want to install support for the Perl DBI/DBD interface, see section 4.10 Perl installation comments.
7. If you would like MySQL to start automatically when you boot your machine, you can copy bin/mysql.server to where your system has its startup files. More information can be found in the bin/mysql.server script itself, and in section 4.14.3 Automatically starting and stopping MySQL.

After everything has been unpacked and installed, you should initialize and test your distribution. See section 4.14 Post-installation setup and testing.

4.6.1 Building client programs

If you compile MySQL clients that you've written yourself or that you obtain from a third party, they must be linked using the -lmysqlclient option on the link command. You may also need to specify a -L option to tell the linker where to find the library. For example, if the library is installed in `/usr/local/mysql/lib', use -L/usr/local/mysql/lib -lmysqlclient on the link command.

For clients that use MySQL header files, you may need to specify a -I option (for example, -I/usr/local/mysql/include) when you compile them, so the compiler can find the header files.

4.6.2 System-specific notes

The following sections indicate some of the issues that have been observed to occur on particular systems.

4.6.2.1 Linux notes

• MySQL needs at least Linux 2.0.
• The binary release is linked with -static, which means you need not worry about which version of the system libraries you have. You need not install LinuxThreads, either. A program linked with -static is slightly bigger than a dynamically-linked program but also slightly faster (3-5%). The only problem is that you can't use user definable functions (UDFs) with a statically-linked program. If you are going to write or use UDF functions (this is only something for C or C++ programmers) you must compile MySQL yourself, using dynamic linking.
• The Linux-Intel binary release of MySQL is configured for the highest possible speed. We are even using the Pentium compiler, pgcc. This compiler is installed under the name gcc and the distribution is configured as follows:

  shell> CC=gcc \
         CFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer" \
         CXX=gcc \
         CXXFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer -felide-constructors" \
         ./configure \
             --prefix=/usr/local/mysql \
             --enable-assembler \
             --with-mysqld-ldflags=-all-static
  

• MySQL Perl support requires Perl 5.004_03 or newer.

4.6.2.2 HP-UX notes

The binary distribution of MySQL for HP-UX is distributed as an HP depot file. This means that you must be running at least HP-UX 10.x to have access to HP's software depot tools.

The HP version of MySQL was compiled on an HP 9000/8xx server under HP-UX 10.20, and uses MIT-pthreads. It is known to work well under this configuration. This version does not use HP's native thread package. It is highly unlikely that MySQL will use HP native threads on anything but HP-UX 10.30 or later.

Other configurations that may work:

• HP 9000/7xx running HP-UX 10.20+
• HP 9000/8xx running HP-UX 10.30 (does not use HP native threads)

The following configurations almost definitely won't work:

• HP 9000/7xx or 8xx running HP-UX 10.x where x < 2
• HP 9000/7xx or 8xx running HP-UX 9.x

To install the distribution, use one of the commands below, where /path/to/depot is the full path to the depot file:

• To install everything, including the server, client and development tools:

  /usr/sbin/swinstall -s /path/to/depot mysql.full
  

• To install only the server:

  /usr/sbin/swinstall -s /path/to/depot mysql.server
  

• To install only the client package:

  /usr/sbin/swinstall -s /path/to/depot mysql.client
  

• To install only the development tools:

  /usr/sbin/swinstall -s /path/to/depot mysql.developer
  

The depot places binaries and libraries in `/opt/mysql' and data in `/var/opt/mysql'. The depot also creates the appropriate entries in `/sbin/init.d' and `/sbin/rc2.d' to start the server automatically at boot time. Obviously, this entails being root to install.

4.7 Installing a MySQL source distribution

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

• GNU gunzip to uncompress the distribution.
• A reasonable tar to unpack the distribution. GNU tar is known to work.
• A working ANSI C++ compiler. gcc >= 2.8.1, egcs >= 1.0.2, SGI C++ and SunPro C++ are some of the compilers that are known to work. libg++ is not needed when using gcc. gcc 2.7.x has a bug that makes it impossible to compile some perfectly legal C++ files, such as `sql/sql_base.cc'. If you only have gcc 2.7.x, you must upgrade your gcc to be able to compile MySQL.
• A good make program. GNU make is always recommended and is sometimes required. If you have problems, we recommend trying GNU make 3.75 or newer.

If you run into problems, PLEASE ALWAYS USE mysqlbug when posting questions to mysql@tcx.se. 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 2.3 How to report bugs / problems.

4.7.1 Quick installation overview

The basic commands you have to do to install MySQL from source are:

shell> configure --prefix=/usr/local/mysql
shell> make
shell> make install
shell> scripts/mysql_install_db
shell> /usr/local/mysql/bin/safe_mysqld &

Here follows a more detailed description:

To install a source distribution, follow the steps below, then proceed to section 4.14 Post-installation setup and testing, for post-installation initialization and testing.

1. Pick the directory under which you want to unpack the distribution, and move into it.
2. Obtain a distribution file from one of the sites listed in section 4.1 How to get MySQL. MySQL source distributions are provided as compressed tar archives and have names like `mysql-VERSION.tar.gz', where VERSION is a number like 3.22.14b-gamma.
3. Unpack the distribution into the current directory:

   shell> gunzip < mysql-VERSION.tar.gz | tar xvf -
   

   This command creates a directory named `mysql-VERSION'.
4. Change into the top-level directory of the unpacked distribution:

   shell> cd mysql-VERSION
   

5. Configure the release and compile everything:

   shell> ./configure
   shell> make
   

   When you run configure, you might want to specify some options. Run ./configure --help for a list of options. section 4.7.3 Typical configure options, discusses some of the more useful options. If configure fails, and you are going to send mail to `config.log' that you think can help solve the problem. Also include the last couple of lines of output from configure if configure aborts. Post the bug report using the mysqlbug script. See section 2.3 How to report bugs / problems. If the compile fails, see section 4.8 Problems compiling?, for help with a number of common problems.
6. Install everything:

   shell> make install
   

   You might need to run this command as root.
7. Create the MySQL grant tables

   shell> scripts/mysql_install_db
   

8. If you want to install support for the Perl DBI/DBD interface, see section 4.10 Perl installation comments.
9. If you would like MySQL to start automatically when you boot your machine, you can copy support-files/mysql.server to where your system has its startup files. More information can be found in the support-files/mysql.server script itself, and in section 4.14.3 Automatically starting and stopping MySQL.

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

You can start the MySQL server with:

shell> cd mysql-install-directory
shell> bin/safe_mysqld &

Note that MySQL versions before 3.22.10 started the MySQL server when you run mysql_install_db. This is no longer true!

See section 4.14 Post-installation setup and testing.

4.7.2 Applying patches

Sometimes patches appear on the mailing list. To apply a patch, change into the top-level directory of your MySQL source tree and run these commands:

shell> gunzip < patch-file-name.gz | patch -p1
shell> rm config.cache
shell> make clean

Then follow the instructions for a normal source install, beginning with the ./configure step. After running the make install step, restart your MySQL server.

You may need to bring down any currently running server before you run make install. Some systems do not allow you to install a new version of a program if it replaces the version that is currently executing.

4.7.3 Typical configure options

The configure script gives you a great deal of control over how you configure your MySQL distribution. Typically you do this using options on the configure command line. You can also affect configure using certain 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 below:

• To compile just the MySQL client libraries and client programs, use the --without-server option:

  shell> ./configure --without-server
  

  If you don't have a C++ compiler, mysql will not compile (it is the one client program that requires C++). In this case, you can remove the code in configure that tests for the C++ compiler and then run ./configure with the --without-server option. The compile step will still try to build mysql, but you can ignore any warnings about `mysql.cc'. (If make stops, try make -k to tell it to continue with the rest of the build even if errors occur.)
• If you don't want your log files and database directories located under `/usr/local/var', use a configure command something like one of these:

  shell> ./configure --prefix=/usr/local/mysql
  shell> ./configure --prefix=/usr/local \
             --localstatedir=/usr/local/mysql/data
  

  The first command changes the installation prefix so that everything is installed under `/usr/local/mysql' rather than the default of `/usr/local'. The second command preserves the default installation prefix, but overrides the default location for database directories (normally `/usr/local/var') and changes it to /usr/local/mysql/data.
• If you want your sockets located somewhere other than the default location (normally `/tmp' or `/var/run'), use a configure command like this:

  shell> ./configure --with-unix-socket-path=/path/to/socket/dir
  

  `/path/to/socket/dir' must be an absolute pathname.
• If you want to compile statically-linked programs (e.g., to make a binary distribution, to get more speed or to work around problems with some RedHat distributions), run configure like this:

  shell> ./configure --with-client-ldflags=-all-static \
             --with-mysqld-ldflags=-all-static
  

• If you are using gcc and don't have libg++ or libstdc++ installed, you can tell configure to use gcc as your C++ compiler:

  shell> CC=gcc CXX=gcc ./configure
  

  When you use gcc as your C++ compiler, it will not attempt to link in libg++ or libstdc++. If you get errors that your compiler or linker can't create the shared library `libmysqlclient.so.#' you can work around this problem by giving the --disable-shared option to configure. In this case, configure will not build a shared libmysqlclient.so.# library.
• You can configure MySQL not to use DEFAULT column values for non-NULL columns (i.e., columns that are not allowed to be NULL). This causes INSERT statements to generate an error unless you explicitly specify values for all columns that require a non-NULL value. To suppress use of default values, run configure like this:

  shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure
  

• By default, MySQL uses the ISO-8859-1 (Latin1) character set. To change the default set, use the --with-charset option:

  shell> ./configure --with-charset=CHARSET
  

  CHARSET may be one of big5, czech, danish, dec8, dos, german1, hebrew, hp8, hungarian, koi8_ru, ru, latin1, latin2, sjis, swe7, tis620, ujis, usa7 or win1251. See section 9.1.1 The character set used for data and sorting. Note that if you want to change the character set, you must do a make distclean between configurations ! If you want to convert characters between the server and the client, you should take a look at the SET OPTION CHARACTER SET command. See section 7.24 SET OPTION syntax. Warning: If you change character sets after having created any tables, you will have to run isamchk -r -q on every table. Your indexes may be sorted incorrectly otherwise. (This can happen if you install MySQL, create some tables, the reconfigure MySQL using a different character set and reinstall it.)
• To configure MySQL with debugging code, use the --with-debug option:

  shell> ./configure --with-debug
  

  This causes a safe memory allocator to be included that can find some errors and that provides output about what is happening.
• Options that pertain to particular systems can be found in the system-specific sections later in this chapter. See section 4.11 System-specific notes.

4.8 Problems compiling?

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

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

• If configure is run after it already has been run, it may use information that was gathered during its previous invocation. This information is stored in `config.cache'; when configure starts up, it looks for that file and reads its contents if it exists, on the assumption that the information is still correct. That assumption is invalid when you reconfigure.
• Each time you run configure, you must run make again to recompile. However, you may want to remove old object files from previous builds first, since they were compiled using different configuration options.

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

shell> rm config.cache
shell> make clean

Alternatively, you can run make distclean.

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

• If you get errors when compiling `sql_yacc.cc' such as the ones shown below, you have probably run out of memory or swap space:

  Internal compiler error: program cc1plus got fatal signal 11
    or
  Out of virtual memory
    or
  Virtual memory exhausted
  

  The problem is that gcc requires huge amounts of memory to compile `sql_yacc.cc' with inline functions. Try running configure with the --with-low-memory option:

  shell> ./configure --with-low-memory
  

  This option causes -fno-inline to be added to the compile line if you are using gcc and -O0 if you are using something else. You should try the --with-low-memory option even if you have so much memory and swap space that you think you can't possibly have run out. This problem has been known to occur even on systems with generous hardware configurations, and the --with-low-memory option usually fixes it.
• By default, configure picks c++ as the compiler name and GNU c++ links with -lg++. If you are using gcc, this can cause problems during configuration such as this:

  configure: error: installation or configuration problem:
  C++ compiler cannot create executables.
  

  You might also observe problems during compilation related to g++, libg++ or libstdc++. One cause of these problems is that you may not have g++, or you may have g++ but not libg++ or libstdc++. The `config.log' contains the exact reason why your c++ compiler didn't work! To work around these problems, you can use gcc as your C++ compiler. Try setting the environment variable CXX to "gcc -O3". For example:

  shell> CXX="gcc -O3" ./configure
  

  This works because gcc compiles C++ sources as well as g++ does, but does not link in libg++ or libstdc++ by default. Another way to fix these problems, of course, is to install g++, libg++ and libstdc++.
• If your compile fails with either of the following errors, you have to upgrade your version of make to GNU make:

  making all in mit-pthreads
  make: Fatal error in reader: Makefile, line 18:
  Badly formed macro assignment
    or
  make: file `Makefile' line 18: Must be a separator (:
  

• If your make stops with this error, you should try using GNU make:

  Can't find Makefile.PL
  

  Solaris and FreeBSD are known to have troublesome make programs.
• If you get error messages from make or error messages like this, you have to upgrade your make to GNU make:

  pthread.h: No such file or directory
  

  GNU make version 3.75 is known to work.
• If you want to define flags to be used by your C or C++ compilers, do so by adding the flags to the CFLAGS and CXXFLAGS environment variables. You can also specify the compiler names this way using CC and CXX. For example:

  shell> CC=gcc
  shell> CFLAGS=-O6
  shell> CXX=gcc
  shell> CXXFLAGS=-O6
  shell> export CC CFLAGS CXX CXXFLAGS
  

  See section 4.12 TcX binaries, for a list of flag definitions that have been found to be useful on various systems.
• If you get an error message like this, you need to upgrade your gcc compiler:

  client/libmysql.c:273: parse error before `__attribute__'
  

  gcc 2.8.1 is known to work, but we recommend using egcs 1.0.3a or newer instead.
• If you get errors when compiling mysqld that look like this, configure didn't correctly detect the type of the last argument to accept(), getsockname() or getpeername():

  cxx: Error: mysqld.cc, line 645: In this statement, the referenced
       type of the pointer value "&length" is "unsigned long", which
       is not compatible with "int".
  new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
  

  To fix this, edit the `config.h' file (which is generated by configure). Look for these lines:

  /* Define as the base type of the last arg to accept */
  #define SOCKET_SIZE_TYPE XXX
  

  Change XXX to size_t or int, depending on your operating system. (Note that you will have to do this each time you run configure, since configure regenerates `config.h'.)
• The `sql_yacc.cc' file is generated from `sql_yacc.yy'. Normally you don't need to generate `sql_yacc.cc' yourself, since MySQL comes with an already-generated copy. However, if you do need to recreate it, you might encounter this error:

  "sql_yacc.yy", line xxx fatal: default action causes potential...
  

  This is a sign that your version of yacc is deficient. You probably need to install bison (the GNU version of yacc) and use that instead.
• If you need to debug mysqld or a MySQL client, run configure with the --with-debug option, then recompile and link your clients with the new client library. Before running a client, you should set the MYSQL_DEBUG environment variable:

  shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace
  shell> export MYSQL_DEBUG
  

  This causes clients to generate a trace file in `/tmp/client.trace'.
• If you have problems with your own client code, you should attempt to connect to the server and run your query using a client that is known to work. Do this by running mysql in debugging mode:

  shell> mysql --debug=d:t:O,/tmp/client.trace
  

  This will provide useful information in case you mail a bug report. See section 2.3 How to report bugs / problems.

4.9 MIT-pthreads notes

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

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

• On most systems, you can force MIT-pthreads to be used by running configure with the --with-mit-threads option:

  shell> ./configure --with-mit-threads
  

  Building in a non-source directory is not supported when using MIT-pthreads, because we want to minimize our changes to this code.
• MIT-pthreads doesn't support the AF_UNIX protocol used to implement Unix sockets. This means that if you compile using MIT-pthreads, all connections must be made using TCP/IP (which is a little slower). If you find after building MySQL that you cannot connect to the local server, it may be that your client is attempting to connect to localhost using a Unix socket as the default. Try making a TCP/IP connection by using mysql with a host option (-h or --host) to specify the local host name explicitly.
• The checks that determine whether or not to use MIT-pthreads occur only during the part of the configuration process that deals with the server code. If you have configured the distribution using --without-server to build only the client code, clients will not know whether or not MIT-pthreads is being used and will use Unix socket connections by default. Since Unix sockets do not work under MIT-pthreads, you will also need to use -h or --host in such instances.
• When MySQL is compiled using MIT-pthreads, system locking is disabled by default for performance reasons. You can tell the server to use system locking with the --use-locking option.
• Sometimes (at least on Solaris) the pthread bind() command fails to bind to a socket without any error message. The result is that all connections to the server fail. For example:

  shell> mysqladmin version
  mysqladmin: connect to server at " failed;
  error: 'Can't connect to mysql server on localhost (146)'
  

  The solution to this is to kill the mysqld server and restart it. This has only happened to us when we have forced the server down and done a restart immediately.
• With MIT-pthreads, the sleep() system call isn't interruptible with SIGINT (break). This is only noticeable when you run mysqladmin --sleep. You must wait for the sleep() call to terminate before the interrupt is served and the process stops.
• When linking (at least on Solaris) you will receive warning messages like these; they can be ignored:

  ld: warning: symbol `_iob' has differing sizes:
      (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
  file /usr/lib/libc.so value=0x140);
      /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
  ld: warning: symbol `__iob' has differing sizes:
      (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
  file /usr/lib/libc.so value=0x140);
      /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
  

• Some other warnings also can be ignored:

  implicit declaration of function `int strtoll(...)'
  implicit declaration of function `int strtoul(...)'
  

• We haven't gotten readline to work with MIT-pthreads. (This isn't needed, but may be interesting for someone.)

4.10 Perl installation comments

MySQL support for the Perl DBI/DBD interface is distributed separately from the main MySQL distribution, as of release 3.22.8. If you want to install Perl support, check http://www.mysql.com/Contrib for the files you will need.

The Perl client code for the DBD/DBI interface requires Perl 5.004 or later. The interface will not work if you have an older version of Perl.

The Perl distributions are provided as compressed tar archives and have names like `MODULE-VERSION.tar.gz', where MODULE is the module name and VERSION is the version number. You should get the Data-Dumper, DBI, and Msql-Mysql-modules archives. Once you have them, install them using the procedure shown below. The example shown below is for the Data-Dumper module, but the procedure is the same for all three modules.

1. Unpack the distribution into the current directory:

   shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -
   

   This command creates a directory named `Data-Dumper-VERSION'.
2. Change into the top-level directory of the unpacked distribution:

   shell> cd Data-Dumper-VERSION
   

3. Build the distribution and compile everything:

   shell> perl Makefile.PL
   shell> make
   shell> make test
   shell> make install
   

After you've installed the three modules, run make test in the Msql-Mysql-modules directory to exercise the interface code. (The server must be running for this to work.)

4.10.1 Problems using the Perl DBI/DBD interface

If perl reports that it can't find the ../mysql/mysql.so module, then the problem is probably that perl can't locate the shared library `libmysqlclient.so'.

You can fix this by any of the following methods:

• Compile the Msql-MySQL modules with: perl Makefile.PL -static instead of perl Makefile.PL
• Copy libmysqlclient.so to the library where your other shared libraries are (probably `/usr/lib' or `/lib').
• On Linux you can add the path to the directory, where you have libmysqlclient.so, to `/etc/ld.so.conf'.
• Add the path to libmysqlclient.so to the LD_RUN_PATH environment variable.

If you get the following errors from DBD-mysql, you are probably using gcc (or using an old binary compiled with gcc):

/usr/bin/perl: can't resolve symbol '__moddi3'
/usr/bin/perl: can't resolve symbol '__divdi3'

Add -L/usr/lib/gcc-lib/... -lgcc to the link command when the `mysql.so' library gets built (check the output from make for `mysql.so' when you compile the Perl client). The -L option should specify the path to the directory where `libgcc.a' is located on your system.

Another cause of this problem may be that Perl and MySQL aren't both compiled with gcc. In this case, you can solve the mismatch by compiling both with gcc.

If you want to use the Perl module on a system that doesn't support dynamic linking (like SCO) you can generate a static version of Perl that includes DBI and DBD-mysql. The way this works is that you generate a version of Perl with the DBI code linked in and install it on top of your current Perl. Then you use that to build a version of Perl that additionally has the DBD code linked in, and install that.

On SCO, you must have the following environment variables set:

shell> LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
or
shell> LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib
shell> LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib
shell> MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:/usr/skunk/man:

First, you create a Perl that includes a statically-linked DBI by running these commands in the `perl/DBI' directory:

shell> perl Makefile.PL LINKTYPE=static
shell> make
shell> make install
shell> make perl

After this you must install the new Perl. The output of make perl will indicate the exact make command you will need to execute to perform the installation. On SCO, this is make -f Makefile.aperl inst_perl MAP_TARGET=perl.

Next you create Perl that includes a statically-linked DBD::mysql by running these commands in the `perl/Mysql-modules' directory:

shell> perl Makefile.PL LINKTYPE=static
shell> make
shell> make install
shell> make perl

You should also install this new Perl. Again, the output of make perl indicates the command to use.

4.11 System-specific notes

The following sections indicate some of the issues that have been observed to occur on particular systems.

4.11.1 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://www.mysql.com/Downloads/.

Sun native threads work only on Solaris 2.5 and higher. For 2.4 and earlier versions, MySQL will automaticly use MIT-pthreads. See section 4.9 MIT-pthreads notes.

If you have the Sun Workshop 4.2 compiler, you can run configure like this:

shell> CC=cc CFLAGS="-Xa -fast -xstrconst -mt" \
       CXX=CC CXXFLAGS="-xsb -noex -fast -mt" \
       ./configure

You may also have to edit the configure script to 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 error message shown below when you run it, you have tried to compile MySQL with the Sun compiler without enabling the multi-thread option -mt:

libc internal error: _rmutex_unlock: rmutex not held

Add -mt to CFLAGS and CXXFLAGS and try again.

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 egcs or 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)!

Note that gcc 2.8.1 has a couple on bugs on Sparc platforms! On Sparc, we recommend you use egcs 1.0.3a. If you are using egcs 1.1 or egcs 1.1.1 you MUST compile MySQL with -O1 as higher optimization levels produces wrong code.

The recommended configure line when using egcs 1.1 or egcs 1.1.1 is:

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

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

ld: fatal: library -ldl: not found

Solaris 2.7 has some bugs in the include files. If you get the following error when you use gcc:

/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of the previous
definition

You can do the following to avoid this:

copy /usr/include/widec.h to .../lib/gcc-lib/os/gcc-version/include and change row 41 from:

#if     !defined(lint) && !defined(__lint)

to

#if     !defined(lint) && !defined(__lint) && !defined(getwc)

You can of course edit `/usr/include/widec.h' directly. After this you should remove `config.cache' and run configure again!

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 --set-variable back_log=50 option as a workaround for this.

If you are linking your own MySQL client and get the error:

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

when executing them, the problem can be avoided by one of the following methods:

•

Link the client with the following flag (instead of -Lpath): -Wl,r/path-libmysqlclient.so

•

Copy libmysqclient.so to `/usr/lib'

•

Set the LD_RUN_PATH environment to the path to `libmysqlclient.so' before running your client.

4.11.2 Solarix x86 notes

If you are using gcc or egcs on Solaris x86 and you experience problems with core dumps under load, you should use the following configure command:

shell> CC=gcc CFLAGS="-O6 -fomit-frame-pointer" \
       CXX=gcc \
       CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" \
       ./configure --prefix=/usr/local/mysql

This will avoid problems with the libstdc++ library and with C++ exceptions.

If this doesn't help, you should compile a debug version and run this with a trace file or under gdb. See section 19.10 Debugging MySQL.

4.11.3 SunOS 4 notes

On SunOS 4, MIT-pthreads is needed. This in turn means you will need GNU make to compile MySQL.

Some SunOS 4 systems have problems with dynamic libraries and libtool. You can use the following configure line to avoid this problem.

./configure --disable-shared --with-mysqld-ldflags=-all-static

When compiling readline, you may get warnings about duplicate defines. These may be ignored.

When compiling mysqld, there will be some implicit declaration of function warnings. These may be ignored.

4.11.4 Linux notes (all Linux versions)

If you can't start mysqld or if mysql_install_db doesn't work, please continue reading! This only happens on Linux system with problems in the LinuxThreads or libc/glibc libraries. There are a lot of simple workarounds to get MySQL to work! The simplest is to use the binary version of MySQL (not the RPM) for Linux x86; One nice aspect of this version is that it's probably 10% faster than any version you would compile yourself! See section 10.3 How compiling and linking affects the speed of MySQL.

isamchk hangs with libc.so.5.3.12. Upgrading to the newest libc fixes this problem.

When using LinuxThreads you will see a minimum of three 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.

If you are using LinuxThreads and mysqladmin shutdown doesn't work, you have to upgrade to LinuxThreads 0.7.1 or newer.

If you are using RedHat, you might get errors like this:

/usr/bin/perl is needed...
/usr/sh is needed...
/usr/sh is needed...

If so, you should upgrade your version of rpm to `rpm-2.4.11-1.i386.rpm' and `rpm-devel-2.4.11-1.i386.rpm' (or later).

You can get the upgrades of libraries to RedHat 4.2 from ftp://ftp.redhat.com/updates/4.2/i386. Or http://www.sunsite.unc.edu/pub/Linux/distributions/redhat/code/rpm/ for other distributions.

If you are linking an own MySQL client and get the error:

ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory

when executing them, the problem can be avoided by one of the following methods:

•

Link the client with the following flag (instead of -Lpath): -Wl,r/path-libmysqlclient.so

•

Copy libmysqclient.so to `/usr/lib'

•

Set the LD_RUN_PATH environment to the path to `libmysqlclient.so' before running your client.

4.11.4.1 Linux-x86 notes

LinuxThreads should be installed before configuring MySQL!

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 RedHat so if you have problems, check whether or not there are any updates! The glibc 2.0.7-19 RPM is known to work.

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 and add an extra underscore to the _P macro that has only one underscore, then try again.

You may get some warnings when compiling; those shown below 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'

In Debian GNU/Linux, if you want MySQL to start automatically when the system boots, do the following:

shell> cp mysql.server /etc/init.d/mysql.server
shell> /usr/sbin/update-rc.d mysql.server defaults 99

mysql.server can be found in the `share/mysql' directory under the MySQL installation directory, or in the `support-files' directory of the MySQL source tree.

If mysqld always core dumps when it starts up, 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. RedHat 5.0 has also a similar problem with some new glibc versions. See section 4.11.4.2 RedHat 5.0 notes.

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

4.11.4.2 RedHat 5.0 notes

If you have any problems with MySQL on RedHat, you should start by upgrading glibc to the newest possible version!

If you install all the official RedHat patches (including glibc-2.0.7-19 and glibc-devel-2.0.7-19), both the binary and source distributions of MySQL should work without any trouble!

The updates are needed since there is a bug in glibc 2.0.5 in how pthread_key_create variables are freed. With glibc 2.0.5, you must use a statically-linked MySQL binary distribution. If you want to compile from source, you must install the corrected version of LinuxThreads from http://www.mysql.com/Downloads/Linux or upgrade your glibc.

If you have an incorrect version of glibc or LinuxThreads, the symptom is that mysqld crashes after each connection. For example, mysqladmin version will crash mysqld when it finishes!

Another symptom of incorrect libraries is that mysqld crashes at once when it starts. On some Linux systems, this can be fixed by configuring like this:

shell> ./configure --with-mysqld-ldflags=-all-static

On Redhat 5.0, the easy way out is to install the glibc 2.0.7-19 RPM and run configure without the --with-mysqld-ldflags=-all-static option.

For the source distribution of glibc 2.0.7, a patch that is easy to apply and is tested with MySQL may be found at http://www.mysql.com/Download/Linux/glibc-2.0.7-total-patch.tar.gz.

If you experience crashes like these when you build MySQL, you can always download the newest binary version of MySQL. This is statically-linked to avoid library conflicts and should work on all Linux systems!

MySQL comes with an internal debugger that can generate trace files with a lot of information that can be used to find and solve a wide range of different problems. See section 19.10 Debugging MySQL.

4.11.4.3 RedHat 5.1 notes

The glibc of RedHat 5.1 (glibc 2.0.7-13) has a memory leak, so to get a stable MySQL version, you must upgrade glibc to 2.0.7-19, downgrade glibc or use a binary version of mysqld. If you don't do this, you will encounter memory problems (out of memory, etc., etc.). The most common error in this case is:

Can't create a new thread (errno 11). If you are not out of available
memory, you can consult the manual for any possible OS dependent bug

After you have upgraded to glibc 2.0.7-19, you can configure MySQL with dynamic linking (the default), but you cannot run configure with the --with-mysqld-ldflags=-all-static option until you have installed glibc 2.0.7-19 from source!

You can check which version of glibc you have with rpm -q glibc.

4.11.4.4 Linux-Sparc notes

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

Some problems will require patching your Linux installation. The patch can be found at http://www.mysql.com/patches/Linux-sparc-2.0.30.diff. This patch is against the Linux distribution `sparclinux-2.0.30.tar.gz' that is available at vger.rutgers.edu (a version of Linux that was never merged with the official 2.0.30). You must also install LinuxThreads 0.6 or newer.

Thanks to jacques@solucorp.qc.ca for this information.

4.11.4.5 Linux-Alpha notes

The first problem is LinuxThreads. The RedHat distribution uses an old (broken) LinuxThreads version, so you must patch LinuxThreads for Alpha. Use the following procedure:

1. Obtain the glibc2.5c source from any GNU FTP site.
2. Get the file ftp://www.mysql.com/pub/mysql/linux/patched-glibc-linuxthreads-0.6.tar.gz. This includes a fixed .c file. Copy this to the glibc `./linuxthreads' directory.
3. Configure and compile glibc (You have to read the manual how to do this together with LinuxThreads), but don't install it!
4. In the `/usr/lib' directory, rename your old version of `libpthread.a' to `libpthread.a-old'.
5. Copy the file `glibc.../linuxthreads/libpthread.a' to `/usr/lib'.
6. Configure MySQL with the following command:

   shell> CC=gcc CCFLAGS="-Dalpha_linux_port" \
          CXX=gcc CXXFLAGS="-O3 -Dalpha_linux_port" \
          ./configure --prefix=/usr/local/mysql
   

7. Try to compile mysys/thr_lock and mysys/thr_alarm. Test that these programs work! (Invoke each one with no arguments. Each should end with test_succeeded if everything was okay.)
8. Recompile mysqld.

Note that Linux-Alpha is still an alpha-quality platform for MySQL. With RedHat 5.0 and the patched LinuxThreads, you have a very good chance of it working.

If you have problems with signals (MySQL dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with:

shell> CFLAGS=-DDONT_USE_THR_ALARM CXXFLAGS=-DDONT_USE_THR_ALARM ./configure ...

This doesn't affect the performance of MySQL, but has the side effect that you can't kill clients that are "sleeping" on a connection with mysqladmin kill or mysqladmin shutdown. The client will instead die when it issues its next command.

4.11.4.6 MkLinux notes

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

4.11.5 Linux RPM notes

The recommended way to install MySQL on linux is by a RPM. The MySQL RPMS is currently being build on a RedHat 5.1 system but should work on other versions of Linux that supports RPM as well.

• MySQL-VERSION.i386.rpm The MySQL server. Unless you only want to connect to another MySQL server running on another machice yo will need this.
• MySQL-client-VERSION.i386.rpm The standard MySQL client programs. You probably always want to install this package.
• MySQL-bench-VERSION.i386.rpm Test and benchmarks. Requires perl and msql-mysql-modules RPMS.
• MySQL-devel-VERSION.i386.rpm Libraries and include files nesesarry if you want to compile other MySQL clients.
• MySQL-VERSION.src.rpm This contains the source code to all of the above packages. It can also be used to try to build RPMS for other architectures (for example, Alpha or SPARC).

• To make a standard minimal installation:

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

• To install only the client package:

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

The RPM places data in `/var/lib/mysql'. The RPM also creates the appropriate entries in `/sbin/rc.d/' to start the server automatically at boot time.

4.11.6 Alpha-DEC-Unix notes

When compiling threaded programs under Digital UNIX, the documentation recommends the -pthread option for cc and cxx and the libraries -lmach -lexc (in addition to -lpthread). You should run configure something like this:

shell> CC="cc -pthread" CXX="cxx -pthread -O" \
       ./configure -with-named-thread-libs="-lpthread -lmach -lexc -lc"

When compiling mysqld, you may see a couple of warnings like this:

mysqld.cc: In function void handle_connections()':
mysqld.cc:626: passing long unsigned int *' as argument 3 of
accept(int,sockadddr *, int *)'

You can safely ignore these warnings. They occur because configure can't detect warnings, only errors.

If you start the server directly from the command line, you may have problems with it dying when you log out. (When you log out, your outstanding processes receive a SIGHUP signal.) If so, try starting the server like this:

shell> nohup mysqld [options] &

nohup causes the command following it to ignore any SIGHUP signal sent from the terminal. Alternatively, start the server by running safe_mysqld, which invokes mysqld using nohup for you.

4.11.7 Alpha-DEC-OSF1 notes

If you have problems compiling and have DEC CC and gcc installed, try running configure like this:

shell> CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \
       ./configure --prefix=/usr/local/mysql

If you get problems with the `c_asm.h' file, you can create and use a 'dummy' `c_asm.h' file with:

shell> touch include/c_asm.h
shell> CC=gcc CFLAGS=-I./include CXX=gcc CXXFLAGS="-O3 ./configure --prefix=/usr/local/mysql

On OSF1 V4.0D and compiler "DEC C V5.6-071 on Digital UNIX V4.0 (Rev. 878)" the compiler had some strange behavior (undefined asm symbols). /bin/ld also appears to be broken (problems with _exit undefined when linking mysqld). On this system, we have managed to compile MySQL with the following configure line, after replacing /bin/ld with the version from OSF 4.0C:

shell> CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

In some versions of OSF1, the alloca() function is broken. Fix this by removing the line in `config.h' that defines 'HAVE_ALLOCA'.

The alloca() function also may have an incorrect prototype in /usr/include/alloca.h. This warning resulting from this can be ignored.

configure will use the following thread libraries automatically: -with-named-thread-libs="-lpthread -lmach -lexc -lc".

When using gcc, you can also try running configure like this:

shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ....

If you have problems with signals (MySQL dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with:

shell> CFLAGS=-DDONT_USE_THR_ALARM CXXFLAGS=-DDONT_USE_THR_ALARM ./configure ...

This doesn't affect the performance of MySQL, but has the side effect that you can't kill clients that are "sleeping" on a connection with mysqladmin kill or mysqladmin shutdown. The client will instead die when it issues its next command.

4.11.8 SGI-IRIX notes

You may have to undefine some things in `config.h' after running configure and before compiling.

In some Irix implementations, the alloca() function is broken. If the mysqld server dies on some SELECT statements, remove the lines from `config.h' that define HAVE_ALLOC and HAVE_ALLOCA_H. If mysqladmin create doesn't work, remove the line from `config.h' that defines HAVE_READDIR_R. You may have to remove the HAVE_TERM_H line as well.

Irix 6.2 doesn't support POSIX threads out of of the box. You must install these patches, which are available from SGI if you have support: 1403, 1404, 1644, 1717, 1918, 2000, 2044.

If you get the something like the following error when compiling `mysql.cc':

"/usr/include/curses.h", line 82: error(1084): invalid combination of type

Then type the following in the top-level directory of your MySQL source tree:

shell> extra/replace bool curses_bool < /usr/include/curses.h > include/curses.h
shell> make

There have also been reports of scheduling problems. If only one thread is running, things go slow. Avoid this by starting another client. This may lead to a 2-to-10-fold increase in execution speed thereafter for the other thread.

This is a poorly-understood problem with IRIS threads; you may have to improvise to find solutions until this can be fixed.

If you are compiling with gcc, you can use the following configure command:

shell> CC=gcc CXX=gcc CXXFLAGS=-O3 \
       ./configure --prefix=/usr/local/mysql --with-thread-safe-client

4.11.9 FreeBSD notes

If you notice that configure will use MIT-pthreads, you should read the MIT-pthreads notes. See section 4.9 MIT-pthreads notes.

If you get an error on make install that it can't find `/usr/include/pthreads', configure didn't detect that you need MIT-pthreads on FreeBSD. This is fixed by doing:

shell> rm config.cache
shell> ./configure --with-mit-threads

The FreeBSD make behavior is slightly different from that of GNU make. If you have make-related problems, you should install GNU make.

If mysql or mysqladmin takes a long time to respond, a user said the following:

Are you running the ppp user process? On one FreeBSD box (2.2.5) MySQL clients takes a couple of seconds to connect to mysqld if the ppp process is running.

FreeBSD is also known to have a very low default file handle limit. See section 16.9 File not found.

If you have a problem with SELECT NOW() returning values in GMT and not your local time, you have to set the TZ environment variable to your current timezone. This should be done for the environment in which the server runs, for example, in safe_mysqld or mysql.server.

Make sure that you modify the `/etc/hosts' file so that the localhost entry is correct (otherwise you will have problems connecting to the database. The `/etc/hosts' file should start with a line:

127.0.0.1       localhost localhost.your.domain

If you are using FreeBSD 2.2.6, don't forget to apply the ttcp and mmap-22 patches to the OS (for security reasons). Please see http://www.freebsd.org for these CERT patches.

If you are using FreeBSD 2.2.7 and you have problems killing the mysqld daemon, you should cvsup new sources and recompile libc_r.

4.11.9.1 FreeBSD-3.0 notes

You have to run configure with the --with-named-thread-libs=-lc_r option.

The pthreads library for FreeBSD doesn't contain the sigwait() function and there are some bugs in it. To fix this, get the `FreeBSD-3.0-libc_r-1.0.diff' file and apply this in the `/usr/src/lib/libc_r/uthread' directory. Then follow the instructions that can be found with man pthread about how to recompile the libc_r library.

You can test if you have a "modern" libpthread.a with this command:

shell> nm /usr/lib/libc_r.a | grep sigwait

If the above doesn't find sigwait, you must use the patch above and recompile libc_r.

4.11.10 BSD/OS 2.# notes

If you get the following error when compiling MySQL, your ulimit for virtual memory is too low:

item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)':
item_func.h:28: virtual memory exhausted
make[2]: *** [item_func.o] Error 1

Try using ulimit -v 80000 and run make again. If this doesn't work and you are using bash, try switching to csh or sh; Some BSDI users have reported problems with bash and ulimit.

If you are using gcc, you may also use have to use the --with-low-memory flag to configure to be able to compile `sql_yacc.cc'.

If you have a problem with SELECT NOW() returning values in GMT and not your local time, you have to set the TZ environment variable to your current timezone. This should be done for the environment in which the server runs, for example in safe_mysqld or mysql.server.

4.11.10.1 BSD/OS 3.# notes

1. Upgrade to BSD/OS 3.1. If that is not possible, install BSDIpatch M300-038.
2. Use the following command when configuring MySQL:

   shell> env CXX=shlicc++ CC=shlicc2 \
          ./configure \
              --prefix=/usr/local/mysql \
              --localstatedir=/var/mysql \
              --without-perl \
              --with-unix-socket-path=/var/mysql/mysql.sock
   

   The following is also known to work:

   shell> env CC=gcc CXX=gcc CXXFLAGS=-O3 \
          ./configure \
              --prefix=/usr/local/mysql \
              --with-unix-socket-path=/var/mysql/mysql.sock
   

   You can change the directory locations if you wish, or just use the defaults by not specifying any locations.
3. If you have problems with performance under heavy load, try using the --skip-thread-priority option to safe_mysqld! This will run all threads with the same priority; on BSDI 3.1, this gives better performance. (At least until BSDI fixes their thread scheduler).

If you get the error virtual memory exhausted while compiling, you should try using ulimit -v 80000 and run make again. If this doesn't work and you are using bash, try switching to csh or sh; Some BSDI users have reported problems with bash and ulimit.

4.11.11 SCO notes

The current port is tested only on a "sco3.2v5.0.4" system. There has also been a lot of progress on a port to "sco 3.2v4.2".

1. For OpenServer 5.0.X You need to use GDS in Skunkware 95 (95q4c). This is necessary because GNU gcc 2.7.2 in Skunkware 97 does not have GNU as.
2. You need the port of GCC 2.5.? for this product and the Development system. They are required on this version of SCO UNIX. You cannot just use the GCC Dev system.
3. You should get FSU thread package and install this first. This can be found at http://www.cs.wustl.edu/~schmidt/ACE_wrappers/FSU-threads.tar.gz. You can also get a precompiled package from ftp://www.mysql.com/pub/mysql/Downloads/SCO/FSU-threads-3.5c.tar.gz.
4. FSU pthreads can be compiled with SCO UNIX 4.2 with tcpip. Or OpenServer 3.0 or Open Desktop 3.0 (OS 3.0 ODT 3.0), with the SCO Development System installed using a good port of GCC 2.5.X ODT or OS 3.0 you will need a good port of GCC 2.5.? There are a lot of problems without a good port. The port for this product requires the SCO UNIX Development system. Without it, you are missing the libraries and the linker that is needed.
5. To build FSU pthreads in your system, do the following:
   1. Run ./configure in the `threads/src' directory and select the SCO OpenServer option. This command copies `Makefile.SCO5' to `Makefile'.
   2. Run make.
   3. To install in the default `/usr/include' directory, login as root and cd to `thread/src' directory, and run make install.
6. Remember to use GNU make when making MySQL.
7. If you don't start safe_mysqld as root, you will probably only get the default 110 open files per process. mysqld will write a note about this in the log file.
8. With SCO 3.2V4.2, you must use a FSU-pthreads version 3.5c or newer. The following configure command should work:

   shell> CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \
          ./configure \
              --with-debug --prefix=/usr/local/mysql \
              --with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads" \
              --with-named-curses-libs="-lcurses" \
              --without-perl
   

   You may get some problems with some include files. In this case you can find new SCO-specific include files at ftp://www.mysql.com/pub/mysql/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz. You should unpack this file in the `include' directory of your MySQL source tree.

SCO development notes:

• MySQL should automatically detect FSU-threads and link mysqld with -lgthreads -lsocket -lgthreads.
• The SCO development libraries are reentrant in FSU pthreads. SCO claims that its libraries function are reentrant so they must be reentrant with FSU pthreads. FSU pthreads on OpenServer tries to use the SCO scheme to make reentrant library.
• FSU threads (at least the version at www.mysql.com) comes linked with GNU malloc. If you encounter problems with memory usage, make sure that `gmalloc.o' is included in `libgthreads.a' and `libgthreads.so'.
• In FSU pthreads, the following system calls are pthreads aware: read(), write(), getmsg(), connect(), accept(), select() and wait().

4.11.12 SCO Unixware 7.0 notes

MySQL 3.22.13 fixes some portability problems under Unixware so you must use at least this version.

We have been able to compile MySQL with the following configure line on UnixWare 7.0.1:

CC=cc CXX=CC ./configure --prefix=/usr/local/mysql

4.11.13 IBM-AIX notes

Automatic detection of xlC is missing from Autoconf, so something like this is needed when using the IBM compiler:

shell> CC="xlc_r -ma -O3 -qstrict" CXX="xlC_r -ma -O3 -qstrict" \
       ./configure

If you are using egcs to compile MySQL, you MUST use the -fno-exceptions flag, as the exception handling in egcs is not thread-safe! (This is tested with egcs 1.1). We recommend the following configure line with egcs and gcc on AIX:

shell> CXX=gcc CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \
       ./configure --prefix=/home/monty --with-debug --with-low-memory

If you have problems with signals (MySQL dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with:

shell> CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \
       CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -DDONT_USE_THR_ALARM" \
       ./configure --prefix=/home/monty --with-debug --with-low-memory

This doesn't affect the performance of MySQL, but has the side effect that you can't kill clients that are "sleeping" on a connection with mysqladmin kill or mysqladmin shutdown. The client will instead die when it issues its next command.

4.11.14 HP-UX notes

There are a couple of "small" problems when compiling MySQL on HP-UX. We recommend that you use gcc instead of the HP-UX native compiler as gcc produces better code!

gcc 2.8.0 can't compile readline on HP-UX (an internal compiler error occurs) if you are compiling with -O6. On the other hand, MIT-pthreads can't be compiled with the HP-UX compiler, because it can't compile .S (assembler) files. We got MySQL to compile on HP-UX 10.20 by doing the following:

shell> CC=gcc CXX=gcc ./configure --prefix=/usr/local/mysql --with-low-memory
shell> cd readline
shell> edit Makefile and change -O6 to something lower
shell> cd ..
shell> make
shell> make install
shell> scripts/mysql_install_db
shell> /usr/local/mysql/bin/safe_mysqld &

4.12 TcX binaries

As a service, TcX provides a set of binary distributions of MySQL that are compiled at TcX or at sites where customers kindly have given us access to their machines.

These distributions are generated with scripts/make_binary_distribution and are configured with the following compilers and options.

SunOS 4.1.4 2 sun4c with gcc 2.7.2.1

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --disable-shared

SunOS 5.5.1 sun4u with egcs 1.0.3a

CC=gcc CFLAGS="-O6 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-low-memory

SunOS 5.6 sun4u with egcs 2.90.27

CC=gcc CFLAGS="-O6 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-low-memory

SunOS 5.6 i86pc with gcc 2.8.1

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory

Linux 2.0.33 i386 with pgcc 2.90.29 (egcs 1.0.3a)

CFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static

SCO 3.2v5.0.4 i386 with gcc 2.7-95q4

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

AIX 2 4 with gcc 2.7.2.2

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

OSF1 V4.0 564 alpha with gcc 2.8.1

CC=gcc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory

IRIX 6.3 IP32 with gcc 2.8.0

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

BSDI BSD/OS 3.1 i386 with gcc 2.7.2.1

CC=gcc CXX=gcc CXXFLAGS=-O ./configure --prefix=/usr/local/mysql

BSDI BSD/OS 2.1 i386 with gcc 2.7.2

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

Anyone who has more optimal options for any of the configurations listed above can always mail them to us at mysql-developer@tcx.se.

RPM distributions prior to MySQL 3.22 are user-contributed. Beginning with 3.22, some RPMs are TcX-generated.

4.13 Win32 notes

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

Table cache size limitations

Win32 can handle only a very limited number of open files at the same time (about 255). Because of this, you shouldn't increase the number of open connections or number of cached tables very much on Win32.

Win95 and threads

Win95 leaks about 200 bytes of main memory for each thread creation. Because of this, you shouldn't run mysqld for an extended time on Win95 if you do many connections, since each connection in MySQL creates a new thread! NT doesn't suffer from this bug.

Blocking read

MySQL uses a blocking read for each connection. This means that:

• A connection will not be disconnected automatically after 8 hours, as happens with the Unix version of MySQL.
• If a connection "hangs," it's impossible to break it without killing MySQL.
• mysqladmin kill will not work on a sleeping connection.
• mysqladmin shutdown can't abort as long as there are sleeping connections.

We plan to fix this in the near future.

UDF functions

For the moment, MySQL-Win32 does not support user definable functions.

DROP DATABASE

You can't drop a database that is in use by some thread.

Killing MySQL from the task manager

You can't kill MySQL from the task manager or with the shutdown utility in Windows95. You must take it down with mysqladmin shutdown.

Case-insensitive names

Filenames are case insensitive on Win32, so database and table names are also case insensitive in MySQL for Win32. The only restriction is that database and table names must be given in the same case throughout a given statement. The following query would not work because it refers to a table both as my_table and as MY_TABLE:

SELECT * FROM my_table WHERE MY_TABLE.col=1;

The `\' directory character

Pathname components in Win95 are separated by `\', which is also the escape character in MySQL. If you are using LOAD DATA INFILE or SELECT ... INTO OUTFILE, you must double the `\' character or use Unix style filenames with `/':

SELECT * FROM skr INTO OUTFILE 'C:/tmp/skr.txt';
LOAD DATA INFILE "C:\\tmp\\skr.txt" INTO TABLE skr;

Can't open named pipe error

If you use the shareware version of MySQL-Win32 on NT with the newests mysql-clients you will get the following error: error 2017: can't open named pipe to host: . pipe... This is 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 a file, `C:\my.cnf', that contains the following information:

[client]
host = localhost

If you get the error Access denied for user: 'some-user@unknown' to database 'mysql' when accessing a MySQL server on the same machine, this means that your MySQL can't resolve your host name properly. To fix this you should create a file `\windows\hosts' with the following information:

127.0.0.1       localhost

Here are some open issues for anyone who might want to help us with the Win32 release:

• When you suspend a laptop running Win95, the mysqld daemon doesn't accept new connections when the laptop is resumed. We don't know if this is a problem with Win95, TCP/IP or MySQL.
• It would also be real nice to be able to kill mysqld from the task manager. For the moment, you must use mysqladmin shutdown.
• When registering mysqld as a service with -install (on NT) it would be nice if you could also add default options on the command line. For the moment, the workaround is to update the `C:\my.cnf' file instead.
• Port readline to Win32 for use in the mysql command line tool.
• GUI versions of the standard MySQL clients (mysql, mysqlshow, mysqladmin, and mysqldump) would be nice.
• It would be nice if the "read" and "write" to sockets in `net.c' were interruptible. This would make it possible to kill open threads with mysqladmin kill on Win32.
• Documentation of which Windows programs work with MySQL-Win32/MyODBC and what must be done to get them working.
• mysqld always starts in the "C" locale and not in the default locale. We would like to have mysqld use the current locale for the sort order.
• Add more options to MysqlManager
• Change the communication protocol between the server and client to use Windows internal communication instead of sockets and TCP/IP.
• Implement UDF functions with .DLLs

Other Win32-specific issues are described in the `README' file that comes with the MySQL-Win32 distribution.

4.14 Post-installation setup and testing

Once you've installed MySQL (from either a binary or source distribution), 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 up and shuts down.

Normally you install the grant tables and start the server like this:

shell> ./scripts/mysql_install_db
shell> cd mysql_installation_directory
shell> ./bin/safe_mysqld &

This is described in detail below:

Testing is most easily done from the top-level directory of the MySQL distribution. For a binary distribution, this is your installation directory (typically something like `/usr/local/mysql'). For a source distribution, this is the main directory of your MySQL source tree.

In the commands shown below in this section and in the following subsections, BINDIR is the path to the location in which programs like mysqladmin and safe_mysqld are installed. For a binary distribution, this is the `bin' directory within the distribution. For a source distribution, BINDIR is probably `/usr/local/bin', unless you specified an installation directory other than `/usr/local' when you ran configure. EXECDIR is the location in which the mysqld server is installed. For a binary distribution, this is the same as BINDIR. For a source distribution, EXECDIR is probably `/usr/local/libexec'.

1. If necessary, start the mysqld server and set up the initial MySQL grant tables containing the privileges that determine how users are allowed to connect to the server. This is normally done with the mysql_install_db script. Normally, mysql_install_db needs to be run only the first time you install MySQL. Therefore, if you are upgrading an existing installation, you can skip this step. mysql_install_db is quite safe to use and will not update any tables that already exist, so if you are unsure what to do, you can always run mysql_install_db.

   shell> scripts/mysql_install_db
   

   If you don't set up the grant tables, the following error will appear in the log file when you start the server:

   mysqld: Can't find file: 'host.frm'
   

   You might need to run mysql_install_db as root. However, if you prefer, you can run the MySQL server as an unprivileged (non-root) user, provided that user can read and write files in the database directory. Instructions for running MySQL as an unprivileged user are given in section 16.7 How to run MySQL as a normal user. mysql_install_db creates four tables (user, db, host and func) in the mysql database. A description of the initial privileges is given in section 6.8 Setting up the initial MySQL privileges. Briefly, the 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_'. If you have problems with mysql_install_db, see section 4.14.1 Problems running mysql_install_db. There are some alternatives to running the mysql_install_db script as is:
   • You may want to edit mysql_install_db before running it, to change the initial privileges that are installed into the grant tables.
   • If you want to change things in the grant tables after installing them, you can run mysql_install_db, then use mysql -u root mysql to connect to the grant tables as the MySQL root user and issue SQL statements to modify the grant tables directly.
   • It is possible to recreate the grant tables completely after they have already been created. You might want to do this if you've already installed the tables but then want to recreate them after editing mysql_install_db.
   For more information about these alternatives, see section 6.8 Setting up the initial MySQL privileges.
2. Start the MySQL server like this:

   shell> cd mysql_installation_directory
   shell> bin/safe_mysqld &
   

   See section 4.14.2 Problems starting the MySQL server
3. Verify that the server is running using mysqladmin. The following commands provide a simple test to check that the server is up and responding to connections:

   shell> BINDIR/mysqladmin version
   shell> BINDIR/mysqladmin variables
   

   For example, the output from mysqladmin version varies slightly depending on your platform and version of MySQL, but should be similar to that shown below:

   shell> BINDIR/mysqladmin version
   mysqladmin  Ver 6.3 Distrib 3.22.9-beta, for pc-linux-gnu on i686
   TCX Datakonsult AB, by Monty
   
   Server version          3.22.9-beta
   Protocol version        10
   Connection              Localhost via UNIX socket
   TCP port                3306
   UNIX socket             /tmp/mysql.sock
   Uptime:                 16 sec
   
   Running threads: 1  Questions: 20  Reloads: 2  Open tables: 3
   

   To get a feeling for what else you can do with BINDIR/mysqladmin, invoke it with the --help option.
4. Verify that you can shut down the server:

   shell> BINDIR/mysqladmin -u root shutdown
   

5. Verify that you can restart the server. Do this using safe_mysqld or by invoking mysqld directly. For example:

   shell> BINDIR/safe_mysqld --log &
   

   If safe_mysqld fails, try running it from the MySQL installation directory (if you are not already there). If that doesn't work, see section 4.14.2 Problems starting the MySQL server.
6. Run some simple tests to verify that the server is working. The output should be similar to what is shown below:

   shell> BINDIR/mysqlshow
   +-----------+
   | Databases |
   +-----------+
   | mysql     |
   +-----------+
   
   shell> BINDIR/mysqlshow mysql
   Database: mysql
   +--------+
   | Tables |
   +--------+
   | db     |
   | host   |
   | user   |
   +--------+
   
   shell> BINDIR/mysql -e "select host,db,user from db" mysql
   +------+--------+------+
   | host | db     | user |
   +------+--------+------+
   | %    | test   |      |
   | %    | test_% |      |
   +------+--------+------+
   

   There is also a benchmark suite in `sql-bench' that you can use to compare how MySQL performs on different platforms. In the `sql-bench/Results' directory you can find the results from many runs against different databases and platforms. To run all tests, execute these commands:

   shell> cd sql-bench
   shell> run-all-tests
   

   If you don't have the `sql-bench' directory, you are probably using a RPM for a binary distribution. (Source distribution RPMs include the benchmark directory.) In this case, you must first install the benchmark suite before you can use it. Beginning with MySQL 3.22, there are benchmark RPM files named `mysql-bench-VERSION-i386.rpm' that contain benchmark code and data. You can also run the tests in the `tests' subdirectory. For example, to run `auto_increment.tst', do this:

   shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tst
   

   The expected results are shown in the file `./tests/auto_increment.res'.

4.14.1 Problems running mysql_install_db

This section lists some of the 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 doesn't install the grant tables, but terminates after displaying the following messages:

starting mysqld daemon with databases from XXXXXX
mysql daemon ended

In this case, you should examine the 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 using mysqlbug! See section 2.3 How to report bugs / problems.

There is already a mysqld daemon running

In this case, you have probably don't have to run mysql_install_db at all. You have to run mysql_install_db only once, when you install MySQL the first time.

Installing a second mysqld daemon doesn't work when one daemon is running

This can happen when you already have an existing MySQL installation, but want to put a new installation in a different place (e.g., for testing, or perhaps you simply want to run two installations at once). Generally the problem that occurs when you try to run the second server is that it tries to use the same socket and port as the old one. In this case you will get the error message: Can't start server: Bind on TCP/IP port: Address already in use or Can't start server : Bind on unix socket... You can start the new server with a different socket and port as follows:

shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> scripts/mysql_install_db
shell> bin/safe_mysqld &

After this, you should edit your server boot script to start both daemons with different sockets and ports. For example, it could invoke safe_mysqld twice, but with different --socket, --port and --basedir options for each invocation.

You don't have write access to `/tmp'

If you don't have write access to create a socket file at the default place (in `/tmp') or permission to create temporary files in /tmp, you will get an error when running mysql_install_db or when starting/using mysqld. You can specify a different socket and temporary directory as follows:

shell> MYSQL_UNIX_PORT=/some_tmp_dir/mysqld.sock
shell> TMPDIR=/some_tmp_dir/
shell> export MYSQL_UNIX_PORT TMPDIR

`some_tmp_dir' should be the path 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:

shell> scripts/mysql_install_db
shell> BINDIR/safe_mysqld &

mysqld crashes at once

If you are running RedHat 5.0 with a version of glibc older than 2.0.7-5, you should make sure you have installed all glibc patches! There is a lot of information about this in the MySQL mail archives. See section 4.11.4 Linux notes (all Linux versions). Links to the mail archives are available at the online MySQL documentation page. You can also start mysqld manually using the --skip-grant option and add the privilege information yourself using mysql:

shell> BINDIR/safe_mysqld --skip-grant &
shell> BINDIR/mysql -u root mysql

From mysql, manually execute the SQL commands in mysql_install_db. Make sure you run mysqladmin reload afterward to tell the server to reload the grant tables.

4.14.2 Problems starting the MySQL server

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

• By invoking mysql.server. This script is used primarily at system startup and shutdown, and is described more fully in section 4.14.3 Automatically starting and stopping MySQL.
• By invoking safe_mysqld, which tries to determine the proper options for mysqld and then runs it with those options.
• By invoking mysqld directly.

Whichever method you use to start the server, if it fails to start up correctly, check the log file to see if you can find out why. Log files are located in the data directory (typically `/usr/local/mysql/data' for a binary distribution, `/usr/local/var' for a source distribution). Look in the data directory for a file with a name of the form `host_name.log', where host_name is the name of your server host. Then check the last few lines of that file:

shell> tail host_name.log

When the mysqld daemon starts up, it changes directory to the data directory. This is where it expects to write log files and the pid (process ID) file, and where it expects to find databases.

The data directory location is hardwired in when the distribution is compiled. However, if mysqld expects to find the data directory somewhere other than where it really is on your system, it will not work properly. If you have problems with incorrect paths, you can find out what options mysqld allows and what the default path settings are by invoking mysqld with the --help option. You can override the defaults by specifying the correct pathnames as command-line arguments to mysqld. (These options can be used with safe_mysqld as well.)

Normally you should need to tell mysqld only the base directory under which MySQL is installed. You can do this with the --basedir option. You can also use --help to check the effect of changing path options (note that --help must be last). For example:

shell> EXECDIR/mysqld --basedir=/usr/local --help

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

If you get the following error:

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

this means that some other program (or another mysqld server) is already using the TCP/IP port or socket mysqld tries to use! You should check with ps that you don't have another mysqld server running. If you can't find another server running, you can try doing telnet your-host-name tcp-ip-port-number and press RETURN a couple of times. If you don't get a error message like telnet: Unable to connect to remote host: Connection refused, something is using the TCP/IP port mysqld is trying to use. See section 4.14.1 Problems running mysql_install_db, See section 17.3 Running multiple MySQL servers on the same machine.

The safe_mysqld script is written so that it normally is able to start a server that was installed from either a source or a binary version of MySQL, even if these install the server in slightly different locations. safe_mysqld expects one of these conditions to be true:

• The server and databases can be found relative to the directory from which safe_mysqld is invoked. safe_mysqld looks under its working directory for `bin' and `data' directories (for binary distributions) or for `libexec' and `var' directories (for source distributions). This condition should be met if you execute safe_mysqld from your MySQL installation directory (for example, `/usr/local/mysql' for a binary distribution).
• If the server and databases cannot be found relative to its working directory, safe_mysqld attempts to locate them by absolute pathnames. Typical locations are `/usr/local/libexec' and `/usr/local/var'. The actual locations are determined when the distribution was built from which safe_mysqld comes. They should be correct if MySQL was installed in a standard location.

Since safe_mysqld will try to find the server and databases relative to its own working directory, you can install a binary distribution of MySQL anywhere, as long as you start safe_mysqld from the MySQL installation directory:

shell> cd mysql_installation_directory
shell> BINDIR/safe_mysqld &

If safe_mysqld fails, even when invoked from the MySQL installation directory, you can modify it to use the path to mysqld and the pathname options that are correct for your system. Note that if you upgrade MySQL sometime, your modified version will be overwritten, so you should make a copy of your edited version that you can reinstall.

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

shell> mysqladmin variables

If safe_mysqld starts the server but you can't connect to it, you should make sure 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.

4.14.3 Automatically starting and stopping MySQL

The mysql.server script can be used to start or stop the server, by invoking it with start or stop arguments:

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

mysql.server can be found in the `share/mysql' directory under the MySQL installation directory, or in the `support-files' directory of the MySQL source tree.

Before mysql.server starts the server, it changes directory to the MySQL installation directory, then invokes safe_mysqld. You might need to edit mysql.server if you have a binary distribution that you've installed in a non-standard location. Modify it to cd into the proper directory before it runs safe_mysqld. You can also modify mysql.server to pass other options to safe_mysqld. For example, if you want the server to run as some specific user, change the --user option in the safe_mysqld invocation. (You must run mysql.server as the Unix root user for this to work.)

mysql.server stop brings down the server by issuing a mysqladmin shutdown command. You should make the script unreadable to anyone but root since you will need to put the password for the MySQL root user in the script. Alternatively, you could edit mysql.server to read the server pid file from the data directory to get the server process ID, and kill that process.

You can take down the server manually by executing mysqladmin shutdown yourself.

You might want to add these start and stop commands to the appropriate places in your `/etc/rc*' files when you start using MySQL for production applications. Note that if you modify mysql.server, then if you upgrade MySQL sometime, your modified version will be overwritten, so you should make a copy of your edited version that you can reinstall.

4.14.4 Option files

MySQL 3.22 can read default startup options for the server and for clients from option files.

MySQL reads default options from the following files on Unix:

Filename	Purpose
/etc/my.cnf	Global options
DATADIR/my.cnf	Server-specific options
~/.my.cnf	User-specific options

DATADIR is the MySQL data directory (typically `/usr/local/mysql/data' or `/usr/local/var'). Note that this is the directory that was specified at configuration time, not the one specified with --datadir when mysqld starts up! (The server looks for option files before it processes any command-line arguments, so --datadir has no effect on where the server looks for those files.)

MySQL reads default options from the following files on Win32:

MySQL tries to read option files in the order listed above. If multiple option files exist, an option specified in a file read later overrides the same option specified in a file read earlier. Options specified on the command line override options specified in any option file. Some options can be specified using environment variables. Options specified on the command line or in option files override environment variable values.

The following programs support option files: mysql, mysqladmin, mysqld, mysqldump, mysqlimport, isamchk and pack_isam.

In option files, you can specify any long option that a program supports! Run the program with --help to get a list of available options.

An option file can contain lines of the following forms:

#comment

Comment lines starts with `#' or `;'. Empty lines are ignored.

[group]

group is the name of the program or group for which you want to set options. After a group line, any option or set-variable lines apply to the named group, until the end of the option file or another group line is given.

option

This is equivalent to --option on the command line.

option=value

This is equivalent to --option=value on the command line.

set-variable = variable=value

This is equivalent to --set-variable variable=value on the command line. This syntax must be used to set a mysqld variable.

The client group allows you to specify options that apply to all MySQL clients (not mysqld). This is the perfect group to use to specify the password you use to connect to the server. (But make sure the option file is readable and writable only to yourself.)

Note that for options and values, all leading and trailing blanks are automatically deleted. You may use the escape sequences `\b', `\t', `\n', `\r', `\\' and `\s' in your value string (`\s' == blank).

Here is a typical global option file:

[client]
port=3306
socket=/tmp/mysql.sock

[mysqld]
port=3306
socket=/tmp/mysql.sock
set-variable = key_buffer=16M
set-variable = max_allowed_packet=1M

[mysqldump]
quick

Here is typical user option file:

[client]
# The following password will be sent to all standard MySQL clients
password=my_password

[mysql]
no-auto-rehash

If you have a source distribution, you will find a sample configuration file named `my-example.cnf' in the `support-files' directory. If you have a binary distribution, look in the `DIR/share/mysql' directory, where DIR is the pathname to the MySQL installation directory (typically `/usr/local/mysql'). You can copy `my-example.cnf' to your home directory (rename the copy to `.my.cnf') to experiment with.

To tell a MySQL program not to read any option files, specify --no-defaults as the first option on the command line. This MUST be the first option or it will have no effect! If you want to check which options are used, you can give the option --print-defaults as the first option.

Note for developers: Option file handling is implemented simply by processing all matching options (i.e., options in the appropriate group) before any command line arguments. This works nicely for programs that use the last instance of an option that is specified multiple times. If you have an old program that handles multiply-specified options this way but doesn't read option files, you need add only two lines to give it that capability. Check the source code of any of the standard MySQL clients to see how to do this.

4.15 Is there anything special to do when upgrading/downgrading MySQL?

You can always move the MySQL form and data files between different versions on the same architecture as long as you have the same base version of MySQL. The current base version is 3. If you change the character set by recompiling MySQL (which may also change the sort order), you must run isamchk -r -q on all tables. Otherwise your indexes may not be ordered correctly.

If you are paranoid and/or afraid of new versions, you can always rename your old mysqld to something like mysqld-'old-version-number'. If your new mysqld then does something unexpected, you can simply shut it down and restart with your old mysqld!

When you do an upgrade you should also backup your old databases, of course. Sometimes it's good to be a little paranoid!

After an upgrade, if you experience problems with recompiled client programs, like Commands out sync or unexpected core dumps, you probably have used an old header or library file when compiling your programs. In this case you should check the date for your `mysql.h' file and `libmysql.a' library to verify that they are from the new MySQL distribution. If not, please recompile your programs!

4.15.1 Upgrading from a 3.21 version to 3.22

Nothing that affects compatibility has changed between 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 fields from an old version of mysqld.

After installing MySQL 3.22 you should start the new server and then run the mysql_fix_privilege_tables script. This will add the new privileges that you need to use the GRANT command. If you forget this, you will get Access denied when you try to use ALTER TABLE or CREATE/DROP INDEX. If your MySQL root user requires a password, you should give this as an argument to mysql_fix_privilege_tables.

The C API interface to mysql_real_connect() has changed. If you have an old client program that calls this function, you must place a 0 for the new db argument (or recode the client to send the db element for faster connections).

4.15.2 Upgrading from a 3.20 version to 3.21

If you already have a version older than 3.20.28 running and want to switch to 3.21.x, you need to do the following:

You can start the mysqld 3.21 server with safe_mysqld --old-protocol to use it with clients from the 3.20 distribution. In this case, the new client function mysql_errno() will not return any server error, only CR_UNKNOWN_ERROR, (but it works for client errors) and the server uses the old password() checking rather than the new one.

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

• All client code must be recompiled. If you are using ODBC, you must get the new MyODBC 2.x driver.
• The script scripts/add_long_password must be run to convert the password field in the mysql.user table to CHAR(16).
• All passwords must be reassigned in the mysql.user table (to get 62-bit rather than 31-bit passwords).
• The table format hasn't changed, so you don't have to convert any tables.

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 on it if you convert the user table. So to be safe, you should first upgrade to at least 3.20.28 and then upgrade to 3.21.x.

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 issue the error message:

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

The new Perl DBI/DBD 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, password (the user and password arguments have changed places).

The following changes may affect queries in old applications:

• HAVING must now be specified before any ORDER BY clause.
• The parameters to LOCATE() has been swapped.
• There are some new reserved words. The most notable are DATE, TIME and TIMESTAMP.

4.15.3 Upgrading to another architecture

Currently the MySQL data and index files (`*.ISD' and `*.ISM' files) are architecture-dependent and in some case OS-dependent. If you want to move your applications to another machine that has a different architecture/OS than your current machine, you should not try to move a database by simply copying the files to the other machine. You should use mysqldump instead.

By default, mysqldump will create a file full of 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 with the newer version to get a fast, compact dump.

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 (compressed in this example):

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

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 accomplish the database transfer. For big tables, this is much faster than simply using mysqldump. In the commands shown below, 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 some corresponding directory on the target machine and load the files into MySQL there:

shell> mysqladmin create db_name
shell> cat DUMPDIR/*.sql | mysql db_name
shell> mysqlimport db_name PATH/*.txt

Also, don't forget to copy the mysql database, since that's where the grant tables (user, db, host) 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 reload so that the server reloads the grant table information.

5 How standards-compatible is MySQL?

5.1 MySQL extensions to ANSI SQL92

MySQL 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 still write portable code that includes MySQL extensions by using comments of the form /*! ... */. In this case, MySQL will execute the code within the comment. For example:

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

MySQL extensions are listed below:

• The field types MEDIUMINT, SET, ENUM and the different BLOB and TEXT types.
• The field attributes AUTO_INCREMENT, BINARY, UNSIGNED and ZEROFILL.
• All string comparisons are case insensitive by default, with sort ordering determined by the current character set (ISO-8859-1 Latin1 by default). If you don't like this, you should declare your columns with the BINARY attribute, which causes comparisons to be done according to the ASCII order used on the MySQL server host.
• MySQL maps databases to directories and tables to filenames. This has two implications:
  • Database names and table names are case sensitive in MySQL on operating systems that have case sensitive filenames (like most Unix systems). If you have a problem remembering table names, create everything in lowercase.
  • You can use standard system commands to backup, rename, move, delete and copy tables. For example, to rename a table, rename the `.ISD', `.ISM' and `.frm' files to which the table corresponds.
• In SQL statements, you can access tables from different databases with the db_name.tbl_name syntax. Some SQL servers provide the same functionality but call this User space. MySQL dosen't support tablespaces like in: create table ralph.my_table...IN my_tablespace.
• LIKE is allowed on numeric columns.
• Use of INTO OUTFILE and STRAIGHT_JOIN in a SELECT statement. See section 7.11 SELECT syntax.
• EXPLAIN SELECT to get a description on how tables are joined.
• Use of index names, indexes on a subpart of a field, and use of INDEX or KEY in a CREATE TABLE statement. See section 7.6 CREATE TABLE syntax.
• Use of CHANGE col_name, DROP col_name or DROP INDEX in an ALTER TABLE statement. See section 7.7 ALTER TABLE syntax.
• Use of IGNORE in an ALTER TABLE statement.
• Use of multiple ADD, ALTER, DROP or CHANGE clauses in an ALTER TABLE statement.
• Use of DROP TABLE with the keywords IF EXISTS.
• Use of DROP TABLE with more than one table.
• Use of LOAD DATA INFILE. In many cases, this syntax is compatible with Oracle's LOAD DATA INFILE. See section 7.15 LOAD DATA INFILE syntax.
• Use of OPTIMIZE TABLE.
• Strings may be enclosed by either `"' or `'', not just by `''.
• Using the escape `\' character.
• The SET OPTION statement. See section 7.24 SET OPTION syntax.
• You don't need to have all columns in the GROUP BY part. This gives better performance for some very specific, but quite normal queries. See section 7.3.12 Functions for use with GROUP BY clauses.
• To make it easier for a user that comes from different SQL environments MySQL supports aliases for many functions. For example, all string functions support both the ANSI SQL and the ODBC syntax.
• MySQL understands the || and && operators to mean logical OR and AND, as in the C programming language. In MySQL, || and OR are synonyms, as are && and AND. Because of this nice syntax, MySQL doesn't support the ANSI SQL operator || for string concatenation; use CONCAT() instead. Since CONCAT() takes any number of arguments, it's easy to convert use of the || operator to MySQL.
• To support use of MySQL-specific keywords as STRAIGHT_JOIN in SQL code that should be portable, you can embed them in a /* */ comment that starts with a '!'. In this case MySQL will parse the comment as it would any other MySQL statement, but other SQL servers will ignore the extensions. For example:

  SELECT /*! STRAIGHT_JOIN */ * from table1,table2 WHERE ...
  

• Use of any of the following functions or commands:
  • CREATE DATABASE or DROP DATABASE. See section 7.4 CREATE DATABASE syntax.
  • % instead of MOD(). % is supported for C programmers and for compatibility with PostgreSQL.
  • =, <>, <= ,<, >=,>, <<, >>, AND, OR or LIKE in a column statement.
  • LAST_INSERT_ID(). See section 18.4.49 How can I get the unique ID for the last inserted row?.
  • REGEXP or NOT REGEXP.
  • CONCAT() or CHAR() with one or more than two arguments. In MySQL these functions can take any number of arguments.
  • BIT_COUNT(), ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD(), ENCRYPT(), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS(), or WEEKDAY().
  • Use of TRIM() to trim substrings. ANSI SQL only supports removal of single characters.
  • The STD(), BIT_OR() and BIT_AND() group functions.
  • Use of REPLACE instead of DELETE + INSERT. See section 7.14 REPLACE syntax.
  • The FLUSH flush_option command.

5.2 Functionality missing from MySQL

The following functionality is missing in the current version of MySQL. For the priority of new extensions, you should consult the MySQL TODO list. That is the latest version of the TODO list in this manual. See section F List of things we want to add to MySQL in the future (The TODO).

5.2.1 Sub-selects

The following will not work in MySQL:

SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);

MySQL only supports INSERT ... SELECT ... and REPLACE ... SELECT ... Independent sub-selects will be probably be available in 3.23.0. You can now use the function IN() in other contexts, however.

5.2.2 SELECT INTO TABLE

MySQL doesn't yet support SELECT ... INTO TABLE .... Currently, MySQL only supports SELECT ... INTO OUTFILE ..., which is basically the same thing.

5.2.3 Transactions

Transactions are not supported. MySQL shortly will support atomic operations, which are like transactions without rollback. With atomic operations, you can execute a group of insert/select/whatever commands and be guaranteed that no other thread will interfere. In this context, you won't usually need rollback. Currently, you can prevent interference from other threads with the help of the LOCK TABLES and UNLOCK TABLES commands. See section 7.23 LOCK TABLES/UNLOCK TABLES syntax.

5.2.4 Stored procedures and triggers

A stored procedure is a set of SQL commands that can be compiled and stored in the server. Once this has been done, clients don't need to keep reissuing the entire query but can refer to the stored procedure. This provides more speed because the query has to be parsed only once and less data need be sent between the server and the client. You can also raise the conceptual level by having libraries of functions in the server.

A trigger is a stored procedure that is invoked when a particlar event occurs. For example, you can install a stored procedure that is triggered each time a record is deleted from a transaction table and that automatically deletes the corresponding customer from a customer table when all his transactions are deleted.

The planned update language will be able to handle stored procedures, but without triggers. Triggers usually slow down everything, even queries for which they are not needed.

To see when MySQL might get stored procedures, see section F List of things we want to add to MySQL in the future (The TODO).

5.2.5 Foreign Keys

Note that foreign keys in SQL are not used to join tables, but are used mostly for checking referential integrity. If you want to get results from multiple tables from a SELECT statement, you do this by joining tables!

SELECT * from table1,table2 where table1.id = table2.id

See section 7.12 JOIN syntax.

The FOREIGN KEY syntax in MySQL exists only for compatibility with other SQL vendors' CREATE TABLE commands; it doesn't do anything. The FOREIGN KEY syntax without ON DELETE ... is mostly used for documentation purposes. Some ODBC applications may use this to produce automatic WHERE clauses, but this is usually easy to override. FOREIGN KEY is sometimes used as a constraint check, but this check is unnecessary in practice if rows are inserted into the tables in the right order. MySQL only supports these clauses because some applications require them to exist (regardless of whether or not they work!).

In MySQL, you can work around the problem of ON DELETE ... not being implemented by adding the appropriate DELETE statement to an application when you delete records from a table that has a foreign key. In practice this is as quick (in some cases quicker) and much more portable than using foreign keys.

In the near future we will extend the FOREIGN KEY implementation so that at least the information will be saved and may be retrieved by mysqldump and ODBC.

5.2.5.1 Reasons NOT to use foreign keys

There are so many problems with FOREIGN KEYs that we don't know where to start:

• Foreign keys make life very complicated, because the foreign key definitions must be stored in a database and implementing them would destroy the whole "nice approach" of using files that can be moved, copied and removed.
• The speed impact is terrible fore INSERT and UPDATE statements, and in this case almost all FOREIGN KEY checks are useless because one usually inserts records in the right tables in the right order.
• There is also a need to hold locks on many more tables when updating one table, because the side effects can cascade through the entire database. It's MUCH faster to delete records from one table first and subsequently delete them from the other tables.
• You can no longer restore a table by doing a full delete from the table and then restoring all records (from a new source or from a backup).
• If you have foreign keys you can't dump and restore tables unless you do so in a very specific order.
• It's very easy to do "allowed" circular definitions that make the tables impossible to recreate each table with a single create statement, even if the definition works and is usable.

The only nice aspect of foreign key is that it gives ODBC and some other client programs the ability to see how a table is connected and use this to show connection diagrams and to help building applicatons.

MySQL will soon store FOREIGN KEY definitions so that a client can ask for and receive an answer how the original connection was made. The current `.frm' file format does not have any place for it.

5.2.6 Views

MySQL doesn't support views, but this is on the TODO.

5.2.7 `--' as the start of a comment

Some other SQL databases use `--' to start comments. MySQL has `#' as the start comment character, even if the mysql command line tool removes all lines that start with `--'. You can also use the C comment style /* this is a comment */ with MySQL. See section 7.28 Comment syntax.

MySQL will not support `--'; this degenerate comment style has caused many 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!

What do you think will happen when the value of payment is negative?

Because 1--1 is legal in SQL, we think it is terrible that `--' means start comment.

If you have a SQL program in a text file that contains `--' comments you should use:

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

instead of the normal:

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

You can also change the `--' comments to `#' comments in the command file:

shell> replace " --" " #" -- text-file-with-funny-comments.sql

Change them back with this command:

shell> replace " #" " --" -- text-file-with-funny-comments.sql

5.3 What standards does MySQL follow?

Entry level SQL92. ODBC level 0-2.

5.4 Limitations of BLOB and TEXT types

If you want to use GROUP BY or ORDER BY on a BLOB or TEXT field, you must make the field into a fixed-length object. The standard way to do this is with the SUBSTRING function. For example:

mysql> select comment from tbl_name order by SUBSTRING(comment,20);

If you don't do this, only the first max_sort_length bytes (default=1024) are considered when sorting.

BLOB and TEXT cannot have DEFAULT values and will also always be NULL columns.

5.5 How to cope without COMMIT-ROLLBACK

MySQL doesn't support COMMIT-ROLLBACK. The problem is that handling COMMIT-ROLLBACK efficiently would require a completely different table layout than MySQL uses today. MySQL would also need extra threads that do automatic cleanups on the tables and the disk usage would be much higher. This would make MySQL about 2-4 times slower than it is today. MySQL is much faster than almost all other SQL databases (typically at least 2-3 times faster). One of the reasons for this is the lack of COMMIT-ROLLBACK.

For the moment, we are much more for implementing the SQL server language (something like stored procedures). With this you would very seldom really need COMMIT-ROLLBACK. This would also give much better performance.

Loops that need transactions normally can be coded with the help of LOCK TABLES, and you don't need cursors when you can update records on the fly.

We have transactions and cursors on the TODO but not quite prioritized. If we implement these, it will be as an option to CREATE TABLE. That means that COMMIT-ROLLBACK will only work on those tables and only those tables will be slower.

We at TcX have a greater need for a real fast database than a 100% general database. Whenever we find a way to implement these features without any speed loss, we will probably do it. For the moment, there are many more important things to do. Check the TODO for how we prioritize things at the moment. Customers with higher levels of support can alter this, so things may be reprioritized.

The current problem is actually ROLLBACK. Without ROLLBACK, you can do any kind of COMMIT action with LOCK TABLES. To support ROLLBACK, MySQL would have to be changed to store all old records that were updated and revert everything back to the starting point if ROLLBACK was issued. For simple cases, this isn't that hard to do (the current isamlog could be used for this purpose), but it would be much more difficult to implement ROLLBACK for ALTER/DROP/CREATE TABLE.

To avoid using ROLLBACK, you can use the following strategy:

1. Use LOCK TABLES ... to lock all the tables you want to access.
2. Test conditions.
3. Update if everything is okay.
4. UNLOCK TABLES

This is usually a much faster method than using transactions with possible ROLLBACKs, although not always. The only situation this solution doesn't handle is when someone kills the threads in the middle of an update. In this case, all locks will be released but some of the updates may not have been executed.

You can also use functions to update records in a single operation. You can get a very efficient application by using the following techniques:

• Modify fields relative to their current value
• Update only those fields that actually have changed

For example, when we are doing updates on some customer information, we update only the customer data that have changed and test only that none of the changed data, or data that depend on the changed data, have changed compared to the original row. The test for changed data is done with the WHERE clause in the UPDATE statement. If the record wasn't updated, we give the client a message: "Some of the data you have changed have been changed by another user". Then we show the old row versus the new row in a window, so the user can decide which version of the customer record he should use.

This gives us something that is similar to "column locking" but is actually even better, because we only update some of the columns with values that are relative to their current values. This means that typical UPDATE statements look something like these:

UPDATE tablename SET pay_back=pay_back+'relative change';

UPDATE customer
  SET
    customer_date='current_date',
    address='new address',
    phone='new phone',
    money_he_owes_us=money_he_owes_us+'new_money'
  WHERE
    customer_id=id AND address='old address' AND phone='old phone';

As you can see, this is very efficient and works even if another client has changed the values in the pay_back or money_he_owes_us columns.

In many cases, users have wanted ROLLBACK and/or LOCK TABLES to manage unique identifiers for some tables. This can be handled much more efficiently by using an AUTO_INCREMENT column and either the SQL LAST_INSERT_ID() function or the C API function mysql_insert_id(). See section 18.4.49 How can I get the unique ID for the last inserted row?.

At TcX, we have never had any need for row-level locking because we have always been able to code around it. Some cases really need row locking, but they are very few. If you want row-level locking, you can use a flag column in the table and do something like this:

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

MySQL returns 1 for the number of affected rows if the row was found and row_flag wasn't already 1 in the original row.

6 The MySQL access privilege system

MySQL has an advanced but non-standard security/privilege system. This section describes how it works.

6.1 What the privilege system does

The primary function of the MySQL privilege system is to associate a user name on a host with select, insert, update and delete privileges on a database.

Additional functionality includes the ability to have an anonymous user and to grant privileges for MySQL-specific functions such as LOAD DATA INFILE and administrative operations.

Please note that user names, as used by MySQL for authentication purposes, have nothing to do with Unix user names (login names) or Windows user names. Most MySQL clients try to log in using the current Unix user name as the MySQL user name, but that is for convenience only. Client programs allow a different name to be specified with the -u or --user options. This means that you can't make a database secure in any way unless all MySQL user names have passwords. Anyone may attempt to connect to the server using any name, and they will succeed if you don't have a password for each name.

MySQL user names can be up to 16 characters long, whereas Unix user names typically are limited to 8 characters.

MySQL passwords have nothing to do with Unix passwords, either. There is no necessary connection between the password you use to log in on a Unix machine and the password you use to access a database on that machine. MySQL also encrypts passwords using a different algorithm than the one used during the Unix login process.

6.2 Connecting to the MySQL server

MySQL client programs generally require that you specify connection parameters: the host you want to connect to, your user name and your password. For example, the mysql client can be started like this (optional arguments are enclosed between `[' and `]'):

shell> mysql [-h host_name] [-u user_name] [-pyour_pass]

Note that there is no space between -p and the password following it.

Alternate forms of the -h, -u and -p options are --host=host_name, --user=user_name and --password=your_pass.

mysql uses default values for connection parameters that are missing from the command line. The default hostname is localhost and the default user name is your Unix login name. (No password is supplied if -p is missing.) Thus, for a Unix user joe, the following commands are equivalent:

shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql

Other MySQL clients behave similarly.

On Unix systems, you can specify different default values to be used when you make a connection, so that you need not enter them on the command line each time you invoke a client program:

• You can specify connection parameters in the [client] section of the `.my.cnf' configuration file in your home directory. The relevant section of the file might look like this:

  [client]
  host=host_name
  user=user_name
  password=your_pass
  

  See section 4.14.4 Option files.
• You can specify connection parameters using environment values. The host can be specified using MYSQL_HOST. The MySQL user name can be specified using USER, LOGNAME or LOGIN (although these variables might already be set to your Unix login name, and it may be wise not to change them). The password can be specified using MYSQL_PWD (but this is insecure; see next section).

If connection parameters are specified in multiple ways, values specified on the command line override values specified in configuration files and environment variables, and values in configuration files override values in environment variables.

6.2.1 Keeping your password secure

It is inadvisable to specify your password in a way that exposes it to discovery by other users. The methods you can use to specify your password when you run client programs are listed below, along with an assessment of the risks of each method:

• Use a -pyour_pass or --password=your_pass option on the command line. This is convenient but insecure, since your password becomes visible to system status programs (such as ps) that may be invoked by other users to display command lines. (MySQL clients typically overwrite the command line argument with zeroes during their initialization sequence, but there is still a brief interval during which the value is visible.)
• Use a -p or --password option (with no your_pass value specified). In this case, the client program solicits the password from the terminal:

  shell> mysql -u user_name -p
  Enter password: ********
  

  The client echoes `*' characters to the terminal as you enter your password so that onlookers cannot see it. It is more secure to enter your password this way than to specify it on the command line because it is not visible to other users. However, this method of entering a password is unsuitable if you want to invoke a client from a script that runs non-interactively.
• Store your password in a configuration file. For example, you can list your password in the [client] section of the `.my.cnf' file in your home directory:

  [client]
  password=your_pass
  

  If you store your password in `.my.cnf', the file should not be group or world readable or writable. Make sure the file's access mode is 400 or 600.
• You can store your password in the MYSQL_PWD environment variable, but this method must be considered extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes; your password will be in plain sight for all to see if you set MYSQL_PWD. Even on systems without such a version of ps, it is unwise to assume there is no other method to observe process environments.

All in all, the safest methods are probably to have the client program prompt for the password or to specify the password in a properly-protected `.my.cnf' file.

6.3 Privileges provided by MySQL

Privilege information is stored in the user, db, host, tables_priv and columns_priv tables in the mysql database (that is, in the database named mysql). The MySQL server reads the contents of these tables when it starts up and under the circumstances indicated in section 6.7 When privilege changes take effect.

The names used in this manual to refer to the privileges provided by MySQL are shown below, along with the table column name associated with each privilege in the grant tables and the context in which the privilege applies:

The select, insert, update and delete privileges allow you to perform operations on rows in existing tables in a database.

SELECT statements require the select privilege only if they actually retrieve rows from a table. You can execute certain SELECT statements even without permission to access any of the databases on the server. For example, you could use the mysql client as a simple calculator:

mysql> SELECT 1+1;
mysql> SELECT PI()*2;

The index privilege allows you to create or drop (remove) indexes.

The alter privilege allows you to use ALTER TABLE.

The create and drop privileges allow you to create new databases and tables, or to drop (remove) existing databases and tables.

Note that if you grant the drop privilege for the mysql database to a user, that user can drop the database in which the MySQL access privileges are stored!

The grant privilege allows you to give to other users those privileges you yourself possess.

The file privilege gives you permission to read and write files on the server using the LOAD DATA INFILE and SELECT ... INTO OUTFILE statements. Any user to whom this privilege is granted can read or write any file that the MySQL server can read or write.

The remaining privileges are used for administrative operations, which are performed using the mysqladmin program. The table below shows which mysqladmin commands each administrative privilege allows you to execute:

The reload command tells the server to reread the grant tables. The refresh command flushes all tables and opens and closes the log files. flush-privileges is a synonym for reload. The other flush-* commands perform functions similar to refresh but are more limited in scope, and may be preferable in some instances. For example, if you want to flush just the log files, flush-logs is a better choice than refresh.

The shutdown command shuts down the server.

The processlist command displays information about the threads executing within the server. The kill command kills server threads. You can always display or kill your own threads, but you need the process privilege to display or kill threads initiated by other users.

Certain privileges should be granted sparingly:

• The grant privilege allows users to give away their privileges to other users. Two users with different privileges and with the grant privilege are able to combine privileges.
• The file privilege can be abused to read any world-readable file on the server into a database table, the contents of which can then be accessed using SELECT.
• The shutdown privilege can be abused to deny service to other users entirely.
• The process privilege can be used to view the plain text of currently executing queries, including queries that set or change passwords.
• Privileges on the mysql database can be used to change passwords and other access privilege information. (Even though passwords are stored encrypted, a malicious user can, with sufficient privileges, replace a password with a different one.)

There are some things that you cannot do with the MySQL privilege system:

• You cannot explicitly specify that a given user should be denied access. That is, you cannot explicitly match a user and then refuse the connection.
• You cannot specify that a user has privileges to create or drop tables in a database but not to create or drop the database itself.

6.4 How the privilege system works

The MySQL privilege system ensures that all users may do exactly the things that they are supposed to be allowed to do. When you connect to a MySQL server, your identity is determined by the host from which you connect and the user name you specify. The system grants privileges according to your identity and what you want to do.

MySQL considers both your hostname and user name in identifying you because there is little reason to assume that a given user name belongs to the same person everywhere on the Internet. For example, the user bill who connects from whitehouse.gov need not be the same person as the user bill who connects from microsoft.com. MySQL handles this by allowing you to distinguish users on different hosts that happen to have the same name: you can grant bill one set of privileges for connections from whitehouse.gov, and a different set of privileges for connections from microsoft.com.

MySQL access control involves two stages:

• Stage 1: The server checks whether or not you are even allowed to connect.
• Stage 2 (assuming the server lets you connect): The server checks each request you issue to see whether or not you have sufficient privileges to perform it. For example, if you try to select rows from a table in a database or drop a table from the database, the server makes sure you have the select privilege for the table or the drop privilege for the database.

The server uses the user, db and host tables in the mysql database at both stages of access control. The fields in these grant tables are shown below:

For the second stage of access control (request verification), the server may, if the request involves tables, additionally consult the tables_priv and columns_priv tables. The fields in these tables are shown below:

Each grant table contains scope fields and privilege fields.

Scope fields determine the scope of each entry in the tables, i.e., the context in which the entry applies. For example, a user table entry with Host and User values of 'thomas.loc.gov' and 'bob' would be used for authenticating connections made to the server by bob from the host thomas.loc.gov. Similarly, a db table entry with Host, User and Db fields of 'thomas.loc.gov', 'bob' and 'reports' would be used when bob connects from the host thomas.loc.gov to access the reports database. The tables_priv and columns_priv tables contain scope fields indicating tables or table/column combinations to which each entry applies.

For access-checking purposes, comparisons of Host values are case insensitive. User, Password, Db and Table_name values are case sensitive. Column_name values are case insensitive in MySQL 3.22.12 and up (but case sensitive in 3.22.11).

Privilege fields indicate the privileges granted by a table entry, that is, what operations can be performed. The server combines the information in the various grant tables to form a complete description of a user's privileges. The rules used to do this are described in section 6.6 Access control, stage 2: Request verification.

Scope fields are strings, declared as shown below; the default value for each is the empty string:

In the user, db and host tables, all privilege fields are declared as ENUM('N','Y') -- each can have a value of 'N' or 'Y', and the default value is 'N'.

In the tables_priv and columns_priv tables, the privilege fields are declared as SET fields:

Briefly, the server uses the grant tables like this:

• The user table scope fields determine whether to allow or reject incoming connections. For allowed connections, the privilege fields indicate the user's global (superuser) privileges.
• The db and host tables are used together:
  • The db table scope fields determine which users can access which databases from which hosts. The privilege fields determine which operations are allowed.
  • The host table is used as an extension of the db table when you want a given db table entry to apply to several hosts. For example, if you want a user to be able to use a database from several hosts in your network, leave the Host value empty in the user's db table entry, then populate the host table with an entry for each of those hosts. This mechanism is described more detail in section 6.6 Access control, stage 2: Request verification.
• The tables_priv and columns_priv tables are similar to the db table, but are more fine-grained: they apply at the table and column level rather than at the database level.

Note that administrative privileges (reload, shutdown, etc.) are specified only in the user table. This is because administrative operations are operations on the server itself and are not database-specific, so there is no reason to list such privileges in the other grant tables. In fact, only the user table need be consulted to determine whether or not you can perform an administrative operation.

The file privilege is specified only in the user table, too. It is not an administrative privilege as such, but your ability to read or write files on the server host is independent of the database you are accessing.

The mysqld server reads the contents of the grant tables once, when it starts up. Changes to the grant tables take effect as indicated in section 6.7 When privilege changes take effect.

When you modify the contents of the grant tables, it is a good idea to make sure that your changes set up privileges the way you want. A useful diagnostic tool is the mysqlaccess script, which Yves Carlier has provided for the MySQL distribution. Invoke mysqlaccess with the --help option to find out how it works. Also, see section 6.11 Causes of Access denied errors and section 6.12 How to make MySQL secure against crackers.

Note that mysqlaccess checks access using only the user, db and host tables. It does not check table- or column-level privileges.

6.5 Access control, stage 1: Connection verification

When you attempt to connect to a MySQL server, the server accepts or rejects the connection based on your identity and whether or not you can verify your identity by supplying the correct password. If not, the server completely denies access to you. Otherwise, the server accepts the connection, then enters stage 2 and waits for requests.

Your identity is based on two pieces of information:

• The host from which you connect
• Your MySQL user name

Identity checking is performed using the three user table scope fields (Host, User and Password). The server accepts the connection only if a user table entry matches your hostname and user name, and you supply the correct password.

You can specify user table scope field values as follows:

• A Host value may be a hostname or an IP number, or 'localhost' to indicate the local host,
• You can use the wildcard characters `%' and `_' in the Host field.
• A Host value of '%' matches any hostname. A blank Host value is equivalent to '%'. Note that these values match any host that can create a connection to your server!
• Wildcard characters are not allowed in the User field, but you can specify a blank value, which matches any name. If the matching entry for an incoming connection has a blank user name, the user is considered to be the anonymous user, the user with no name), rather than the name that the client actually specified. This means that all further access checking for the duration of the connection is done using a blank user name.
• The Password field can be blank. This does not mean that any password matches, it means the user must connect without specifying a password.

The table below shows some examples of how various combinations of Host and User values in user table entries apply to incoming connections:

Since you can use IP wildcard values in the Host field (e.g., '144.155.166.%' to match every host on a subnet), there is the possibility that someone might try to exploit this capability by naming a host 144.155.166.somewhere.com. To foil such attempts, MySQL disallows matching on hostnames that start with digits and a dot. Thus, if you have a host named something like 1.2.foo.com, its name will never match the Host column of the grant tables. Only an IP number can match an IP wildcard value.

How does the server choose which user table entry to use if more than one matches? This question is resolved by the way the user table is sorted, which is done at server startup time. Suppose the user table looks like this:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

When the server reads in the table, it orders the entries with the most-specific Host values first ('%' in the Host column means "any host" and is least specific). Entries with the same Host value are ordered with the most-specific User values first (a blank User value means "any user" and is least specific). As a result, the sorted user table looks like this:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

The matching algorithm looks through the sorted entries and uses the first match found. For a connection from localhost by jeffrey, the entries with 'localhost' in the Host column match first. Of those, the entry with the blank user name matches both the connecting hostname and user name. (The '%'/'jeffrey' entry would have matched, too, but it is not the first match in the table.)

Here is another example. Suppose the user table looks like this:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

The sorted table looks like this:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

A connection from thomas.loc.gov by jeffrey is matched by the first entry, whereas a connection from whitehouse.gov by jeffrey is matched by the second.

If you have problems connecting to the server, print out the user table and sort it by hand to see where the first match is being made.

6.6 Access control, stage 2: Request verification

Once you establish a connection, the server enters stage 2. For each request that comes in on the connection, the server checks whether you have sufficient privileges for it, based on the type of operation you wish to perform. This is where the privilege fields in the grant tables come into play. These privileges can come from any of the user, db, host, tables_priv or columns_priv tables. The grant tables are manipulated with GRANT and REVOKE commands. See section 7.25 GRANT and REVOKE syntax. (You may find it helpful to refer to the table shown earlier that lists the fields present in each of the grant tables; see section 6.4 How the privilege system works.)

The user table grants privileges that are assigned to you on a global basis and that apply no matter what the current database is. For example, if the user table grants you the delete privilege, you can delete rows from any database on the server host! In other words, user table privileges are superuser privileges and it is wise to grant privileges in the user table only to superusers (such as server or database administrators). For other users, you should leave the privileges in the user table set to 'N' and grant privileges on a database-specific basis only, using the db and host tables.

The db and host tables grant database-specific privileges. The wildcard characters `%' and `_' can be used in the Host and Db fields of each table and blank values are allowed in any of the scope fields. A '%' Host value means "any host." A blank Host value in the db table means "consult the host table for further information." A '%' or blank Db value in the host table means or "any database." A blank User value matches the anonymous user.

The db and host tables are read in and sorted when the server starts up (at the same time that it reads the user table). The db table is sorted on the Host, Db and User scope fields, and the host table is sorted on the Host and Db scope fields. As with the user table, sorting puts the most-specific values first and least-specific values last, and when the server looks for matching entries, it uses the first match that it finds.

The tables_priv and columns_priv tables grant table- and column-specific privileges. The same wildcards are allowed in the Host field as for the Host field in the db and host tables, but the Db, Table_name and Column_name fields cannot contain wildcards or be blank.

The tables_priv and columns_priv tables are sorted similarly to the db table, although since only the Host table may contain wildcards, the sorting is simpler.

The request verification process is described below. If you are familiar with the access-checking source code, you will notice that the description here differs slightly from the algorithm used in the code. The description is equivalent to what the code actually does; it differs only to make the explanation simpler.

For administrative requests (shutdown, reload, etc.), the server checks only the user table entry, since that is the only table that specifies administrative privileges. Access is granted if the entry allows the requested operation and denied otherwise. For example, if you want to execute mysqladmin shutdown but your user table entry doesn't grant the shutdown privilege to you, access is denied without even checking the db or host tables (there is no need to do so, because they contain no Shutdown_priv column).

For database-related requests (insert, update, etc.), the server first checks the user's global (superuser) privileges by looking in the user table entry. If the entry allows the requested operation, access is granted.

If the global privileges in the user table are insufficient, the server determines the user's database-specific privileges by checking the db and host tables:

1. The server looks in the db table for a match on the Host, Db and User fields. Host and User are matched to the connecting user's hostname and MySQL user name. The Db field is matched to the database the user wants to access. If there is no entry for the Host and User, access is denied.
2. If there is a matching db table entry and its Host field is not blank, that entry defines the user's database-specific privileges.
3. If the matching db table entry's Host field is blank, it signifies that the host table enumerates which hosts should be allowed access to the database. In this case, a further lookup is done in the host table to find a match on the Host and Db fields. If no host table entry matches, access is denied. If there is a match, the user's database-specific privileges are computed as the intersection of the privileges in the db and host table entries, i.e., the privileges that are 'Y' in both entries. (This way you can grant general privileges in the db table entry and then selectively restrict them on a host-by-host basis using the host table entries.)

After determining the database-specific privileges granted by the db and host table entries, the server adds them to the global privileges granted by the user table. If the result allows the requested operation, access is granted. Otherwise, the server checks the user's table and column privileges in the tables_priv and columns_priv tables and adds those to the user's privileges. Access is allowed or denied based on the result.

It may not be apparent why the server adds the database-, table- and column-specific privileges to the global user entry privileges for those cases in which the user privileges are initially found to be insufficient for the requested operation. The reason is that a request might require more than one type of privilege. For example, if you execute an INSERT ... SELECT statement, you need both insert and select privileges. Your privileges might be such that the user table entry grants one privilege and the db table entry grants the other. In this case, you have the necessary privileges to perform the request, but the server cannot tell that from either table by itself; the privileges granted by both entries must be combined.

The host table can be used to maintain a list of "secure" servers. At TcX, the host table contains a list of all machines on the local network. These are granted all privileges.

You can also use the host table to indicate hosts that are not secure. Suppose you have a machine public.your.domain that is located in a public area that you do not consider secure. You can allow access to all hosts on your network except that machine with host table entries like this:

+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (all privileges set to 'N')
| %.your.domain      | %  | ... (all privileges set to 'Y')
+--------------------+----+-

Naturally, you should always test your entries in the grant tables (e.g., using mysqlaccess) to make sure your access privileges are actually set up the way you think they are.

6.7 When privilege changes take effect

When mysqld starts, all grant table contents are read into memory and become effective at that point.

Modifications to the grant tables that you perform using GRANT, REVOKE, or SET PASSWORD are noticed by the server immediately.

If you modify the grant tables manually (using INSERT, UPDATE, etc.), you should execute a FLUSH PRIVILEGES statement or run mysqladmin flush-privileges to tell the server to reload the grant tables. Otherwise your changes will have no effect until you restart the server.

When the server notices that the grant tables have been changed, existing client connections are affected as follows:

• Table and column privilege changes take effect with the client's next request.
• Database privilege changes take effect at the next USE db_name command.
• Global privilege and password changes take effect the next time the client connects.

6.8 Setting up the initial MySQL privileges

After installing MySQL, you set up the initial access privileges by running scripts/mysql_install_db. See section 4.7.1 Quick installation overview. The scripts/mysql_install_db script starts up the mysqld server, then initializes the grant tables to contain the following set of privileges:

• The MySQL root user is a superuser and can do anything. Connections must be made from the local host. Note: The initial root password is empty, so anyone can connect as root without a password and be granted all privileges.
• Anonymous-user privileges allow anything to be done with databases that have a name of 'test' or starting with 'test_'. Any user can connect from the local host and be treated as the anonymous user.
• Other privileges are denied. For example, normal users can't use mysqladmin shutdown or mysqladmin processlist.

Since your installation is initially wide open, one of the first things you should do is specify a password for the MySQL root user. You can do this as follows (note that you specify the password using the PASSWORD() function):

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

or

shell> mysqladmin -u root password new_password

Note that if you use the first method, which updates the password in the user table directly, you have to tell the server to reread the grant tables (with FLUSH PRIVILEGES), since the change will go unnoticed otherwise.

Once the root password has been set, you must supply that password whenever you connect to the server as root.

You may wish to leave the root password blank so that you don't need to specify it while you perform additional setup or testing, but be sure to set it before using your installation for any real production work.

See the scripts/mysql_install_db script to see how it sets up the default privileges. You can use this as a basis to see how to add other users.

If you want the initial privileges to be different than those just described above, you can modify mysql_install_db before you run it.

To recreate the grant tables completely, remove all the `*.ISM' and `*.ISD' files in the directory containing the mysql database. (This is the directory named `mysql' under the database directory, which is listed when you run mysqld --help.) Then run the mysql_install_db script, possibly after editing it first to have the privileges you want.

6.9 Adding new user privileges to MySQL

You can add users in two different ways: by using GRANT statements or by manipulating the MySQL grant tables directly. Use of GRANT statements is the preferred method.

The examples below show how to use the mysql client to set up new users. These examples assume that privileges are set up according to the defaults described in the previous section. This means that to make changes, you must be on the same machine where mysqld is running, and you must connect as the MySQL root user, and the root user must have the insert privilege for the mysql database and the reload administrative privilege. If you have changed the root user password, you must also specify it for the mysql commands below.

You can add new users by issuing GRANT statements:

shell> mysql --user=root mysql
mysql> GRANT ALL PRIVILEGES ON *.* TO monty@localhost
           IDENTIFIED BY 'something' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO monty@"%"
           IDENTIFIED BY 'something' WITH GRANT OPTION;
mysql> GRANT RELOAD,PROCESS ON *.* TO admin@localhost;
mysql> GRANT USAGE ON *.* TO dummy@localhost;

These GRANT statements set up three new users:

monty

A full superuser who can connect to the server from anywhere, but who must use a password to do so. Note that we must issue GRANT statements for both monty@localhost and monty@"%". If we don't add the entry with localhost, the anonymous user entry for localhost that is created by mysql_install_db will take precedence when we connect from the local host, because it has a more specific Host field value and comes earlier in the sort order.

admin

A user who can connect from localhost without a password and who is granted the reload and process administrative privileges. This allows the user to execute the mysqladmin reload, mysqladmin refresh and mysqladmin flush-* commands, as well as mysqladmin processlist . No database-related privileges are granted. They could be granted later by issuing additional GRANT statements.

dummy

A user who can connect without a password, but only from the local host. The global privileges are all set to 'N' because the privilege type is USAGE, which allows you to set up a user with no privileges. It is assumed that you would grant database-specific privileges later.

You can also add the same user access information directly by issuing INSERT statements and then telling the server to reload the grant tables:

shell> mysql --user=root mysql
mysql> INSERT INTO user VALUES('localhost','monty',PASSWORD('something'),
                'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y')
mysql> INSERT INTO user VALUES('%','monty',PASSWORD('something'),
                'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y')
mysql> INSERT INTO user SET Host='localhost',User='admin', 
                 Reload_priv='Y', Process_priv='Y';
mysql> INSERT INTO user (Host,User,Password)
                        VALUES('localhost','dummy',");
mysql> FLUSH PRIVILEGES;

Note that depending on your MySQL version, you may have to use a different number of 'Y' values above. The extended (more readable) INSERT syntax that is available starting with 3.22.11 is used here for the admin user.

Note that to set up a superuser, you need only create a user table entry with the privilege fields set to 'Y'. No db or host table entries are necessary.

The privilege columns in the user table were not set explicitly in the last INSERT statement (for the dummy user), so those columns are assigned the default value of 'N'.

The following example adds a user custom who can connect from hosts localhost, server.domain and whitehouse.gov. He wants to access the bankaccount database only from localhost, the expenses database only from whitehouse.gov and the customer database from all three hosts. He wants to use the password stupid from all three hosts.

To set up this user's privileges using GRANT statements, run these commands:

shell> mysql --user=root mysql
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
           ON bankaccount.*
           TO custom@localhost
           IDENTIFIED BY 'stupid';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
           ON expenses.*
           TO custom@whitehouse.gov
           IDENTIFIED BY 'stupid';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
           ON customer.*
           TO custom@'%'
           IDENTIFIED BY 'stupid';

To set up the user's privileges by modifying the grant tables directly, run these commands (note the FLUSH PRIVILEGES at the end):

shell> mysql --user=root mysql
mysql> INSERT INTO user (Host,User,Password)
       VALUES('localhost','custom',PASSWORD('stupid'));
mysql> INSERT INTO user (Host,User,Password)
       VALUES('server.domain','custom',PASSWORD('stupid'));
mysql> INSERT INTO user (Host,User,Password)
       VALUES('whitehouse.gov','custom',PASSWORD('stupid'));
mysql> INSERT INTO db
       (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
        Create_priv,Drop_priv)
       VALUES
       ('localhost','bankaccount','custom','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
       (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
        Create_priv,Drop_priv)
       VALUES
       ('whitehouse.gov','expenses','custom','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
       (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
        Create_priv,Drop_priv)
       VALUES('%','customer','custom','Y','Y','Y','Y','Y','Y');
mysql> FLUSH PRIVILEGES;

The first three INSERT statements add user table entries that allow user custom to connect from the various hosts with the given password, but grant no permissions to him (all privileges are set to the default value of 'N'). The next three INSERT statements add db table entries that grant privileges to custom for the bankaccount, expenses and customer databases, when accessed from the proper hosts. As usual, when the grant tables are modified directly, the server must be told to reload the grant tables so that the changes take effect.

If you want to give a specific user access from any machine in a given domain, you can issue a GRANT statement like the following:

mysql> GRANT ...
           ON *.*
           TO myusername@"%.mydomainname.com"
           IDENTIFIED BY 'mypassword';

To do the same thing by modifying the grant tables directly, do this:

mysql> INSERT INTO user VALUES ('%.mydomainname.com', 'myusername', 
           PASSWORD('mypassword'),...);
mysql> FLUSH PRIVILEGES;

You can also use xmysqladmin, mysql_webadmin and even xmysql to insert, change and update values in the grant tables. You can find these utilities at http://www.mysql.com/Contrib.

6.10 How to set up passwords

The examples in the preceding sections illustrate an important principle: when you store a non-empty password using INSERT or UPDATE statements, you must use the PASSWORD() function to encrypt it. This is because the user table stores passwords in encrypted form, not as plaintext. If you forget that fact, you are likely to attempt to set passwords like this:

shell> mysql -u root mysql
mysql> INSERT INTO user (Host,User,Password)
       VALUES('%','jeffrey','bLa81m0');
mysql> FLUSH PRIVILEGES;

The result is that the plaintext value 'bLa81m0' is stored as the password in the user table. When the user jeffrey attempts to connect to the server using this password, the mysql client encrypts it and sends the result to the server. The server compares the value in the user table (which is the plaintext value 'bLa81m0') to the encrypted password (which is not 'bLa81m0'). The comparison fails and the server rejects the connection:

shell> mysql -u jeffrey -pbLa81m0 test
Access denied

Since passwords must be encrypted when they are inserted in the user table, the INSERT statement should have been specified like this instead:

mysql> INSERT INTO user (Host,User,Password)
       VALUES('%','jeffrey',PASSWORD('bLa81m0'));

You must also use the PASSWORD() function when you use SET PASSWORD statements:

mysql> SET PASSWORD FOR jeffrey@"%" = PASSWORD('bLa81m0');

Note: The PASSWORD() function performs password encryption, but it does not do so in the same way that Unix passwords are encrypted. You should not assume that if your Unix password and your MySQL password are the same, PASSWORD() will result in the same encrypted value as is stored in the Unix password file.

If you set passwords using the GRANT ... IDENTIFIED BY statement or the mysqladmin password command, the PASSWORD() function is unnecessary. They both take care of encrypting the password for you:

mysql> GRANT USAGE ON *.* TO jeffrey@"%" IDENTIFIED BY 'bLa81m0';

shell> mysqladmin -u jeffrey password bLa81m0

6.11 Causes of Access denied errors

If you encounter Access denied errors when you try to connect to the MySQL server, the list below indicates some courses of action you can take to correct the problem:

• Did you run the mysql_install_db script after installing MySQL, to set up the initial grant table contents? If not, do so. See section 6.8 Setting up the initial MySQL privileges. Test these initial privileges by executing this command:

  shell> mysql -u root test
  

  The server should let you connect without error. You should also make sure you have a file `user.ISD' in the MySQL database directory (ordinarily, this is `PATH/var/mysql/user.ISD', where PATH is the pathname to the MySQL installation root).
• After a fresh installation, you should connect to the server and set up your users and access permissions:

  shell> mysql -u root mysql
  

  The server should let you connect because the MySQL root user has no password initially. Since that is also a security risk, setting the root password is something you should do while you're setting up your other MySQL users. If you try to connect as root and get this error:

  Access denied for user: '@unknown' to database mysql
  

  this means that you don't have an entry in the user table with the User column = root and that mysqld cannot resolve the hostname for your client. In this case, you must restart the server with the --skip-grant-tables option and edit your `/etc/hosts' or `\windows\hosts' file to add a entry for your host.
• If you updated an existing MySQL installation from a pre-3.22.11 version to version 3.22.11 or later, did you run the mysql_fix_privilege_tables script? If not, do so. The structure of the grant tables changed with MySQL 3.22.11 when the GRANT statement became functional.
• If you make changes to the grant tables directly (using INSERT or UPDATE statement) and your changes seem to be ignored, remember that you must issue a FLUSH PRIVILEGES statement or execute a mysqladmin flush-privileges command to cause the server to reread the tables. Otherwise your changes have no effect until the next time the server is restarted. Remember that after you set the root password, you won't need to specify it until after you flush the privileges, because the server still won't know you've changed the password yet!
• If your privileges seem to have changed in the middle of a session, it may be that a superuser has changed them. Reloading the grant tables affects new client connections, but it also affects existing connections as indicated in section 6.7 When privilege changes take effect.
• For testing, start the mysqld daemon with the --skip-grant-tables option. Then you can change the MySQL grant tables and use the mysqlaccess script to check whether or not your modifications have the desired effect. When you are satisfied with your changes, execute mysqladmin flush-privileges to tell the mysqld server to start using the new grant tables. Note: reloading the grant tables overrides the --skip-grant-tables option. This allows you to tell the server to begin using the grant tables again without bringing it down and restarting it.
• If you have access problems with a Perl, Python or ODBC program, try to connect to the server with mysql -u user_name db_name or mysql -u user_name -pyour_pass db_name. (Notice that there is no space between -p and the password; you can also use the --password=your_pass syntax to specify the password.) If you are able to connect using the mysql client, there is a problem with your program and not with the access privileges.
• If you can't get your password to work, remember that you must use the PASSWORD() function if you set the password with the INSERT, UPDATE or SET PASSWORD statements. The PASSWORD() function is unnecessary if you specify the password using the GRANT ... INDENTIFIED BY statement or the mysqladmin password command. See section 6.10 How to set up passwords.
• localhost is a synonym for your local hostname, and is also the default host to which clients try to connect if you specify no host explicitly. However, connections to localhost do not work if you are running on a system that uses MIT-pthreads (localhost connections are made using Unix sockets, which are not supported by MIT-pthreads). To avoid this problem on such systems, you should use the --host option to name the server host explicitly. This will make a TCP/IP connection to the mysqld server. In this case, you must have your real hostname in user table entries on the server host. (This is true even if you are running a client program on the same host as the server.)
• If you get an Access denied error when trying to connect to the database with mysql -u user_name db_name, you may have a problem with the user table. Check this by executing mysql -u root mysql and issuing this SQL statement:

  mysql> SELECT * FROM user;
  

  The result should include an entry with the Host and User columns matching your computer's hostname and your MySQL user name.
• The Access denied error message will tell you who you are trying to log in as, the host from which you are trying to connect, and whether or not you were using a password. Normally, you should have one entry in the user table that exactly matches the hostname and user name that were given in the error message.
• If you get the following error when you try to connect from another machine to the MySQL server, then there is no row in the user table that matches the host from which you are trying to connect:

  Host ... is not allowed to connect to this MySQL server
  

  You can fix this by using the command line tool mysql (on the server host!) to add a row to the user table for the user/hostname combination from which you are trying to connect. If you are not running MySQL 3.22 and you don't know the IP number or hostname of the machine from which you are connecting, you should put an entry with '%' as the Host column value in the user table and restart mysqld with the --log option on the server machine. After trying to connect from the client machine, the information in the MySQL log will indicate how you really did connect. (Then replace the '%' in the user table entry with the actual hostname that shows up in the log. Otherwise, you'll have a system that is insecure.)
• If mysql -u root test works but mysql -h your_hostname -u root test results in Access denied, then you may not have the correct name for your host in the user table. A common problem here is that the Host value in the user table entry specifies an unqualified hostname, but your system's name resolution routines return a fully-qualified domain name (or vice-versa). For example, if you have an entry with host 'tcx' in the user table, but your DNS tells MySQL that your hostname is 'tcx.subnet.se', the entry will not work. Try adding an entry to the user table that contains the IP number of your host as the Host column value. (Alternatively, you could add an entry to the user table with a Host value that contains a wildcard--for example, 'tcx.%'. However, use of hostnames ending with `%' is insecure and is not recommended!)
• If mysql -u user_name test works but mysql -u user_name other_db_name doesn't work, you don't have an entry for other_db_name listed in the db table.
• If mysql -u user_name db_name works when executed on the server machine, but mysql -u host_name -u user_name db_name doesn't work when executed on another client machine, you don't have the client machine listed in the user table or the db table.
• If you can't figure out why you get Access denied, remove from the user table all entries that have Host values containing wildcards (entries that contain `%' or `_'). A very common error is to insert a new entry with Host='%' and User='some user', thinking that this will allow you to specify localhost to connect from the same machine. The reason that this doesn't work is that the default privileges include an entry with Host='localhost' and User=". Since that entry has a Host value 'localhost' that is more specific than '%', it is used in preference to the new entry when connecting from localhost! The correct procedure is to insert a second entry with Host='localhost' and User='some_user', or to remove the entry with with Host='localhost' and User=".
• If you get the error:

  Access to database denied
  

  you may have a problem with the db or host table. If the entry selected from the db table has an empty value in the Host column, make sure there are one or more corresponding entries in the host table specifying to which hosts the db table entry applies.
• If you get the error:

  Access to database denied
  

  when using the SQL commands SELECT ... INTO OUTFILE or LOAD DATA INFILE, your entry in the user table probably doesn't have the file privilege enabled.
• If everything else fails, start the mysqld daemon with a debugging option (for example, --debug=d,general,query). This will print host and user information about attempted connections, as well as information about each command issued. See section 19.10 Debugging MySQL.
• If you have any other problems with the MySQL grant tables and feel you must post the problem to the mailing list, always provide a dump of the MySQL grant tables. You can dump the tables with the mysqldump mysql command. As always, post your problem using the mysqlbug script.
• If you get either of these errors, then either the mysqld daemon is not running or you are trying to connect to the wrong socket or port:

  Can't connect to local MySQL server
  Can't connect to MySQL server on some_hostname
  

  First see if the mysqld deamon is really running (with ps). Check after this that the socket file exists (normally `/tmp/mysql.sock') or try to connect to the port with telnet host_name 3306. You can also try mysqladmin version and mysqladmin -h host_name version to get some more information. Also, check the error logs in the MySQL data directory to see if they can provide some hints.
• Remember that client programs will use connection parameters specified in configuration files or environment variables. If a client seems to be sending the wrong default connection parameters when you don't specify them on the command line, check your environment and the `.my.cnf' file in your home directory. You might also check the system-wide MySQL configuration files, though it is far less likely that connection parameters will be specified there. If you get Access denied when you run a client without any options, make sure you haven't specified an old password in any of your option files! See section 4.14.4 Option files.

6.12 How to make MySQL secure against crackers

To make a MySQL system secure, you should strongly consider the following suggestions:

• Use passwords for all MySQL users. Remember that anyone can log in as any other person as simply as mysql -u other_user db_name if other_user has no password. This is common behavior with client/server applications. You can change the password of all users by editing the mysql_install_db script before you run it, or only the password for the MySQL root user like this:

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

• Don't start the MySQL daemon as the Unix root user. mysqld can be run as any user. You can also create a new Unix user mysql to make everything even more secure. If you run mysqld as another Unix user, you don't need to change the root user name in the user table, because MySQL user names have nothing to do with Unix user names. You can edit the mysql.server script to start mysqld as another Unix user. Normally this is done with the su command. For more details, see section 16.7 How to run MySQL as a normal user.
• Check that the user that mysqld runs as is the only Unix user with read/write privileges in the database directories.
• Don't give the process privilege to all users. The output of mysqladmin processlist shows the text of the currently executing queries, so any user who is allowed to execute that command might be able to see if another user issues an UPDATE user SET password=PASSWORD('not_secure') query. mysqld saves an extra connection for users who have the process privilege, so that a MySQL root user can log in and check things even if all normal connections are in use.
• Don't give the file privilege to all users. Any user that has this privilege can write a file anywhere in the file system with the privileges of the mysqld daemon! To make this a bit safer, all files generated with SELECT ... INTO OUTFILE are readable to everyone, and you can't overwrite existing files.
• If you don't trust your DNS, you should use IP numbers instead of hostnames in the grant tables. In principle, the --secure option to mysqld should make hostnames safe. In any case, you should be very careful about using hostname values that contain wildcards!
• If you put a password for the Unix root user in the mysql.server script, make sure this script is readable only by root.

The following mysqld options affect security:

--secure

IP numbers returned by the gethostbyname() system call are checked to make sure they resolve back to the original hostname. This makes it harder for someone on the outside to get access by simulating another host. This option also adds some sanity checks of hostnames. The option is turned off by default in MySQL 3.21 since it sometimes takes a long time to perform backward resolutions. MySQL 3.22 caches hostnames and has this option enabled by default.

--skip-grant-tables

This option causes the server not to use the privilege system at all. This gives everyone full access to all databases! (You can tell a running server to start using the grant tables again by executing mysqladmin reload.)

--skip-name-resolve

Hostnames are not resolved. All Host column values in the grant tables must be IP numbers or localhost.

--skip-networking

Don't allow TCP/IP connections over the network. All connections to mysqld must be made via Unix sockets. This option doesn't work very well on systems that use MIT-pthreads, because the MIT-pthreads package doesn't support Unix sockets.

7 MySQL language reference

7.1 Literals: how to write strings and numbers

7.1.1 Strings

A string is a sequence of characters, surrounded by either single quote (`'') or double quote (`"') characters. Examples:

'a string'
"another string"

Within a string, certain sequences have special meaning. Each of these sequences begins with a backslash (`\'), known as the escape character. MySQL recognizes the following escape sequences:

\0

An ASCII 0 (NUL) character.

\n

A newline character.

\t

A tab character.

\r

A carriage return character.

\b

A backspace character.

\'

A single quote (`'') character.

\"

A double quote (`"') character.

\\

A backslash (`\') character.

\%

A `%' character. This is used to search for literal instances of `%' in contexts where `%' would otherwise be interpreted as a wildcard character.

\_

A `_' character. This is used to search for literal instances of `_' in contexts where `_' would otherwise be interpreted as a wildcard character.

There are several ways to include quotes within a string:

• A `'' inside a string quoted with `'' may be written as `"'.
• A `"' inside a string quoted with `"' may be written as `""'.
• You can precede the quote character with an escape character (`\').
• A `'' inside a string quoted with `"' needs no special treatment and need not be doubled or escaped. In the same way, `"' inside a string quoted with `'' needs no special treatment.

The SELECT statements shown below demonstrate how quoting and escaping work:

mysql> SELECT 'hello', '"hello"', '""hello""', 'hel"lo', '\'hello';
+-------+---------+-----------+--------+--------+
| hello | "hello" | ""hello"" | hel'lo | 'hello |
+-------+---------+-----------+--------+--------+
| hello | "hello" | ""hello"" | hel'lo | 'hello |
+-------+---------+-----------+--------+--------+

mysql> SELECT "hello", "'hello'", ""hello"", "hel""lo", "\"hello";
+-------+---------+-----------+--------+--------+
| hello | 'hello' | "hello" | hel"lo | "hello |
+-------+---------+-----------+--------+--------+
| hello | 'hello' | "hello" | hel"lo | "hello |
+-------+---------+-----------+--------+--------+

mysql> SELECT "This\nIs\nFour\nlines";
+--------------------+
| This
Is
Four
lines |
+--------------------+
| This
Is
Four
lines |
+--------------------+

If you want to insert binary data into a BLOB column, the following characters must be represented by escape sequences:

NUL

ASCII 0. Should be represented by `\0' (a backslash and an ASCII `0' character).

\

ASCII 92, backslash

'

ASCII 39, single quote

"

ASCII 34, double quote

If you write C code, you can use the C API function mysql_escape_string() to escape characters for the INSERT clause. See section 18.3 C API function overview. In Perl, you can use the quote method of the DBI package to convert special characters to the proper escape sequences. See section 18.5.1.1 The DBI interface.

You should use an escape function on every possible string that may contain any of the special characters listed above!

7.1.2 Numbers

Integers are just a sequence of digits. Floats use `.' as a decimal separator.

Examples of valid numbers:

1221
294.42
-32032.6809e+10

7.1.3 NULL values

When using the text file export formats (SELECT ... INTO OUTFILE), NULL may be represented by \N. See section 7.15 LOAD DATA INFILE syntax.

Note that NULL means "no data" and is different from values such as 0 for numeric types and the empty string for string types. See section 16.12 Problems with NULL values.

7.1.4 Database, table, index, column and alias names

Database, table, index, column and alias names all follow the same rules in MySQL:

• A name consists of alphanumeric characters from the current character set and also `_' and `$'. The default character set is ISO-8859-1 Latin1; this may be changed by recompiling MySQL.
• A database, table, index or column name can have up to 64 characters. An alias name can have up to 256 characters.
• A name may start with any character that is legal in a name. In particular, a name may start with a number (which is different than many other systems!). However, a name cannot consist only of numbers.
• It is recommended that you do not use names like 1e, because an expression like 1e+1 is ambiguous. It may be interpreted as the expression 1e + 1 or as the number 1e+1.
• You cannot use the `.' character in names because it is used to extend the format by which you can refer to columns (see below).

In MySQL you can refer to a column using any of the following forms:

You need not specify a tbl_name or db_name.tbl_name prefix for a column reference in a statement unless the reference would be ambiguous. For example, suppose tables t1 and t2 each contain a column c, and you retrieve c in a SELECT statement that uses both t1 and t2. In this case, c is ambiguous because it is not unique among the tables used in the statement, so you must indicate which table you mean by writing t1.c or t2.c. Similarly, if you are retrieving from a table t in database db1 and from a table t in database db2, you must refer to columns in those tables as db1.t.col_name and db2.t.col_name.

The syntax .tbl_name means the table tbl_name in the current database. This syntax is accepted because some ODBC prefix table names with a `.' character.

7.1.4.1 Case sensitivity in names

Database and table names are case sensitive in Unix and case insensitive in Win32, because directory and file names are case sensitive in Unix but not in Win32. (In MySQL, databases and tables correspond to directories and files within those directories, so the case sensitivity of the underlying operating system determines how MySQL behaves.)

Note: although database and file names are case insensitive for Win32, you should not refer to a given database or table using different cases within the same query.

Column names are case insensitive in all cases.

Aliases on tables are case sensitive and aliases on columns are case insensitive.

7.2 Column types

MySQL supports a number of column types, which may be grouped into three categories: numeric types, date and time types, and string (or character) types. This section first gives an overview of the types available, then summarizes the storage requirements for each column type and provides a more detailed description of the properties of the types in each category. The overview is intentionally brief. The more detailed descriptions should be consulted for additional information about particular column types, such as the allowable formats in which you can specify values.

The column types supported by MySQL are listed below. The following code letters are used in the descriptions:

• M indicates the maximum display size.
• D applies to floating-point types and indicates the number of digits following the decimal point.

Square brackets (`[' and `]') indicate parts of type specifiers that are optional.

TINYINT[(M)] [UNSIGNED] [ZEROFILL]

A very small integer. The signed range is -128 to 127. The unsigned range is 0 to 255.

SMALLINT[(M)] [UNSIGNED] [ZEROFILL]

A small integer. The signed range is -32768 to 32767. The unsigned range is 0 to 65535.

MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL]

A medium-size integer. The signed range is -8388608 to 8388607. The unsigned range is 0 to 16777215.

INT[(M)] [UNSIGNED] [ZEROFILL]

A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.

INTEGER[(M)] [UNSIGNED] [ZEROFILL]

This is a synonym for INT.

BIGINT[(M)] [UNSIGNED] [ZEROFILL]

A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615. Note that all arithmetic is done using signed BIGINT or DOUBLE values, so you shouldn't use unsigned big integers larger than 9223372036854775807 (63 bits) except with bit functions! Note that -, + and * will use BIGINT arithmetic when both arguments are INTEGER values! This means that if you multiply two big integers (or results from functions that return integers) you may get unexpected results if the result is bigger than 9223372036854775807.

FLOAT(precision) [ZEROFILL]

A floating-point number. Cannot be unsigned. precision can be 4 or 8. FLOAT(4) is a single-precision number and FLOAT(8) is a double-precision number. These types are like the FLOAT and DOUBLE types described immediately below. FLOAT(4) and FLOAT(8) have the same ranges as the corresponding FLOAT and DOUBLE types, but their display size and number of decimals is undefined. This syntax is provided for ODBC compatibility.

FLOAT[(M,D)] [ZEROFILL]

A small (single-precision) floating-point number. Cannot be unsigned. Allowable values are -3.402823466E+38 to -1.175494351E-38, 0 and -1.175494351E-38 to 3.402823466E+38.

DOUBLE[(M,D)] [ZEROFILL]

A normal-size (double-precision) floating-point number. Cannot be unsigned. Allowable values are -1.7976931348623157E+308 to -2.2250738585072014E-308, 0 and 2.2250738585072014E-308 to 1.7976931348623157E+308.

DOUBLE PRECISION[(M,D)] [ZEROFILL]

REAL[(M,D)] [ZEROFILL]

These are synonyms for DOUBLE.

DECIMAL(M,D) [ZEROFILL]

An unpacked floating-point number. Cannot be unsigned. Behaves like a CHAR column (`unpacked' means the number is stored as a string, using one character for each digit of the value, the decimal point, and, for negative numbers, the `-' sign). If D is 0, values will have no decimal point or fractional part. The maximum range of DECIMAL values is the same as for DOUBLE, but the actual range for a given DECIMAL column may be constrained by the choice of M and D.

NUMERIC(M,D) [ZEROFILL]

This is a synonym for DECIMAL.

DATE

A date. The supported range is '1000-01-01' to '9999-12-31'. MySQL displays DATE values in 'YYYY-MM-DD' format, but allows you to assign values to DATE columns using either strings or numbers.

DATETIME

A date and time combination. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. MySQL displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format, but allows you to assign values to DATETIME columns using either strings or numbers.

TIMESTAMP[(M)]

A timestamp. The range is '1970-01-01 00:00:00' to sometime in the year 2106. MySQL displays TIMESTAMP values in YYYYMMDDHHMMSS, YYMMDDHHMMSS, YYYYMMDD or YYMMDD format, depending on whether M is 14 (or missing), 12, 8 or 6, but allows you to assign values to TIMESTAMP columns using either strings or numbers. A TIMESTAMP column is useful for recording the time of an INSERT or UPDATE operation because it is automatically set to the time of the last operation. You can also set it to the current time by giving it a NULL value. See section 7.2.6 Date and time types.

TIME

A time. The range is '-838:59:59' to '838:59:59'. MySQL displays TIME values in 'HH:MM:SS' format, but allows you to assign values to TIME columns using either strings or numbers.

YEAR

A year. The allowable values are 1901 to 2155, and 0000. MySQL displays YEAR values in YYYY format, but allows you to assign values to YEAR columns using either strings or numbers. (YEAR is a new type for MySQL 3.22.)

CHAR(M) [BINARY]

A fixed-length string that is always right-padded with spaces to the specified length when stored. The range of M is 1 to 255 characters. Trailing spaces are removed when the value is retrieved. CHAR values are sorted and compared in case-insensitive fashion unless the BINARY keyword is given.

VARCHAR(M) [BINARY]

A variable-length string. NOTE: Trailing spaces are removed when the value is stored (this differs from the ANSI SQL specification). The range of M is 1 to 255 characters. VARCHAR values are sorted and compared in case-insensitive fashion unless the BINARY keyword is given.

TINYBLOB

TINYTEXT

A BLOB or TEXT column with a maximum length of 255 (2^8 - 1) characters.

BLOB

TEXT

A BLOB or TEXT column with a maximum length of 65535 (2^16 - 1) characters.

MEDIUMBLOB

MEDIUMTEXT

A BLOB or TEXT column with a maximum length of 16777215 (2^24 - 1) characters.

LONGBLOB

LONGTEXT

A BLOB or TEXT column with a maximum length of 4294967295 (2^32 - 1) characters.

ENUM('value1','value2',...)

An enumeration. A string object that can have only one value, chosen from the list of values 'value1', 'value2',... (or NULL). An ENUM can have a maxiumum of 65535 distinct values.

SET('value1','value2',...)

A set. A string object that can have zero or more values, each of which must be chosen from the list of values 'value1', 'value2',... A SET can have a maximum of 64 members.

7.2.1 Column type storage requirements

The storage requirements for each of the column types supported by MySQL are listed below by category.

7.2.2 Numeric types

7.2.3 Date and time types

7.2.4 String types

VARCHAR and the BLOB and TEXT types are variable-length types, for which the storage requirements depend on the actual length of column values (represented by L in the preceding table), rather than on the type's maximum possible size. For example, a VARCHAR(10) column can hold a string with a maximum length of 10 characters. The actual storage required is the length of the string (L), plus 1 byte to record the length of the string. For the string 'abcd', L is 4 and the storage requirement is 5 bytes.

The BLOB and TEXT types require 1, 2, 3 or 4 bytes to record the length of the column value, depending on the maxiumum possible length of the type.

If a table includes any variable-length column types, the record format will also be variable-length. Note that when a table is created, MySQL may under certain conditions change a column from a variable-length type to a fixed-length type, and vice-versa. See section 7.6 CREATE TABLE syntax.

The size of an ENUM object is determined by the number of different enumeration values. 1 byte is used for enumerations with up to 255 possible values. 2 bytes are used for enumerations with up to 65535 values.

The size of a SET object is determined by the number of different set members. If the set size is N, the object occupies (N+7)/8 bytes, rounded up to 1, 2, 3, 4 or 8 bytes. A SET can have a maximum of 64 members.

7.2.5 Numeric types

All integer types can have an optional attribute UNSIGNED. Unsigned values can be used when you want to allow only positive numbers in a column and you need a little bigger numeric range for the column.

All numeric types can have an optional attribute ZEROFILL. Values for ZEROFILL columns are left-padded with zeroes up to the maximum display length when they are displayed. For example, for a column declared as INT(5) ZEROFILL, a value of 4 is retrieved as 00004.

When asked to store a value in a numeric column that is outside the column type's allowable range, MySQL clips the value to the appropriate endpoint of the range and stores the resulting value instead.

For example, the range of an INT column is -2147483648 to 2147483647. If you try to insert -9999999999 into an INT column, the value is clipped to the lower endpoint of the range, and -2147483648 is stored instead. Similarly, if you try to insert 9999999999, 2147483647 is stored instead.

If the INT column is UNSIGNED, the size of the column's range is the same but its endpoints shift up to 0 and 4294967295. If you try to store -9999999999 and 9999999999, the values stored in the column become 0 and 4294967296.

Conversions that occur due to clipping are reported as `warnings' for ALTER TABLE, LOAD DATA INFILE, UPDATE and multi-row INSERT statements.

The maximum display size (M) and number of decimals (D) are used for formatting and calculation of maximum column width.

MySQL will store any value that fits a column's storage type even if the value exceeds the display size. For example, an INT(4) column has a display size of 4. Suppose you insert a value which has more than 4 digits into the column, such as 12345. The display size is exceeded, but the allowable range of the INT type is not, so MySQL stores the actual value, 12345. When retrieving the value from the column, MySQL returns the actual value stored in the column.

The DECIMAL type is considered a numeric type (as is its synonym, NUMERIC), but such values are stored as strings. One character is used for each digit of the value, the decimal point (if D > 0) and the `-' sign (for negative numbers). If D is 0, DECIMAL and NUMERIC values contain no decimal point or fractional part.

The maximum range of DECIMAL values is the same as for DOUBLE, but the actual range for a given DECIMAL column may be constrained by the choice of M and D. For example, a type specification such as DECIMAL(4,2) indicates a maximum length of four characters with two digits after the decimal point. Due to the way the DECIMAL type is stored, this specification results in an allowable range of -.99 to 9.99, much less than the range of a DOUBLE.

To avoid some rounding problems, MySQL always rounds everything that it stores in any floating-point column according to the number of decimals. Suppose you have a column type of FLOAT(8,2). The number of decimals is 2, so a value such as 2.333 is rounded to two decimals and stored as 2.33.

7.2.6 Date and time types

The date and time types are DATETIME, DATE, TIMESTAMP, TIME and YEAR. Each of these has a range of legal values, as well as a `zero' value that is used when you specify an illegal value.

Here are some general considerations to keep in mind when working with date and time types:

• MySQL retrieves values for a given date or time type in a standard format, but it attempts to interpret a variety of formats for values that you supply (e.g., when you specify a value to be assigned to or compared to a date or time type). Nevertheless, only the formats described in the following sections are supported. It is expected that you will supply legal values, and unpredictable results may occur if you use values in other formats.
• Although MySQL tries to interpret values in several formats, it always expects the year part of date values to be leftmost. Dates must be given in year-month-day order (e.g., '98-09-04'), rather than in the month-day-year or day-month-year orders commonly used elsewhere (e.g., '09-04-98', '04-09-98').
• MySQL automatically converts a date or time type value to a number if the value is used in a numeric context, and vice versa.
• When MySQL encounters a value for a date or time type that is out of range or otherwise illegal for the type, it converts the value to the `zero' value for that type. (The exception is that out-of-range TIME values are clipped to the appropriate endpoint of the TIME range.) The table below shows the format of the `zero' value for each type:

  Column type	`Zero' value
  DATETIME	'0000-00-00 00:00:00'
  DATE	'0000-00-00'
  TIMESTAMP	00000000000000 (length depends on display size)
  TIME	'00:00:00'
  YEAR	0000

• The `zero' values are special, but you can store or refer to them explicitly using the values shown in the table. You can also do this using the values '0' or 0, which are easier to write.
• `Zero' date or time values used through MyODBC are converted automatically to NULL in MyODBC 2.50.12 and above, because ODBC can't handle such values.

7.2.6.1 The DATETIME, DATE and TIMESTAMP types

The DATETIME, DATE and TIMESTAMP types are related. This section describes how they are similar and how they differ.

The DATETIME type is used when you need values that contain both date and time information. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. ("Supported" means that although earlier values might work, they are not guaranteed to.)

The DATE type is used when you need only a date value, without a time part. MySQL retrieves and displays DATE values in 'YYYY-MM-DD' format. The supported range is '1000-01-01' to '9999-12-31'.

The TIMESTAMP column type provides a type that you can use to automatically mark INSERT or UPDATE operations with the current time. (`Current time' means `current date and time' in TIMESTAMP contexts.) A TIMESTAMP column is updated automatically under either of the following conditions:

• The column is not specified explicitly in an INSERT or LOAD DATA INFILE statement.
• The column is not specified explicitly in an UPDATE statement and some other column changes value. (Note that an UPDATE that sets a column to the value it already has will not cause the TIMESTAMP column to be updated, because if you set a column to its current value, MySQL ignores the update for efficiency.)
• You explicitly set the TIMESTAMP column to NULL.

If you have multiple TIMESTAMP columns, only the first one is updated automatically. However, you can set any TIMESTAMP column to the current time by setting it to NULL (or by setting it to NOW(), obviously).

TIMESTAMP values may range from the beginning of 1970 to sometime in the year 2106, with a resolution of one second. Values are displayed as numbers.

The format in which MySQL retrieves and displays TIMESTAMP values depends on the display size, as illustrated by the table below. The `full' TIMESTAMP format is 14 digits, but TIMESTAMP columns may be created with shorter display sizes:

All TIMESTAMP columns have the same storage size, regardless of display size. The most common display sizes are 6, 8, 12, and 14. (You can specify an arbitrary display size at table creation time, but values of 0 or greater than 14 are coerced to 14. Odd-valued sizes in the range from 1 to 13 are coerced to the next higher even number.)

You can specify DATETIME, DATE and TIMESTAMP values using any of a common set of formats:

• As a string in either 'YYYY-MM-DD HH:MM:SS' or 'YY-MM-DD HH:MM:SS' format. A `relaxed' syntax is allowed--any non-numeric character may be used as the delimiter between date parts or time parts. For example, '98-12-31 11:30:45', '98.12.31 11+30+45', '98/12/31 11*30*45' and '98@12@31 11^30^45' are equivalent.
• As a string in either 'YYYY-MM-DD' or 'YY-MM-DD' format. A `relaxed' syntax is allowed here, too. For example, '98-12-31', '98.12.31', '98/12/31' and '98@12@31' are equivalent.
• As a string with no delimiters in either 'YYYYMMDDHHMMSS' or 'YYMMDDHHMMSS' format, provided that the string makes sense as a date. For example, '19970523091528' and '970523091528' are interpreted as '1997-05-23 09:15:28', but '971122459015' is illegal (it has a nonsensical minute part) and becomes '0000-00-00 00:00:00'.
• As a string with no delimiters in either 'YYYYMMDD' or 'YYMMDD' format, provided that the string makes sense as a date. For example, '19970523' and '970523' are interpreted as '1997-05-23', but '971332' is illegal (it has nonsensical month and day parts) and becomes '0000-00-00'.
• As a number in either YYYYMMDDHHMMSS or YYMMDDHHMMSS format, provided that the number makes sense as a date. For example, 19830905132800 and 830905132800 are interpreted as '1983-09-05 13:28:00'.
• As a number in either YYYYMMDD or YYMMDD format, provided that the number makes sense as a date. For example, 19830905 and 830905 are interpreted as '1983-09-05'.
• As the result of a function that returns a value that is acceptable in a DATETIME, DATE or TIMESTAMP context, such as NOW() or CURRENT_DATE.

For values specified as strings that include date part delimiters, it is not necessary to specify two digits for month or day values that are less than 10. '1979-6-9' is the same as '1979-06-09'. Similarly, for values specified as strings that include time part delimiters, it is not necessary to specify two digits for hour, month or second values that are less than 10. '1979-10-30 1:2:3' is the same as '1979-10-30 01:02:03'.

Values specified as numbers should be 6, 8, 12 or 14 digits long. If the number is 8 or 14 digits long, it is assumed to be in YYYYMMDD or YYYYMMDDHHMMSS format and that the year is given by the first 4 digits. If the number is 6 or 12 digits long, it is assumed to be in YYMMDD or YYMMDDHHMMSS format and that the year is given by the first 2 digits. Numbers that are not one of these lengths are interpreted as though padded with leading zeros to the closest length.

Values specified as non-delimited strings are interpreted using their length as given. If the string is 8 or 14 characters long, the year is assumed to be given by the first 4 characters. Otherwise the year is assumed to be given by the first 2 characters. The string is interpreted from left to right to find year, month, day, hour, minute and second values, for as many parts as are present in the string.

Year values specified as two digits are ambiguous, since the century is unknown. MySQL interprets 2-digit year values using the following rules:

• Year values in the range 00-69 are converted to 2000-2069.
• Year values in the range 70-99 are converted to 1970-1999.

You can to some extent assign values of one date type to an object of a different date type. However, there may be some alteration of the value or loss of information:

• If you assign a DATE value to a DATETIME or TIMESTAMP object, the time part of the resulting value is set to '00:00:00', because the DATE value contains no time information.
• If you assign a DATETIME or TIMESTAMP value to a DATE object, the time part of the resulting value is deleted, because the DATE type stores no time information.

TIMESTAMP values are stored to full precision regardless of the display size. However, the only function that operates directly on the underlying stored value is UNIX_TIMESTAMP(). Other functions operate on the formatted retrieved value. This means you cannot use functions such as HOUR() or SECOND() unless the relevant part of the TIMESTAMP value is included in the formatted value. For example, the HH part of a TIMESTAMP column is not displayed unless the display size is at least 10, so trying to use HOUR() on shorter TIMESTAMP values produces a meaningless result.

Illegal DATETIME, DATE or TIMESTAMP values are converted the `zero' value of the appropriate type ('0000-00-00 00:00:00', '0000-00-00' or 00000000000000).

Be aware of certain pitfalls when specifying date values:

• The relaxed format allowed for values specified as strings can be deceiving. For example, a value such as '10:11:12' might look like a time value because of the `:' delimiter, but if used in a date context will be interpreted as the year '2010-11-12'. The value '10:45:15' will be converted to '0000-00-00' because '45' is not a legal month.
• Remember that although DATETIME, DATE and TIMESTAMP values all can be specified using the same set of formats, the types do not all have the same range of values. For example, TIMESTAMP values cannot be earlier than 1970 or later than 2036. For example, '1968-01-01', while legal as a DATETIME or DATE value, is not a valid TIMESTAMP value and will be converted to 0 if assigned to such an object.

7.2.6.2 The TIME type

MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or 'HHH:MM:SS' format for large hours values). TIME values may range from '-838:59:59' to '838:59:59'. The reason the hours part may be so large is that the TIME type may be used not only to represent a time of day (which must be less than 24 hours), but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative).

You can specify TIME values in a variety of formats:

• As a string in 'HH:MM:SS' format. A `relaxed' syntax is allowed--any non-numeric character may be used as the delimiter between time parts. For example, '10:11:12' and '10.11.12' are equivalent.
• As a string with no delimiters in 'HHMMSS' format, provided that it makes sense as a time. Example: '101112' is understood as '10:11:12', but '109712' is illegal (it has a nonsensical minute part) and becomes '00:00:00'.
• As a number in HHMMSS format, provided that it makes sense as a time. Example: 101112 is understood as '10:11:12'.
• As the result of a function that returns a value that is acceptable in a TIME context, such as CURRENT_TIME.

For TIME values specified as strings that include a time part delimiter, it is not necessary to specify two digits for hours, minutes or seconds values that are less than 10. '8:3:2' is the same as '08:03:02'.

If you assign a `short' TIME value to a TIME column, MySQL interprets the value as specifying seconds, or minutes and seconds. For example, '12' and 12 are interpreted as '00:00:12', whereas '11:12', '1112' and 1112 are interpreted as '00:11:12'.

Values that lie outside the TIME range but are otherwise legal are clipped to the appropriate endpoint of the range. For example, '-850:00:00' and '850:00:00' are converted to '-838:59:59' and '838:59:59'.

Illegal TIME values are converted to '00:00:00'. Note that since '00:00:00' is itself a legal TIME value, there is no way to distinguish a value of '00:00:00' that was specified explicitly from one that resulted from an illegal value.

7.2.6.3 The YEAR type

The YEAR type is a 1-byte type used for representing years.

MySQL retrieves and displays YEAR values in YYYY format. The range is 1901 to 2155.

You can specify YEAR values in a variety of formats:

• As a four-digit string in the range '1901' to '2155'.
• As a four-digit number in the range 1901 to 2155.
• As a two-digit string in the range '00' to '99'. Values in the ranges '00' to '69' and '70' to '99' are converted to YEAR values in the ranges 2000 to 2069 and 1970 to 1999, and are sorted as such.
• As a two-digit number in the range 1 to 99. Values in the ranges 1 to 69 and 70 to 99 are converted to YEAR values in the ranges 2001 to 2069 and 1970 to 1999, and are sorted as such. Note that the range for two-digit numbers is slightly different than the range for two-digit strings, since you cannot specify zero directly as a number and have it be interpreted as 2000. You must specify it as a string '0' or '00' or it will be interpreted as 0000.
• As the result of a function that returns a value that is acceptable in a YEAR context, such as NOW().

Illegal YEAR values are converted to 0000.

7.2.7 String types

The string types are CHAR, VARCHAR, BLOB, TEXT, ENUM and SET.

7.2.7.1 The CHAR and VARCHAR types

The CHAR and VARCHAR types are similar, but differ in the way they are stored and retrieved.

The length of a CHAR column is fixed to the length that you declare it when you create the table. You can declare it to be any length between 1 and 255; when values are stored, they are right-padded with spaces to the specified length. When CHAR values are retrieved, trailing spaces are removed.

Values in VARCHAR columns are variable-length strings. You can declare a VARCHAR to be any length between 1 and 255 as well. This length is the maximum length, but in contrast to CHAR, values are stored using only as many characters as are needed. Values are not padded; instead, trailing spaces are removed when values are stored. (This space removal differs from the ANSI SQL specification.)

If you assign a value to a CHAR or VARCHAR column that exceeds the column's maximum length, the value is truncated to fit.

To illustrate the differences between the two types of columns, the table below shows the result of storing various string values into CHAR(4) and VARCHAR(4) columns:

The values retrieved from the CHAR(4) and VARCHAR(4) columns will be the same in each case, because trailing spaces are removed from CHAR columns upon retrieval.

Values in CHAR and VARCHAR columns are sorted and compared in case-insensitive fashion, unless the BINARY attribute was specified when the table was created. The BINARY attribute means that column values are sorted and compared in case-sensitive fashion according to the ASCII order of the machine where the MySQL server is running.

The BINARY attribute is "sticky". This means that if a column marked BINARY is used in an expression, the whole expression is compared as a BINARY value.

MySQL may silently change the type of a CHAR or VARCHAR column at table creation time. See section 7.6 CREATE TABLE syntax.

7.2.7.2 The BLOB and TEXT types

A BLOB is a binary large object that can hold a variable amount of data. The four BLOB types TINYBLOB, BLOB, MEDIUMBLOB and LONGBLOB differ only in the maximum length of the values they can hold.

The four TEXT types TINYTEXT, TEXT, MEDIUMTEXT and LONGTEXT correspond to the four BLOB types and have the same maximum lengths and storage requirements. The only difference between BLOB and TEXT types is that sorting and comparison is performed in case-sensitive fashion for BLOB values and case-insensitive fashion for TEXT values. In other words, a TEXT is a case-insensitive BLOB.

BLOB and TEXT columns cannot be indexed, unlike all other MySQL column types.

If you assign a value to a BLOB or TEXT column that exceeds the column type's maximum length, the value is truncated to fit.

There is no trailing space truncation for BLOB and TEXT columns as there is for VARCHAR columns.

In most respects, you can regard a TEXT column as a VARCHAR column that can be as big as you like. Similarly, you can regard a BLOB column as a VARCHAR BINARY column. The differences are that you cannot index BLOB or TEXT columns, and there is no trailing-space removal for BLOB and TEXT columns when values are stored. BLOB and TEXT can not have DEFAULT values and will also always be NULL columns.

MyODBC defines BLOB values as LONGVARBINARY and TEXT values as LONGVARCHAR.

Because BLOB and TEXT values may be extremely long, you may run up against some contraints when using them:

• When you sort or group BLOB or TEXT values, only the first max_sort_length bytes of the column are used. The default value of max_sort_length is 1024; this value can be changed by the -O option when starting the mysqld daemon. You can group on an expression involving BLOB or TEXT values:

  mysql> SELECT id,substr(blob_col,1,100) GROUP BY 2;
  

• The maximum size of a BLOB or TEXT object is determined by its type, but the largest value you can actually transmit between the client and server is determined by the amount of available memory and the size of the communications buffers. You can change the message buffer size, but you must do so on both the server and client ends. See section 10.1 Changing the size of MySQL buffers.

Note that each BLOB/TEXT column is represented internally by a unique alloced object. This is in contrast to all other column types that are alloced once when the table is opened.

7.2.7.3 The ENUM type

An ENUM (enumeration) is a string object that can have only one value, chosen from a list of allowed values, or NULL. For example, a column specified as ENUM("one", "two", "three") can have any of these values:

NULL
"one"
"two"
"three"

An enumeration can have a maximum of 65535 elements.

When you assign a value to an ENUM column, the case of the value to be stored does not matter; the stored value is converted to the case that was used to specify the ENUM column when the table was created.

If you retrieve an ENUM in a numeric context, the column value's index is returned. If you store a number into an ENUM, the value stored is the enumeration member whose index is that number. Enumeration values are indexed beginning with 1 (0 is reserved for incorrect enumeration values).

Sorting of ENUM values is done according to the order in which the enumeration members were listed in the column specification. For example, "a" sorts before "b" for ENUM("a", "b"), but "a" sorts after "b" for ENUM("b", "a"). NULL values sort before other enumeration values.

If an ENUM is declared NOT NULL, the default value is the first value, otherwise the default value is NULL.

7.2.7.4 The SET type

A SET is a string object that can have zero or more values, each of which must be chosen from a list of allowed values. SET column values that are composed of multiple set members are specified with members separated by commas (`,'). For example, a column specified as SET("one", "two") NOT NULL can have any of these values:

""
"one"
"two"
"one,two"

A SET can have a maximum of 64 different members.

MySQL stores SET values numerically, with the low-order bit of the stored value corresponding to the first set member. If you retrieve a set value into a numeric context, the value retrieved has the bit (or bits) set corresponding to the set member (or members) that make up the column value. If a number is stored into a SET column, the bit (or bits) that are set in the number determine the set member (or members) in the column value. Sorting of SET values is done numerically. NULL values sort before other set members.

Normally, you perform a SELECT on a SET column using LIKE or FIND_IN_SET():

mysql> SELECT * FROM tbl_name WHERE set_col LIKE '%value%';
mysql> SELECT * FROM tbl_name WHERE FIND_IN_SET('value',set_col)>0;

But the following will also work:

mysql> SELECT * FROM tbl_name WHERE set_col = 'val1,val2'; # Exact match
mysql> SELECT * FROM tbl_name WHERE set_col & 1;           # Is in first group

7.2.8 Choosing the right type for a column

Try to use the most precise type in all cases. For example, if an integer column will be used for values in the range between 1 and 99999, MEDIUMINT UNSIGNED is the best type.

Accurate representation of monetary values is a common problem. In MySQL you should use the DECIMAL type. This is stored as a string, so no loss of accuracy should occur. If accuracy is not too important, the DOUBLE type may also be good enough.

For high precision, you can always convert to a fixed-point type stored in a BIGINT. This allows you to do all calculations with integers and convert results back to floating-point values only when necessary.

See section 10.14 What are the different row formats? Or, when should VARCHAR/CHAR be used?.

7.2.9 Column indexes

All MySQL column types can be indexed except BLOB and TEXT types. Use of indexes on the relevant columns is the best way to improve the performance of SELECT operations.

A table may have up to 16 indexes. The maximum index length is 256 bytes, although this may be changed when compiling MySQL.

For CHAR and VARCHAR columns, you can index a prefix of a column. This is much faster and requires less disk space than indexing the whole column.

The syntax to use in the CREATE TABLE statement to index a column prefix looks like this:

KEY index_name (col_name(length))

The example below creates an index for the first 10 characters of the name column:

mysql> CREATE TABLE test (
           name CHAR(200) NOT NULL,
           KEY index_name (name(10)));

7.2.10 Multiple-column indexes

MySQL can create indexes from multiple columns.

A multiple-column index can be considered a sorted array where the values of the indexed columns are concatenated.

MySQL uses multiple-column indexes in such a way that queries are fast when you specify a known quantity for the first column of the index in a WHERE clause, even if you don't specify values for the other columns.

An index may consist up up to 15 columns (or column prefixes, for CHAR and VARCHAR columns).

Suppose you have a table that has the following specification:

mysql> CREATE TABLE test (
           id INT NOT NULL,
           last_name CHAR(30) NOT NULL,
           first_name CHAR(30) NOT NULL,
           PRIMARY KEY (id),
           INDEX name (last_name,first_name));

Then the index name is an index over last_name and first_name. The index will be used for queries that specify values in a known range for last_name, or for both last_name and first_name. Therefore, the name index will be used in the following queries:

mysql> SELECT * FROM test WHERE last_name="Widenius";

mysql> SELECT * FROM test WHERE last_name="Widenius"
                          AND first_name="Michael";

mysql> SELECT * FROM test WHERE last_name="Widenius"
                          AND (first_name="Michael" OR first_name="Monty");

mysql> SELECT * FROM test WHERE last_name="Widenius"
                          AND first_name >="M" AND first_name < "N";

However, the name index will NOT be used in the following queries:

mysql> SELECT * FROM test WHERE first_name="Michael";

mysql> SELECT * FROM test WHERE last_name="Widenius" or first_name="Michael";

For more information on the manner in which MySQL uses indexes to improve query performance, see section 10.4 How MySQL uses indexes.

7.2.11 Using column types from other database engines

To make it easier to use code written for SQL implementations from other vendors, MySQL supports the column type mappings shown in the table below. These mappings make it easier to move table definitions from other database engines to MySQL:

Column type mapping occurs at table creation time, so if you create a table with types used by other vendors and then issue a DESCRIBE tbl_name statement, MySQL reports the table structure using the equivalent MySQL types.

7.3 Functions for use in SELECT and WHERE clauses

A select_expression or where_definition can consist of any expression using the functions described below.

An expression that contains NULL always produces a NULL value unless otherwise indicated in the documentation for the operators and functions involved in the expression.

Note: there must be no whitespace between a function name and the parenthesis following it. This helps the MySQL parser distinguish between function calls and references to tables or columns that happen to have the same name as a function.

For the sake of brevity, the examples shown below display the output from the mysql program in abbreviated form. So this:

mysql> select MOD(29,9);
1 rows in set (0.00 sec)

+-----------+
| mod(29,9) |
+-----------+
|         2 |
+-----------+

Is displayed like this:

mysql> select MOD(29,9);
        -> 2

7.3.1 Grouping functions

( ... )

Parentheses. Use these to force the order of evaluation in an expression.

mysql> select 1+2*3;
        -> 7
mysql> select (1+2)*3;
        -> 9

7.3.2 Normal arithmetic operations

Note that in the case of -, + and *, the result is calculated with BIGINT precision if both arguments are integers!

+

Addition

mysql> select 3+5;
        -> 8

-

Subtraction

mysql> select 3-5;
        -> -2

*

Multiplication

mysql> select 3*5;
        -> 15
mysql> select 18014398509481984*18014398509481984.0;
        -> 324518553658426726783156020576256.0
mysql> select 18014398509481984*18014398509481984;
        -> 0

The result of the last expression is incorrect because the result of the integer multiplication is over the 64-bit range.

/

Division. A division by zero produces a NULL result.

mysql> select 3/5;
        -> 0.60
mysql> select 102/(1-1);
        -> NULL

A division will be calculated with BIGINT arithmetic only if it's used in a context where its result is converted to an integer!

7.3.3 Bit functions

These have a maximum range of 64 bits because MySQL uses BIGINT (64-bit) arithmetic for bit operations.

|

Bitwise OR

mysql> select 29 | 15;
        -> 31

&

Bitwise AND

mysql> select 29 & 15;
        -> 13

<<

Shifts a longlong number to the left.

mysql> select 1 << 2
        -> 4

>>

Shifts a longlong number to the right.

mysql> select 4 >> 2
        -> 1

BIT_COUNT(N)

Returns the number of bits that are set in the argument N.

mysql> select BIT_COUNT(29);
        -> 4

7.3.4 Logical operations

All logical functions return 1 (TRUE) or 0 (FALSE).

NOT

!

Logical NOT. Returns 1 if the argument is 0, otherwise returns 0. Exception: NOT NULL returns NULL.

mysql> select NOT 1;
        -> 0
mysql> select NOT NULL;
        -> NULL
mysql> select ! (1+1);
        -> 0
mysql> select ! 1+1;
        -> 1

The last example returns 1 because the expression evaluates the same way as (!1)+1.

OR

||

Logical OR. Returns 1 if either argument is not 0 and not NULL.

mysql> select 1 || 0;
        -> 1
mysql> select 0 || 0;
        -> 0
mysql> select 1 || NULL;
        -> 1

AND

&&

Logical AND. Returns 0 if either argument is 0 or NULL, otherwise returns 1.

mysql> select 1 && NULL;
        -> 0
mysql> select 1 && 0;
        -> 0

7.3.5 Comparison operators

Comparison operations result in a value of 1 (TRUE), 0 (FALSE) or NULL. These functions work for both numbers and strings. Strings are automatically converted to numbers and numbers to strings as needed (as in Perl).

MySQL performs comparisons using the following rules:

• If one or both arguments are NULL, the result of the comparison is NULL.
• If both arguments in a comparison operation are strings, they are compared as strings.
• If both arguments are integers, they are compared as integers.
• If one of the arguments is a TIMESTAMP or DATETIME column and the other argument is a constant, the constant is converted to a timestamp before the comparison is performed. This is done to be more ODBC-friendly.
• In all other cases, the arguments are compared as floating-point (real) numbers.

By default, string comparisons are done in case-independent fashion using the current character set (ISO-8859-1 Latin1 by default, which also works excellently for English).

The examples below illustrate conversion of strings to numbers for comparison operations:

mysql> SELECT 1 > '6x';
         -> 0
mysql> SELECT 7 > '6x';
         -> 1
mysql> SELECT 0 > 'x6';
         -> 0
mysql> SELECT 0 = 'x6';
         -> 1

=

Equal

mysql> select 1 = 0;
        -> 0
mysql> select '0' = 0;
        -> 1
mysql> select '0.0' = 0;
        -> 1
mysql> select '0.01' = 0;
        -> 0
mysql> select '.01' = 0.01;
        -> 1

<>

!=

Not equal

mysql> select '.01' <> '0.01';
        -> 1
mysql> select .01 <> '0.01';
        -> 0
mysql> select 'zapp' <> 'zappp';
        -> 1

<=

Less than or equal

mysql> select 0.1 <= 2;
        -> 1

<

Less than

mysql> select 2 <= 2;
        -> 1

>=

Greater than or equal

mysql> select 2 >= 2;
        -> 1

>

Greater than

mysql> select 2 > 2;
        -> 0

ISNULL(expr)

If expr is NULL, returns 1, otherwise returns 0.

mysql> select ISNULL(1+1);
        -> 0
mysql> select ISNULL(1/0);
        -> 1

expr BETWEEN min AND max

If expr is greater than or equal to min and expr is less than or equal to max, returns 1, otherwise returns 0. Does the same thing as the expression (min <= expr AND expr <= max) if all the arguments are of the same type. The first argument (expr) determines how the comparison is performed. If expr is a string expression, a case-insensitive string comparison is done. If expr is a binary string, a case-sensitive string comparison is done. If expr is an integer expression, an integer comparison is done. Otherwise, a floating-point (real) comparison is done.

mysql> select 1 BETWEEN 2 AND 3;
        -> 0
mysql> select 'b' BETWEEN 'a' AND 'c';
        -> 1
mysql> select 2 BETWEEN 2 AND '3';
        -> 1
mysql> select 2 BETWEEN 2 AND 'x-3';
        -> 0

expr IN (value,...)

Returns 1 if expr is any of the values in the IN list, else returns 0. If all values are constants, then all values are evaluated according to the type of expr and sorted. The search for the item is then done using a binary search. This means IN is very quick when used with constants in the IN value list. If expr is a case-sensitive string expression, the string comparison is done in case-sensitive fashion.

mysql> select 2 IN (0,3,5,'wefwf');
        -> 0
mysql> select 'wefwf' IN (0,3,5,'wefwf');
        -> 1

expr NOT IN (value,...)

Same as NOT (expr IN (value,...)).

INTERVAL(N,N1,N2,N3...)

Returns 0 if N < N1, 1 if N < N2 and so on. All arguments are treated as numbers. It is required that N1 < N2 < N3 < Nn for this function to work correctly. This is because a binary search is used (very fast).

mysql> select INTERVAL(23, 1, 15, 17, 30, 44, 200);
        -> 3
mysql> select INTERVAL(10, 1, 10, 100, 1000);
        -> 2
mysql> select INTERVAL(22, 23, 30, 44, 200);
        -> 0

7.3.6 String comparison functions

Normally, if one expression to be compared is not case sensitive, string comparisons are done in case-insensitive fashion.

expr1 LIKE expr2 [ESCAPE string-of-one-character]

SQL simple regular expression comparison. Returns 1 (TRUE) or 0 (FALSE). With LIKE you can use the following two wildcard characters:

%	Matches any number of characters, even zero characters
_	Matches exactly one character

If one doesn't specify the ESCAPE character '\' will be used. To test for literal instances of the wildcard characters, use the following sequences:

\%	Matches one % character
\_	Matches one _ character

mysql> select 'David!' LIKE 'David_';
        -> 1
mysql> select 'David!' LIKE 'David\_';
        -> 0
mysql> select 'David_' LIKE 'David\_';
        -> 1
mysql> select 'David!' LIKE '%D%v%';
        -> 1
mysql> select 10 LIKE '1%';
        -> 1
mysql> select 'David_' LIKE 'David|_' ESCAPE '|'

LIKE is allowed on numeric expressions! (This is a MySQL extension to the ANSI SQL LIKE.)

expr1 NOT LIKE expr2 [ESCAPE 'string-of-one-character']

Same as NOT (expr1 LIKE expr2 [ESCAPE 'string-of-one-character']).

expr REGEXP pat

expr RLIKE pat

Performs a pattern match of a string expression expr against a pattern pat. The pattern can be an extended regular expression. See section H Description of MySQL regular expression syntax. Returns 1 if expr matches pat, otherwise returns 0. RLIKE is a synonym for REGEXP, provided for mSQL compatibility. NOTE: Because MySQL uses the C escape syntax in strings (\n), you must double any '\' that you use in your REGEXP strings.

mysql> select 'Monty!' REGEXP 'm%y%%';
        -> 0
mysql> select 'Monty!' REGEXP '.*';
        -> 1
mysql> select 'new*\n*line' REGEXP 'new\\*.\\*line';
        -> 1

REGEXP and RLIKE use the current character set (ISO-8859-1 Latin1 by default) when deciding the type of a character.

expr NOT REGEXP expr

Same as NOT (expr REGEXP expr).

STRCMP(expr1,expr2)

Returns 0 if the strings are the same. Returns -1 if the first argument is smaller than the second according to the current sort order. Otherwise returns 1.

mysql> select STRCMP('text', 'text2');
        -> -1
mysql> select STRCMP('text2', 'text');
        -> 1
mysql> select STRCMP('text', 'text');
        -> 0

7.3.7 Control flow functions

IFNULL(expr1,expr2)

If expr1 is not NULL, IFNULL() returns expr1, else returns expr2. IFNULL() returns a numeric or string value, depending on the context in which it are used.

mysql> select IFNULL(1,0);
        -> 1
mysql> select IFNULL(0,10);
        -> 0
mysql> select IFNULL(1/0,10);
        -> 10
mysql> select IFNULL(1/0,'yes');
        -> 'yes'

IF(expr1,expr2,expr3)

If expr1 is TRUE (expr1 <> 0 and expr1 <> NULL) then returns expr2, else returns expr3. IFNULL() returns a numeric or string value, depending on the context in which it are used. expr1 is evaluated as an INTEGER, which means that if you are testing floating-point values, you should do so using a comparison operation.

mysql> select IF(1>2,2,3);
        -> 3
mysql> select IF(1<2,'yes','no');
        -> 'yes'
mysql> select IF(strcmp('test','test1'),'yes','no');
        -> 'no'
mysql> select IF(0.1<>0,1,0);
        -> 1
mysql> select IF(0.1,1,0);
        -> 0

7.3.8 Mathematical functions

All mathematical functions return NULL in case of an error.

-

Sign. Changes the sign of the argument.

mysql> select - 2;
        -> -2

Note that if this function is used with a BIGINT, the return value is a BIGINT! This means that you should avoid using - on integers that may have the value of -2^63 !

ABS(X)

Returns the absolute value of X.

mysql> select ABS(2);
        -> 2
mysql> select ABS(-32);
        -> 32

This function is safe to use with BIGINT values.

SIGN(X)

Returns the sign of the argument (-1, 0 or 1, depending on whether X is negative, zero, or positive).

mysql> select SIGN(-32);
        -> -1
mysql> select SIGN(0);
        -> 0
mysql> select SIGN(234);
        -> 1

MOD(N,M)

%

Modulo (like % in C). Returns the remainder of N divided by M.

mysql> select MOD(234, 10);
        -> 4
mysql> select 253 % 7;
        -> 1
mysql> select MOD(29,9);
        -> 2

This function is safe to use with BIGINT values.

FLOOR(X)

Returns the largest integer value not greater than X.

mysql> select FLOOR(1.23);
        -> 1
mysql> select FLOOR(-1.23);
        -> -2

Note that the return value is converted to a BIGINT !

CEILING(X)

Returns the smallest integer value not less than X.

mysql> select CEILING(1.23);
        -> 2
mysql> select CEILING(-1.23);
        -> -1

Note that the return value is converted to a BIGINT !

ROUND(X)

Returns the argument X, rounded to an integer.

mysql> select ROUND(-1.23);
        -> -1
mysql> select ROUND(-1.58);
        -> -2
mysql> select ROUND(1.58);
        -> 2

Note that the return value is converted to a BIGINT !

ROUND(X,D)

Returns the argument X, rounded to a number with D decimals.

mysql> select ROUND(1.298, 1);
        -> 1.3

Note that the return value is converted to a BIGINT !

EXP(X)

Returns the value of e (the base of natural logarithms) raised to the power of X.

mysql> select EXP(2);
        -> 7.389056
mysql> select EXP(-2);
        -> 0.135335

LOG(X)

Returns the natural logarithm of X.

mysql> select LOG(2);
        -> 0.693147
mysql> select LOG(-2);
        -> NULL

If you want the log of a number X to some arbitary base B, use the formula LOG(X)/LOG(B).

LOG10(X)

Returns the base-10 logarithm of X.

mysql> select LOG10(2);
        -> 0.301030
mysql> select LOG10(100);
        -> 2.000000
mysql> select LOG10(-100);
        -> NULL

POW(X,Y)

POWER(X,Y)

Returns the value of X raised to the power of Y.

mysql> select POW(2,2);
        -> 4.000000
mysql> select POW(2,-2);
        -> 0.250000

SQRT(X)

Returns the non-negative square root of X.

mysql> select SQRT(4);
        -> 2.000000
mysql> select SQRT(20);
        -> 4.472136

PI()

Returns the value of PI.

mysql> select PI();
        -> 3.141593

COS(X)

Returns the cosine of X, where X is given in radians.

mysql> select COS(PI());
        -> -1.000000

SIN(X)

Returns the sine of X, where X is given in radians.

mysql> select SIN(PI());
        -> 0.000000

TAN(X)

Returns the tangent of X, where X is given in radians.

mysql> select TAN(PI()+1);
        -> 1.557408

ACOS(X)

Returns the arc cosine of X, that is, the value whose cosine is X. Returns NULL if X is not in the range -1 to 1.

mysql> select ACOS(1);
        -> 0.000000
mysql> select ACOS(1.0001);
        -> NULL
mysql> select ACOS(0);
        -> 1.570796

ASIN(X)

Returns the arc sine of X, that is, the value whose sine is X. Returns NULL if X is not in the range -1 to 1.

mysql> select ASIN(0.2);
        -> 0.201358
mysql> select ASIN('foo');
        -> 0.000000

ATAN(X)

Returns the arc tangent of X, that is, the value whose tangent is X.

mysql> select ATAN(2);
        -> 1.107149
mysql> select ATAN(-2);
        -> -1.107149

ATAN2(X,Y)

Returns the arc tangent of the two variables X and Y. It is similar to calculating the arc tangent of Y / X, except that the signs of both arguments are used to determine the quadrant of the result.

mysql> select ATAN(-2,2);
        -> -0.785398
mysql> select ATAN(PI(),0);
        -> 1.570796

COT(X)

Returns the cotangent of X.

mysql> select COT(12);
        -> -1.57267341
mysql> select COT(0);
        -> NULL

RAND()

RAND(N)

Returns a random floating-point value in the range 0 to 1.0. If an integer argument N is specified, it is used as the seed value.

mysql> select RAND();
        -> 0.5925
mysql> select RAND(20);
        -> 0.1811
mysql> select RAND(20);
        -> 0.1811
mysql> select RAND();
        -> 0.2079
mysql> select RAND();
        -> 0.7888

You can't do an ORDER BY on a column with RAND() values because ORDER BY would evaluate the column multiple times.

LEAST(X,Y...)

With two or more arguments, returns the smallest (minimum-valued) argument. The arguments are compared according to the following rules:

• If the value is used as an INTEGER, or all arguments are integer-valued, then they are compared as integers.
• If the value is used as a REAL, or all arguments are real-valued, then they are compared as reals.
• If any argument is a case-sensitive string, then the arguments are compared as case-sensitive strings
• In other cases, the arguments are compared as case-insensitive strings.

mysql> select LEAST(2,0);
        -> 0
mysql> select LEAST(34.0,3.0,5.0,767.0);
        -> 3.0
mysql> select LEAST("B","A","C");
        -> "A"

In MySQL versions prior to 3.22.5, you can use MIN() instead of LEAST.

GREATEST(X,Y...)

Returns the largest (maximum-valued) argument. The arguments are compared according to the same rules as for LEAST.

mysql> select GREATEST(2,0);
        -> 2
mysql> select GREATEST(34.0,3.0,5.0,767.0);
        -> 767.0
mysql> select GREATEST("B","A","C");
        -> "C"

In MySQL versions prior to 3.22.5, you can use MAX() instead of GREATEST.

DEGREES(X)

Returns the argument X, converted from radians to degrees.

mysql> select DEGREES(PI());
        -> 180.000000

RADIANS(X)

Returns the argument X, converted from degrees to radians.

mysql> select RADIANS(90);
        -> 1.570796

TRUNCATE(X,D)

Returns the number X, truncated to D decimals.

mysql> select TRUNCATE(1.223,1);
        -> 1.2
mysql> select TRUNCATE(1.999,1);
        -> 1.9
mysql> select TRUNCATE(1.999,0);
        -> 1

7.3.9 String functions

For functions that operate on string positions, the first position is numbered 1.

ASCII(str)

Returns the ASCII code value of the leftmost character of the string str. Returns 0 if str is the empty string. Returns NULL if str is NULL.

mysql> select ASCII(2);
        -> 50
mysql> select ASCII('dx');
        -> 100

CONV(N,FROM_BASE,TO_BASE)

Converts numbers between different number bases. Returns a string representation of the number N, converted from base FROM_BASE to base TO_BASE. Returns NULL if any argument is NULL. The argument N is interpreted as an integer, but may be specified as an integer or a string. The minimum base is 2 and the maximum base is 36. If TO_BASE is a negative number, N is regarded as a signed number. CONV works with 64-bit precision.

mysql> select CONV("a",16,2);
        -> '1010'
mysql> select CONV("6E",18,8);
        -> '172'
mysql> select CONV(-17,10,-18);
        -> '-H'
mysql> select CONV(10+"10"+'10'+0xa,10,10);
        -> '40'

BIN(N)

Returns a string representation of the binary value of N where N is a longlong number. This is the same as CONV(N,10,2). Returns NULL if N is NULL.

mysql> select BIN(12);
        -> '1100'

OCT(N)

Returns a string representation of the octal value of N where N is a longlong number. This is the same as CONV(N,10,8). Returns NULL if N is NULL.

mysql> select OCT(12);
        -> '14'

HEX(N)

Returns a string representation of the hexadecimal value of N where N is a longlong number. This is the same as CONV(N,10,16). Returns NULL if N is NULL.

mysql> select HEX(255);
        -> 'FF'

CHAR(N,...)

Returns a string consisting of the characters given by the ASCII code values of the arguments. NULL values are skipped.

mysql> select CHAR(77,121,83,81,'76');
        -> 'MySQL'

CONCAT(X,Y...)

Returns the string that results from concatenating the arguments. Returns NULL if any argument is NULL. May have more than 2 arguments.

mysql> select CONCAT('My', 'S', 'QL');
        -> 'MySQL'
mysql> select CONCAT('My', NULL, 'QL');
        -> NULL

LENGTH(str)

OCTET_LENGTH(str)

CHAR_LENGTH(str)

CHARACTER_LENGTH(str)

Returns the length of the string str.

mysql> select LENGTH('text');
        -> 4
mysql> select OCTET_LENGTH('text');
        -> 4

LOCATE(substr,str)

POSITION(substr IN str)

Returns the position of the first occurrence of substring substr in string str. Returns 0 if substr is not in str.

mysql> select LOCATE('bar', 'foobarbar');
        -> 4
mysql> select LOCATE('xbar', 'foobar');
        -> 0

LOCATE(substr,str,pos)

Returns the position of the first occurrence of substring substr in string str, starting at position pos. Returns 0 if substr is not in str.

mysql> select LOCATE('bar', 'foobarbar',5);
        -> 7

INSTR(str,substr)

Returns the position of the first occurrence of substring substr in string str. This is the same as the two-argument form of LOCATE, except that the arguments are swapped.

mysql> select INSTR('foobarbar', 'bar');
        -> 4
mysql> select INSTR('xbar', 'foobar');
        -> 0

LPAD(str,len,padstr)

Returns the string str, left-padded with the string padstr until str is len characters long.

mysql> select LPAD('hi',4,'??');
        -> '??hi'

RPAD(str,len,padstr)

Returns the string str, right-padded with the string padstr until str is len characters long.

mysql> select RPAD('hi',5,'?');
        -> 'hi???'

LEFT(str,len)

Returns the leftmost len characters from the string str.

mysql> select LEFT('foobarbar', 5);
        -> 'fooba'

RIGHT(str,len)

SUBSTRING(str FROM len)

Returns the rightmost len characters from the string str.

mysql> select RIGHT('foobarbar', 4);
        -> 'rbar'
mysql> select SUBSTRING('foobarbar' from 4);
        -> 'rbar'

SUBSTRING(str,pos,len)

SUBSTRING(str FROM pos FOR len)

MID(str,pos,len)

Returns a substring len characters long from string str, starting at position pos. The variant form that uses FROM is ANSI SQL 92 syntax.

mysql> select SUBSTRING('Quadratically',5,6);
        -> 'ratica'

SUBSTRING(str,pos)

Returns a substring from string str starting at position pos.

mysql> select SUBSTRING('Quadratically',5);
        -> 'ratically'

SUBSTRING_INDEX(str,delim,count)

Returns the substring from string str after count occurrences of the delimiter delim. If count is positive, everything to the left of the final delimiter (counting from the left) is returned. If count is negative, everything to the right of the final delimiter (counting from the right) is returned.

mysql> select SUBSTRING_INDEX('www.mysql.com', '.', 2);
        -> 'www.tcx'
mysql> select SUBSTRING_INDEX('www.mysql.com', '.', -2);
        -> 'tcx.se'

LTRIM(str)

Returns the string str with leading space characters removed.

mysql> select LTRIM('  barbar');
        -> 'barbar'

RTRIM(str)

Returns the string str with trailing space characters removed.

mysql> select RTRIM('barbar   ');
        -> 'barbar'

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

Returns the string str with all remstr prefixes and/or suffixes removed. If none of the specifiers BOTH, LEADING or TRAILING are given, BOTH is assumed. If remstr is not specified, spaces are removed.

mysql> select TRIM('  bar   ');
        -> 'bar'
mysql> select TRIM(leading 'x' from 'xxxbarxxx');
        -> 'barxxx'
mysql> select TRIM(both 'x' from 'xxxbarxxx');
        -> 'bar'
mysql> select TRIM(trailing 'xyz' from 'barxxyz');
        -> 'barx'

SOUNDEX(str)

Returns a soundex string from str. Two strings that sound "about the same" should have identical soundex strings. A "standard" soundex string is 4 characters long, but the SOUNDEX() function returns an arbitrarily long string. You can use SUBSTRING() on the result to get a "standard" soundex string. All non-alpha characters are ignored in the given string. All characters outside the A-Z range are treated as vowels.

mysql> select SOUNDEX('Hello');
        -> 'H400'
mysql> select SOUNDEX('Quadratically');
        -> 'Q36324'

SPACE(N)

Returns a string consisting of N space characters.

mysql> select SPACE(6);
        -> '      '

REPLACE(str,from,to)

Returns the string str with all all occurrences of the string from replaced by the string to.

mysql> select REPLACE('www.mysql.com', 'w', 'Ww');
        -> 'WwWwww.mysql.com'

REPEAT(str,count)

Returns a string consisting of the string str repeated count times. If count <= 0, returns an empty string. Returns NULL if str or count are NULL or if LENGTH(str)*count > max_allowed_packet.

mysql> select REPEAT('MySQL', 3);
        -> 'MySQLMySQLMySQL'

REVERSE(str)

Returns the string str with the order of the characters reversed.

mysql> select REVERSE('abc');
        -> 'cba'

INSERT(str,start,len,newstr)

Returns the string str, with the substring beginning at position start and len characters long replaced by the string newstr.

mysql> select INSERT('Quadratic', 3, 4, 'What');
        -> 'QuWhattic'

ELT(N,str1,str2,str3...)

Returns str1 if N = 1, str2 if N = 2, and so on. Returns NULL if N is less than 1 or greater than the number of arguments. ELT() is the complement of FIELD().

mysql> select ELT(1, 'ej', 'Heja', 'hej', 'foo');
        -> 'ej'
mysql> select ELT(4, 'ej', 'Heja', 'hej', 'foo');
        -> 'foo'

FIELD(str,str1,str2,str3...)

Returns the index of str in the str1, str2, str3... list. Returns 0 if str is not found. FIELD() is the complement of ELT().

mysql> select FIELD('ej', 'Hej', 'ej', 'Heja', 'hej', 'foo');
        -> 2
mysql> select FIELD('fo', 'Hej', 'ej', 'Heja', 'hej', 'foo');
        -> 0

FIND_IN_SET(str,strlist)

Returns a value 1 to N if the string str is in the list strlist consisting of N substrings. A string list is itself a string with its individual substrings separated by ',' characters. If the first argument is a constant string and the second is a column of type SET, the FIND_IN_SET is optimized to use bit arithmetic! Returns 0 if strlist is the empty string. Returns NULL if either argument is NULL. This function will not work properly if the first argument contains a ','.

mysql> SELECT FIND_IN_SET('b','a,b,c,d');
        -> 2

MAKE_SET(bits,strlist)

Returns a set (a string separated with `,') of the strings that have the corresponding bit set. NULL strings in the set list are not appended to the result.

mysql> SELECT MAKE_SET(1,'a','b','c');
        -> 'a'
mysql> SELECT MAKE_SET(1 | 4,'hello','nice','world');
        -> 'hello,world'
mysql> SELECT MAKE_SET(0,'a','b','c');
        -> "

LCASE(str)

LOWER(str)

Returns the string str with all characters changed to lowercase according to the current character set mapping (the default is Latin1).

mysql> select LCASE('QUADRATICALLY');
        -> 'quadratically'

UCASE(str)

UPPER(str)

Returns the string str with all characters changed to uppercase according to the current character set mapping (the default is Latin1).

mysql> select UCASE('Hej');
        -> 'HEJ'

There is no string function to convert a number to a char. This is not needed as MySQL automaticly converts numbers to string and vice versa:

SELECT 1+"1";
	-> 2 
SELECT concat(2,' test');
	-> '2 test'

If a string function gets a binary string as an argument, the resulting string is also a binary string. A number converted to a string is treated as a binary string. This only affects comparisons.

7.3.10 Date and time functions

Here is an example that uses date functions. The query below selects all records with a date_field value from the last 30 days:

mysql> SELECT something FROM table
           WHERE TO_DAYS(NOW()) - TO_DAYS(date_field) <= 30;

See section 7.2.6 Date and time types for a description of the range of values each type has, and the valid formats in which date and time values may be specified.

DAYOFWEEK(date)

Returns the weekday index for date (1 = Sunday, 2 = Monday, ... 7 = Saturday). These index values correspond to the ODBC standard.

mysql> select DAYOFWEEK('1998-02-03');
        -> 3

WEEKDAY(date)

Returns the weekday index for date (0 = Monday, 1 = Tuesday, ... 6 = Sunday).

mysql> select WEEKDAY('1997-10-04 22:23:00');
        -> 5
mysql> select WEEKDAY('1997-11-05');
        -> 2

DAYOFMONTH(date)

Returns the day of the month for date, in the range 1 to 31.

mysql> select DAYOFMONTH('1998-02-03');
        -> 3

DAYOFYEAR(date)

Returns the day of the year for date, in the range 1 to 366.

mysql> select DAYOFYEAR('1998-02-03');
        -> 34

MONTH(date)

Returns the month for date, in the range 1 to 12.

mysql> select MONTH('1998-02-03');
        -> 2

DAYNAME(date)

Returns the name of the weekday for date.

mysql> select DAYNAME("1998-02-05");
        -> Thursday

MONTHNAME(date)

Returns the name of the month for date.

mysql> select MONTHNAME("1998-02-05");
        -> February

QUARTER(date)

Returns the quarter of the year for date, in the range 1 to 4.

mysql> select QUARTER('98-04-01');
        -> 2

WEEK(date)

WEEK(date,first)

With a single argument, returns the week for date, in the range 0 to 52, for locations where Sunday is the first day of the week. The two-argument form of WEEK() allows you to specify whether the week starts on Sunday or Monday. The week starts on Sunday if the second argument is 0, on Monday if the second argument is 1.

mysql> select WEEK('1998-02-20');
        -> 7
mysql> select WEEK('1998-02-20',0);
        -> 7
mysql> select WEEK('1998-02-20',1);
        -> 8

YEAR(date)

Returns the year for date, in the range 1000 to 9999.

mysql> select YEAR('98-02-03');
        -> 1998

HOUR(time)

Returns the hour for time, in the range 0 to 23.

mysql> select HOUR('10:05:03');
        -> 10

MINUTE(time)

Returns the minute for time, in the range 0 to 59.

mysql> select MINUTE('98-02-03 10:05:03');
        -> 5

SECOND(time)

Returns the second for time, in the range 0 to 59.

mysql> select SECOND('10:05:03');
        -> 3

PERIOD_ADD(P,N)

Adds N months to period P (in the format YYMM or YYYYMM). Returns a value in the format YYYYMM.

mysql> select PERIOD_ADD(9801,2);
        -> 199803

PERIOD_DIFF(P1,P2)

Returns the number of months between periods P1 and P2. P1 and P2 should be in the format YYMM or YYYYMM.

mysql> select PERIOD_DIFF(9802,199703);
        -> 11

DATE_ADD(date,INTERVAL expr type)

DATE_SUB(date,INTERVAL expr type)

ADDDATE(date,INTERVAL expr type)

SUBDATE(date,INTERVAL expr type)

These functions perform date arithmetic. They are new for MySQL 3.22. ADDDATE() and SUBDATE() are synonyms for DATE_ADD() and DATE_SUB(). date is the starting date (a DATETIME or DATE value). expr is an expression specifying the interval value to be added or substracted from the starting date. expr is a string; it may start with a `-' for negative intervals. type is an interval type keyword indicating how the expression should be interpreted.

type value	Meaning	expr format
SECOND	Seconds	SECONDS
MINUTE	Minutes	MINUTES
HOUR	Hours	HOURS
DAY	Days	DAYS
MONTH	Months	MINUTES
YEAR	Years	YEARS
MINUTE_SECOND	Minutes and seconds	"MINUTES:SECONDS"
HOUR_MINUTE	Hours and minutes	"HOURS:MINUTES"
DAY_HOUR	Days and hours	"DAYS HOURS"
YEAR_MONTH	Years and months	"YEARS-MONTHS"
HOUR_SECOND	Hours, minutes, seconds	"HOURS:MINUTES:SECONDS"
DAY_MINUTE	Days, hours, minutes	"DAYS HOURS:MINUTES"
DAY_SECOND	Days, hours, minutes, seconds	"DAYS HOURS:MINUTES:SECONDS"

MySQL allows any non-numeric delimiter in the format. The ones shown in the table are the suggested delimiters. If the date is a DATE value and your calculations involve only YEAR, MONTH and DAY (that is, no time parts), the result is a DATE value. Otherwise the result is a DATETIME value.

mysql> select DATE_ADD("1997-12-31 23:59:59",INTERVAL 1 SECOND);
        -> 1998-01-01 00:00:00
mysql> select DATE_ADD("1997-12-31 23:59:59",INTERVAL "1:1" MINUTE_SECOND);
        -> 1998-01-01 00:01:00
mysql> select DATE_SUB("1998-01-01 00:00:00",INTERVAL "1 1:1:1" DAY_SECOND);
        -> 1997-12-30 22:58:59
mysql> select DATE_ADD("1997-12-31 23:59:59",INTERVAL 1 DAY);
        -> 1998-01-01 23:59:59
mysql> select DATE_ADD("1998-01-01 00:00:00",INTERVAL "-1 10" DAY_HOUR);
        -> 1997-12-30 14:00:00
mysql> select DATE_SUB("1998-01-02",INTERVAL 31 DAY);
        -> 1997-12-02

If you specify an interval value that is too short (does not include all the interval parts that would be expected from the interval type keyword), MySQL assumes you have left out the leftmost parts of the interval value. For example, if you specify a type of DAY_SECOND, the value of expr is expected to have day, hours, minutes and seconds parts. If you specify a value like "1:10", MySQL assumes that the day and hours parts are missing and the the value represents minutes and seconds. In other words, "1:10" DAY_SECOND is interpreted as "1:10" MINUTE_SECOND. If you use incorrect dates, the result is NULL. If you add MONTH, YEAR_MONTH or YEAR and the resulting date has a day that is larger than the maximum day for the new month, the day is adjusted to the maximum days in the new month.

mysql> select date_add('1998-01-30',Interval 1 month);
        -> 1998-02-28

TO_DAYS(date)

Given a date date, returns a daynumber (the number of days since year 0). TO_DAYS() is not intended for use with values that precede the advent of the Gregorian calendar (1582).

mysql> select TO_DAYS(950501);
        -> 728779
mysql> select TO_DAYS('1997-10-07);
        -> 729669

FROM_DAYS(N)

Given a daynumber N, returns a DATE value. FROM_DAYS() is not intended for use with values that precede the advent of the Gregorian calendar (1582).

mysql> select FROM_DAYS(729669);
        -> '1997-10-07'

DATE_FORMAT(date,format)

Formats the date value according to the format string. The following specifiers may be used in the format string:

%M	Month name (January..December)
%W	Weekday name (Sunday..Saturday)
%D	Day of the month with english suffix (1st, 2nd, 3rd, etc.)
%Y	Year, numeric, 4 digits
%y	Year, numeric, 2 digits
%a	Abbreviated weekday name (Sun..Sat)
%d	Day of the month, numeric (00..31)
%e	Day of the month, numeric (0..31)
%m	Month, numeric (01..12)
%c	Month, numeric (1..12)
%b	Abbreviated month name (Jan..Dec)
%j	Day of year (001..366)
%H	Hour (00..23)
%k	Hour (0..23)
%h	Hour (01..12)
%I	Hour (01..12)
%l	Hour (1..12)
%i	Minutes, numeric (00..59)
%r	Time, 12-hour (hh:mm:ss [AP]M)
%T	Time, 24-hour (hh:mm:ss)
%S	Seconds (00..59)
%s	Seconds (00..59)
%p	AM or PM
%w	Day of the week (0=Sunday..6=Saturday)
%U	Week (0..52), where Sunday is the first day of the week.
%u	Week (0..52), where Monday is the first day of the week.
%%	Single `%' characters are ignored. Use %% to produce a literal `%' (for future extensions).

All other characters are just copied to the result.

mysql> select DATE_FORMAT('1997-10-04 22:23:00', '%W %M %Y');
        -> 'Saturday October 1997'
mysql> select DATE_FORMAT('1997-10-04 22:23:00', '%H:%i:%s');
        -> '22:23:00'
mysql> select DATE_FORMAT('1997-10-04 22:23:00', '%D %y %a %d %m %b %j');
        -> '4th 97 Sat 04 10 Oct 277'
mysql> select DATE_FORMAT('1997-10-04 22:23:00', '%H %k %I %r %T %S %w');
        -> '22 22 10 10:23:00 PM 22:23:00 00 6'

For the moment, % is optional. In future versions of MySQL, % will be required.

TIME_FORMAT(time,format)

This is used like the DATE_FORMAT() function above, but the format string may contain only those format specifiers that handle hours, minutes and seconds. Other specifiers produce a NULL value or 0.

CURDATE()

CURRENT_DATE

Returns today's date. The format is YYYYMMDD or 'YYYY-MM-DD', depending on whether the function is used in a numeric or string context.

mysql> select CURDATE();
        -> '1997-12-15'
mysql> select CURDATE()+0;
        -> 19971215

CURTIME()

CURRENT_TIME

Returns the current time. The format is HHMMSS or 'HH:MM:SS', depending on whether the function is used in a numeric or string context.

mysql> select CURTIME();
        -> '23:50:26'
mysql> select CURTIME()+0;
        -> 235026

NOW()

SYSDATE()

CURRENT_TIMESTAMP

Returns the current time, in the format YYYYMMDDHHMMSS or 'YYYY-MM-DD HH:MM:SS', depending on whether the function is used in a numeric or string context.

mysql> select NOW();
        -> '1997-12-15 23:50:26'
mysql> select NOW()+0;
        -> 19971215235026

UNIX_TIMESTAMP()

UNIX_TIMESTAMP(date)

If called with no argument, returns a Unix timestamp (seconds in GMT since '1970-01-01 00:00:00'). Normally, it is called with a TIMESTAMP-valued argument, in which case it returns the value of the argument in seconds. date may be a DATE string, a DATETIME string, a TIMESTAMP, or a number in the format YYMMDD or YYYYMMDD in local time.

mysql> select UNIX_TIMESTAMP();
        -> 882226357
mysql> select UNIX_TIMESTAMP('1997-10-04 22:23:00');
        -> 875996580

When UNIX_TIMESTAMP is used on a TIMESTAMP column, the function will get the value without an implicit `string-to-unix-timestamp' conversion.

FROM_UNIXTIME(Unix_timestamp)

Returns a representation of the timestamp value. The format is YYYYMMDDHHMMSS or 'YYYY-MM-DD HH:MM:SS', depending on whether the function is used in a numeric or string context.

mysql> select FROM_UNIXTIME(875996580);
        -> '1997-10-04 22:23:00'
mysql> select FROM_UNIXTIME(875996580)+0;
        -> 19971004222300

FROM_UNIXTIME(Unix_timestamp,format)

Returns a string representation of the Unix timestamp, formatted according to the format string. format may contain the same specifiers as those listed in the entry for the DATE_FORMAT() function.

mysql> select FROM_UNIXTIME(UNIX_TIMESTAMP(), '%Y %D %M %h:%i:%s %x');
        -> '1997 23rd December 03:43:30 x'

SEC_TO_TIME(seconds)

Returns the seconds argument, converted to hours, minutes and seconds in the format HHMMSS or HH:MM:SS, depending on whether the function is used in a numeric or string context.

mysql> select SEC_TO_TIME(2378);
        -> '00:39:38'
mysql> select SEC_TO_TIME(2378)+0;
        -> 3938

TIME_TO_SEC(time)

Returns the time argument, converted to seconds.

mysql> select TIME_TO_SEC('22:23:00');
        -> 80580
mysql> select TIME_TO_SEC('00:39:38');
        -> 2378