<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Appendix A. Problems and Common Errors</title><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"><link rel="start" href="index.html" title="MySQL 5.0 Reference Manual"><link rel="up" href="index.html" title="MySQL 5.0 Reference Manual"><link rel="prev" href="extending-mysql.html" title="Chapter 24. Extending MySQL"><link rel="next" href="error-handling.html" title="Appendix B. Error Codes and Messages"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix A. Problems and Common Errors</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="extending-mysql.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="error-handling.html">Next</a></td></tr></table><hr></div><div class="appendix" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="problems"></a>Appendix A. Problems and Common Errors</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="problems.html#what-is-crashing">A.1. How to Determine What Is Causing a Problem</a></span></dt><dt><span class="section"><a href="problems.html#common-errors">A.2. Common Errors When Using MySQL Programs</a></span></dt><dd><dl><dt><span class="section"><a href="problems.html#error-access-denied">A.2.1. <code class="literal">Access denied</code></a></span></dt><dt><span class="section"><a href="problems.html#can-not-connect-to-server">A.2.2. <code class="literal">Can't connect to [local] MySQL server</code></a></span></dt><dt><span class="section"><a href="problems.html#old-client">A.2.3. <code class="literal">Client does not support authentication protocol</code></a></span></dt><dt><span class="section"><a href="problems.html#password-too-long">A.2.4. Password Fails When Entered Interactively</a></span></dt><dt><span class="section"><a href="problems.html#blocked-host">A.2.5. <code class="literal">Host '<em class="replaceable"><code>host_name</code></em>' is blocked</code></a></span></dt><dt><span class="section"><a href="problems.html#too-many-connections">A.2.6. <code class="literal">Too many connections</code></a></span></dt><dt><span class="section"><a href="problems.html#out-of-memory">A.2.7. <code class="literal">Out of memory</code></a></span></dt><dt><span class="section"><a href="problems.html#gone-away">A.2.8. <code class="literal">MySQL server has gone away</code></a></span></dt><dt><span class="section"><a href="problems.html#packet-too-large">A.2.9. <code class="literal">Packet too large</code></a></span></dt><dt><span class="section"><a href="problems.html#communication-errors">A.2.10. Communication Errors and Aborted Connections</a></span></dt><dt><span class="section"><a href="problems.html#full-table">A.2.11. <code class="literal">The table is full</code></a></span></dt><dt><span class="section"><a href="problems.html#cannot-create">A.2.12. <code class="literal">Can't create/write to file</code></a></span></dt><dt><span class="section"><a href="problems.html#commands-out-of-sync">A.2.13. <code class="literal">Commands out of sync</code></a></span></dt><dt><span class="section"><a href="problems.html#ignoring-user">A.2.14. <code class="literal">Ignoring user</code></a></span></dt><dt><span class="section"><a href="problems.html#cannot-find-table">A.2.15. <code class="literal">Table '<em class="replaceable"><code>tbl_name</code></em>' doesn't exist</code></a></span></dt><dt><span class="section"><a href="problems.html#cannot-initialize-character-set">A.2.16. <code class="literal">Can't initialize character set</code></a></span></dt><dt><span class="section"><a href="problems.html#not-enough-file-handles">A.2.17. File Not Found</a></span></dt></dl></dd><dt><span class="section"><a href="problems.html#installation-issues">A.3. Installation-Related Issues</a></span></dt><dd><dl><dt><span class="section"><a href="problems.html#link-errors">A.3.1. Problems Linking to the MySQL Client Library</a></span></dt><dt><span class="section"><a href="problems.html#changing-mysql-user">A.3.2. How to Run MySQL as a Normal User</a></span></dt><dt><span class="section"><a href="problems.html#file-permissions">A.3.3. Problems with File Permissions</a></span></dt></dl></dd><dt><span class="section"><a href="problems.html#administration-issues">A.4. Administration-Related Issues</a></span></dt><dd><dl><dt><span class="section"><a href="problems.html#resetting-permissions">A.4.1. How to Reset the Root Password</a></span></dt><dt><span class="section"><a href="problems.html#crashing">A.4.2. What to Do If MySQL Keeps Crashing</a></span></dt><dt><span class="section"><a href="problems.html#full-disk">A.4.3. How MySQL Handles a Full Disk</a></span></dt><dt><span class="section"><a href="problems.html#temporary-files">A.4.4. Where MySQL Stores Temporary Files</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-mysql-sock">A.4.5. How to Protect or Change the MySQL Socket File <code class="filename">/tmp/mysql.sock</code></a></span></dt><dt><span class="section"><a href="problems.html#timezone-problems">A.4.6. Time Zone Problems</a></span></dt></dl></dd><dt><span class="section"><a href="problems.html#query-issues">A.5. Query-Related Issues</a></span></dt><dd><dl><dt><span class="section"><a href="problems.html#case-sensitivity">A.5.1. Case Sensitivity in Searches</a></span></dt><dt><span class="section"><a href="problems.html#using-date">A.5.2. Problems Using <code class="literal">DATE</code> Columns</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-null">A.5.3. Problems with <code class="literal">NULL</code> Values</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-alias">A.5.4. Problems with Column Aliases</a></span></dt><dt><span class="section"><a href="problems.html#non-transactional-tables">A.5.5. Rollback Failure for Non-Transactional Tables</a></span></dt><dt><span class="section"><a href="problems.html#deleting-from-related-tables">A.5.6. Deleting Rows from Related Tables</a></span></dt><dt><span class="section"><a href="problems.html#no-matching-rows">A.5.7. Solving Problems with No Matching Rows</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-float">A.5.8. Problems with Floating-Point Comparisons</a></span></dt></dl></dd><dt><span class="section"><a href="problems.html#optimizer-issues">A.6. Optimizer-Related Issues</a></span></dt><dt><span class="section"><a href="problems.html#table-definition-issues">A.7. Table Definition-Related Issues</a></span></dt><dd><dl><dt><span class="section"><a href="problems.html#alter-table-problems">A.7.1. Problems with <code class="literal">ALTER TABLE</code></a></span></dt><dt><span class="section"><a href="problems.html#change-column-order">A.7.2. How to Change the Order of Columns in a Table</a></span></dt><dt><span class="section"><a href="problems.html#temporary-table-problems">A.7.3. <code class="literal">TEMPORARY TABLE</code> Problems</a></span></dt></dl></dd><dt><span class="section"><a href="problems.html#bugs">A.8. Known Issues in MySQL</a></span></dt><dd><dl><dt><span class="section"><a href="problems.html#open-bugs">A.8.1. Open Issues in MySQL</a></span></dt></dl></dd></dl></div><a class="indexterm" name="id3130284"></a><a class="indexterm" name="id3130295"></a><p>
This appendix lists some common problems and error messages that you
may encounter. It describes how to determine the causes of the
problems and what to do to solve them.
</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="what-is-crashing"></a>A.1. How to Determine What Is Causing a Problem</h2></div></div></div><p>
When you run into a problem, the first thing you should do is to
find out which program or piece of equipment is causing it:
</p><div class="itemizedlist"><ul type="disc"><li><p>
If you have one of the following symptoms, then it is probably
a hardware problems (such as memory, motherboard, CPU, or hard
disk) or kernel problem:
</p><div class="itemizedlist"><ul type="circle"><li><p>
The keyboard doesn't work. This can normally be checked by
pressing the Caps Lock key. If the Caps Lock light doesn't
change, you have to replace your keyboard. (Before doing
this, you should try to restart your computer and check
all cables to the keyboard.)
</p></li><li><p>
The mouse pointer doesn't move.
</p></li><li><p>
The machine doesn't answer to a remote machine's pings.
</p></li><li><p>
Other programs that are not related to MySQL don't behave
correctly.
</p></li><li><p>
Your system restarted unexpectedly. (A faulty user-level
program should never be able to take down your system.)
</p></li></ul></div><p>
In this case, you should start by checking all your cables and
run some diagnostic tool to check your hardware! You should
also check whether there are any patches, updates, or service
packs for your operating system that could likely solve your
problem. Check also that all your libraries (such as
<code class="literal">glibc</code>) are up to date.
</p><p>
It's always good to use a machine with ECC memory to discover
memory problems early.
</p></li><li><p>
If your keyboard is locked up, you may be able to recover by
logging in to your machine from another machine and executing
<code class="literal">kbd_mode -a</code>.
</p></li><li><p>
Please examine your system log file
(<code class="filename">/var/log/messages</code> or similar) for
reasons for your problem. If you think the problem is in
MySQL, you should also examine MySQL's log files. See
<a href="database-administration.html#log-files" title="5.11. The MySQL Log Files">Section 5.11, “The MySQL Log Files”</a>.
</p></li><li><p>
If you don't think you have hardware problems, you should try
to find out which program is causing problems. Try using
<span><strong class="command">top</strong></span>, <span><strong class="command">ps</strong></span>, Task Manager,
or some similar program, to check which program is taking all
CPU or is locking the machine.
</p></li><li><p>
Use <span><strong class="command">top</strong></span>, <span><strong class="command">df</strong></span>, or a
similar program to check whether you are out of memory, disk
space, file descriptors, or some other critical resource.
</p></li><li><p>
If the problem is some runaway process, you can always try to
kill it. If it doesn't want to die, there is probably a bug in
the operating system.
</p></li></ul></div><p>
If after you have examined all other possibilities and you have
concluded that the MySQL server or a MySQL client is causing the
problem, it's time to create a bug report for our mailing list or
our support team. In the bug report, try to give a very detailed
description of how the system is behaving and what you think is
happening. You should also state why you think that MySQL is
causing the problem. Take into consideration all the situations in
this chapter. State any problems exactly how they appear when you
examine your system. Use the “<span class="quote">copy and paste</span>” method
for any output and error messages from programs and log files.
</p><p>
Try to describe in detail which program is not working and all
symptoms you see. We have in the past received many bug reports
that state only “<span class="quote">the system doesn't work.</span>” This
doesn't provide us with any information about what could be the
problem.
</p><p>
If a program fails, it's always useful to know the following
information:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Has the program in question made a segmentation fault (did it
dump core)?
</p></li><li><p>
Is the program taking up all available CPU time? Check with
<span><strong class="command">top</strong></span>. Let the program run for a while, it
may simply be evaluating something computationally intensive.
</p></li><li><p>
If the <span><strong class="command">mysqld</strong></span> server is causing problems,
can you get any response from it with <span><strong class="command">mysqladmin -u
root ping</strong></span> or <span><strong class="command">mysqladmin -u root
processlist</strong></span>?
</p></li><li><p>
What does a client program say when you try to connect to the
MySQL server? (Try with <span><strong class="command">mysql</strong></span>, for
example.) Does the client jam? Do you get any output from the
program?
</p></li></ul></div><p>
When sending a bug report, you should follow the outline described
in <a href="introduction.html#asking-questions" title="1.7.1.2. Asking Questions or Reporting Bugs">Section 1.7.1.2, “Asking Questions or Reporting Bugs”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="common-errors"></a>A.2. Common Errors When Using MySQL Programs</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="problems.html#error-access-denied">A.2.1. <code class="literal">Access denied</code></a></span></dt><dt><span class="section"><a href="problems.html#can-not-connect-to-server">A.2.2. <code class="literal">Can't connect to [local] MySQL server</code></a></span></dt><dt><span class="section"><a href="problems.html#old-client">A.2.3. <code class="literal">Client does not support authentication protocol</code></a></span></dt><dt><span class="section"><a href="problems.html#password-too-long">A.2.4. Password Fails When Entered Interactively</a></span></dt><dt><span class="section"><a href="problems.html#blocked-host">A.2.5. <code class="literal">Host '<em class="replaceable"><code>host_name</code></em>' is blocked</code></a></span></dt><dt><span class="section"><a href="problems.html#too-many-connections">A.2.6. <code class="literal">Too many connections</code></a></span></dt><dt><span class="section"><a href="problems.html#out-of-memory">A.2.7. <code class="literal">Out of memory</code></a></span></dt><dt><span class="section"><a href="problems.html#gone-away">A.2.8. <code class="literal">MySQL server has gone away</code></a></span></dt><dt><span class="section"><a href="problems.html#packet-too-large">A.2.9. <code class="literal">Packet too large</code></a></span></dt><dt><span class="section"><a href="problems.html#communication-errors">A.2.10. Communication Errors and Aborted Connections</a></span></dt><dt><span class="section"><a href="problems.html#full-table">A.2.11. <code class="literal">The table is full</code></a></span></dt><dt><span class="section"><a href="problems.html#cannot-create">A.2.12. <code class="literal">Can't create/write to file</code></a></span></dt><dt><span class="section"><a href="problems.html#commands-out-of-sync">A.2.13. <code class="literal">Commands out of sync</code></a></span></dt><dt><span class="section"><a href="problems.html#ignoring-user">A.2.14. <code class="literal">Ignoring user</code></a></span></dt><dt><span class="section"><a href="problems.html#cannot-find-table">A.2.15. <code class="literal">Table '<em class="replaceable"><code>tbl_name</code></em>' doesn't exist</code></a></span></dt><dt><span class="section"><a href="problems.html#cannot-initialize-character-set">A.2.16. <code class="literal">Can't initialize character set</code></a></span></dt><dt><span class="section"><a href="problems.html#not-enough-file-handles">A.2.17. File Not Found</a></span></dt></dl></div><a class="indexterm" name="id3130597"></a><p>
This section lists some errors that users frequently encounter
when running MySQL programs. Although the problems show up when
you try to run client programs, the solutions to many of the
problems involves changing the configuration of the MySQL server.
</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="error-access-denied"></a>A.2.1. <code class="literal">Access denied</code></h3></div></div></div><a class="indexterm" name="id3130627"></a><a class="indexterm" name="id3130637"></a><a class="indexterm" name="id3130648"></a><p>
An <code class="literal">Access denied</code> error can have many causes.
Often the problem is related to the MySQL accounts that the
server allows client programs to use when connecting. See
<a href="database-administration.html#access-denied" title="5.7.8. Causes of Access denied Errors">Section 5.7.8, “Causes of <code class="literal">Access denied</code> Errors”</a>. See
<a href="database-administration.html#privileges" title="5.7.2. How the Privilege System Works">Section 5.7.2, “How the Privilege System Works”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="can-not-connect-to-server"></a>A.2.2. <code class="literal">Can't connect to [local] MySQL server</code></h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="problems.html#can-not-connect-to-server-on-windows">A.2.2.1. <code class="literal">Connection to MySQL Server Failing on Windows</code></a></span></dt></dl></div><p>
A MySQL client on Unix can connect to the
<span><strong class="command">mysqld</strong></span> server in two different ways: By using
a Unix socket file to connect through a file in the filesystem
(default <code class="filename">/tmp/mysql.sock</code>), or by using
TCP/IP, which connects through a port number. A Unix socket file
connection is faster than TCP/IP, but can be used only when
connecting to a server on the same computer. A Unix socket file
is used if you don't specify a hostname or if you specify the
special hostname <code class="literal">localhost</code>.
</p><p>
If the MySQL server is running on Windows 9x or Me, you can
connect only via TCP/IP. If the server is running on Windows NT,
2000, XP, or 2003 and is started with the
<code class="option">--enable-named-pipe</code> option, you can also
connect with named pipes if you run the client on the host where
the server is running. The name of the named pipe is
<code class="literal">MySQL</code> by default. If you don't give a
hostname when connecting to <span><strong class="command">mysqld</strong></span>, a MySQL
client first tries to connect to the named pipe. If that doesn't
work, it connects to the TCP/IP port. You can force the use of
named pipes on Windows by using <code class="literal">.</code> as the
hostname.
</p><p>
The error (2002) <code class="literal">Can't connect to ...</code>
normally means that there is no MySQL server running on the
system or that you are using an incorrect Unix socket filename
or TCP/IP port number when trying to connect to the server.
</p><p>
Start by checking whether there is a process named
<span><strong class="command">mysqld</strong></span> running on your server host. (Use
<span><strong class="command">ps xa | grep mysqld</strong></span> on Unix or the Task
Manager on Windows.) If there is no such process, you should
start the server. See <a href="installing.html#starting-server" title="2.9.2.3. Starting and Troubleshooting the MySQL Server">Section 2.9.2.3, “Starting and Troubleshooting the MySQL Server”</a>.
</p><p>
If a <span><strong class="command">mysqld</strong></span> process is running, you can check
it by trying the following commands. The port number or Unix
socket filename might be different in your setup.
<code class="literal">host_ip</code> represents the IP number of the
machine where the server is running.
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysqladmin version</code></strong>
shell> <strong class="userinput"><code>mysqladmin variables</code></strong>
shell> <strong class="userinput"><code>mysqladmin -h `hostname` version variables</code></strong>
shell> <strong class="userinput"><code>mysqladmin -h `hostname` --port=3306 version</code></strong>
shell> <strong class="userinput"><code>mysqladmin -h host_ip version</code></strong>
shell> <strong class="userinput"><code>mysqladmin --protocol=socket --socket=/tmp/mysql.sock version</code></strong>
</pre><p>
Note the use of backticks rather than forward quotes with the
<code class="literal">hostname</code> command; these cause the output of
<code class="literal">hostname</code> (that is, the current hostname) to
be substituted into the <span><strong class="command">mysqladmin</strong></span> command.
If you have no <code class="literal">hostname</code> command or are
running on Windows, you can manually type the hostname of your
machine (without backticks) following the <code class="literal">-h</code>
option. You can also try <code class="literal">-h 127.0.0.1</code> to
connect with TCP/IP to the local host.
</p><p>
Here are some reasons the <code class="literal">Can't connect to local MySQL
server</code> error might occur:
</p><div class="itemizedlist"><ul type="disc"><li><p>
<span><strong class="command">mysqld</strong></span> is not running. Check your
operating system's process list to ensure the
<span><strong class="command">mysqld</strong></span> process is present.
</p></li><li><p>
You're running a MySQL server on Windows with many TCP/IP
connections to it. If you're experiencing that quite often
your clients get that error, you can find a workaround here:
<a href="problems.html#can-not-connect-to-server-on-windows" title="A.2.2.1. Connection to MySQL Server Failing on Windows">Section A.2.2.1, “<code class="literal">Connection to MySQL Server Failing on Windows</code>”</a>.
</p></li><li><p>
You are running on a system that uses MIT-pthreads. If you
are running on a system that doesn't have native threads,
<span><strong class="command">mysqld</strong></span> uses the MIT-pthreads package. See
<a href="installing.html#which-os" title="2.1.1. Operating Systems Supported by MySQL">Section 2.1.1, “Operating Systems Supported by MySQL”</a>. However, not all MIT-pthreads
versions support Unix socket files. On a system without
socket file support, you must always specify the hostname
explicitly when connecting to the server. Try using this
command to check the connection to the server:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysqladmin -h `hostname` version</code></strong>
</pre></li><li><p>
Someone has removed the Unix socket file that
<span><strong class="command">mysqld</strong></span> uses
(<code class="filename">/tmp/mysql.sock</code> by default). For
example, you might have a <span><strong class="command">cron</strong></span> job that
removes old files from the <code class="filename">/tmp</code>
directory. You can always run <span><strong class="command">mysqladmin
version</strong></span> to check whether the Unix socket file that
<span><strong class="command">mysqladmin</strong></span> is trying to use really
exists. The fix in this case is to change the
<span><strong class="command">cron</strong></span> job to not remove
<code class="filename">mysql.sock</code> or to place the socket file
somewhere else. See
<a href="problems.html#problems-with-mysql-sock" title="A.4.5. How to Protect or Change the MySQL Socket File /tmp/mysql.sock">Section A.4.5, “How to Protect or Change the MySQL Socket File <code class="filename">/tmp/mysql.sock</code>”</a>.
</p></li><li><p>
You have started the <span><strong class="command">mysqld</strong></span> server with
the <code class="option">--socket=/path/to/socket</code> option, but
forgotten to tell client programs the new name of the socket
file. If you change the socket pathname for the server, you
must also notify the MySQL clients. You can do this by
providing the same <code class="option">--socket</code> option when you
run client programs. You also need to ensure that clients
have permission to access the
<code class="filename">mysql.sock</code> file. To find out where the
socket file is, you can do:
</p><pre class="programlisting">shell> <strong class="userinput"><code>netstat -ln | grep mysql</code></strong>
</pre><p>
See <a href="problems.html#problems-with-mysql-sock" title="A.4.5. How to Protect or Change the MySQL Socket File /tmp/mysql.sock">Section A.4.5, “How to Protect or Change the MySQL Socket File <code class="filename">/tmp/mysql.sock</code>”</a>.
</p></li><li><p>
You are using Linux and one server thread has died (dumped
core). In this case, you must kill the other
<span><strong class="command">mysqld</strong></span> threads (for example, with
<code class="literal">kill</code> or with the
<code class="literal">mysql_zap</code> script) before you can restart
the MySQL server. See <a href="problems.html#crashing" title="A.4.2. What to Do If MySQL Keeps Crashing">Section A.4.2, “What to Do If MySQL Keeps Crashing”</a>.
</p></li><li><p>
The server or client program might not have the proper
access privileges for the directory that holds the Unix
socket file or the socket file itself. In this case, you
must either change the access privileges for the directory
or socket file so that the server and clients can access
them, or restart <span><strong class="command">mysqld</strong></span> with a
<code class="option">--socket</code> option that specifies a socket
filename in a directory where the server can create it and
where client programs can access it.
</p></li></ul></div><p>
If you get the error message <code class="literal">Can't connect to MySQL
server on some_host</code>, you can try the following things
to find out what the problem is:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Check whether the server is running on that host by
executing <code class="literal">telnet some_host 3306</code> and
pressing the Enter key a couple of times. (3306 is the
default MySQL port number. Change the value if your server
is listening to a different port.) If there is a MySQL
server running and listening to the port, you should get a
response that includes the server's version number. If you
get an error such as <code class="literal">telnet: Unable to connect to
remote host: Connection refused</code>, then there is no
server running on the given port.
</p></li><li><p>
If the server is running on the local host, try using
<span><strong class="command">mysqladmin -h localhost variables</strong></span> to
connect using the Unix socket file. Verify the TCP/IP port
number that the server is configured to listen to (it is the
value of the <code class="literal">port</code> variable.)
</p></li><li><p>
Make sure that your <span><strong class="command">mysqld</strong></span> server was not
started with the <code class="option">--skip-networking</code> option.
If it was, you cannot connect to it using TCP/IP.
</p></li><li><p>
Check to make sure that there is no firewall blocking access
to MySQL. Applications such as ZoneAlarm and the Windows XP
personal firewall may need to be configured to allow
external access to a MySQL server.
</p></li></ul></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="can-not-connect-to-server-on-windows"></a>A.2.2.1. <code class="literal">Connection to MySQL Server Failing on Windows</code></h4></div></div></div><p>
When you're running a MySQL server on Windows with many TCP/IP
connections to it, and you're experiencing that quite often
your clients get a <code class="literal">Can't connect to MySQL
server</code> error, the reason might be that Windows
doesn't allow for enough ephemeral (short-lived) ports to
serve those connections.
</p><p>
By default, Windows allows 5000 ephemeral (short-lived) TCP
ports to the user. After any port is closed it will remain in
a <code class="literal">TIME_WAIT</code> status for 120 seconds. This
status allows the connection to be reused at a much lower cost
than re-initialising a brand new connection. However, the port
will not be available again until this time expires.
</p><p>
With a small stack of available TCP ports (5000) and a high
number of TCP ports being open and closed over a short period
of time along with the <code class="literal">TIME_WAIT</code> status you
have a good chance for running out of ports. There are two
ways to address this problem:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Reduce the number of TCP ports consumed quickly by
investigating connection pooling or persistent connections
where possible
</p></li><li><p>
Tune some settings in the Windows registry (see below)
</p></li></ul></div><p>
<span class="bold"><strong> IMPORTANT: The following procedure
involves modifying the Windows registry. Before you modify the
registry, make sure to back it up and make sure that you
understand how to restore the registry if a problem occurs.
For information about how to back up, restore, and edit the
registry, view the following article in the Microsoft
Knowledge Base:
<a href="http://support.microsoft.com/kb/256986/EN-US/" target="_top">http://support.microsoft.com/kb/256986/EN-US/</a>.
</strong></span>
</p><div class="orderedlist"><ol type="1"><li><p>
Start Registry Editor (<code class="filename">Regedt32.exe</code>).
</p></li><li><p>
Locate the following key in the registry:
</p><pre class="programlisting">HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
</pre></li><li><p>
On the <code class="literal">Edit</code> menu, click <code class="literal">Add
Value</code>, and then add the following registry
value:
</p><pre class="programlisting">Value Name: MaxUserPort
Data Type: REG_DWORD
Value: 65534
</pre><p>
This sets the number of ephemeral ports available to any
user. The valid range is between 5000 and 65534 (decimal).
The default value is 0x1388 (5000 decimal).
</p></li><li><p>
On the <code class="literal">Edit</code> menu, click <code class="literal">Add
Value</code>, and then add the following registry
value:
</p><pre class="programlisting">Value Name: TcpTimedWaitDelay
Data Type: REG_DWORD
Value: 30
</pre><p>
This sets the number of seconds to hold a TCP port
connection in <code class="literal">TIME_WAIT</code> state before
closing. The valid range is between 0 (zero) and 300
(decimal). The default value is 0x78 (120 decimal).
</p></li><li><p>
Quit Registry Editor.
</p></li><li><p>
Reboot the machine.
</p></li></ol></div><p>
Note: Undoing the above should be as simple as deleting the
registry entries you've created.
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="old-client"></a>A.2.3. <code class="literal">Client does not support authentication protocol</code></h3></div></div></div><p>
MySQL 5.0 uses an authentication protocol based on
a password hashing algorithm that is incompatible with that used
by older (pre-4.1) clients. If you upgrade the server from 4.1,
attempts to connect to it with an older client may fail with the
following message:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysql</code></strong>
Client does not support authentication protocol requested
by server; consider upgrading MySQL client
</pre><p>
To solve this problem, you should use one of the following
approaches:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Upgrade all client programs to use a 4.1.1 or newer client
library.
</p></li><li><p>
When connecting to the server with a pre-4.1 client program,
use an account that still has a pre-4.1-style password.
</p></li><li><p>
Reset the password to pre-4.1 style for each user that needs
to use a pre-4.1 client program. This can be done using the
<code class="literal">SET PASSWORD</code> statement and the
<code class="literal">OLD_PASSWORD()</code> function:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SET PASSWORD FOR</code></strong>
-> <strong class="userinput"><code>'<em class="replaceable"><code>some_user</code></em>'@'<em class="replaceable"><code>some_host</code></em>' = OLD_PASSWORD('<em class="replaceable"><code>newpwd</code></em>');</code></strong>
</pre><p>
Alternatively, use <code class="literal">UPDATE</code> and
<code class="literal">FLUSH PRIVILEGES</code>:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>UPDATE mysql.user SET Password = OLD_PASSWORD('<em class="replaceable"><code>newpwd</code></em>')</code></strong>
-> <strong class="userinput"><code>WHERE Host = '<em class="replaceable"><code>some_host</code></em>' AND User = '<em class="replaceable"><code>some_user</code></em>';</code></strong>
mysql> <strong class="userinput"><code>FLUSH PRIVILEGES;</code></strong>
</pre><p>
Substitute the password you want to use for
“<span class="quote"><em class="replaceable"><code>newpwd</code></em></span>” in the
preceding examples. MySQL cannot tell you what the original
password was, so you'll need to pick a new one.
</p></li><li><p>
Tell the server to use the older password hashing algorithm:
</p><div class="orderedlist"><ol type="1"><li><p>
Start <span><strong class="command">mysqld</strong></span> with the
<code class="option">--old-passwords</code> option.
</p></li><li><p>
Assign an old-format password to each account that has
had its password updated to the longer 4.1 format. You
can identify these accounts with the following query:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT Host, User, Password FROM mysql.user</code></strong>
-> <strong class="userinput"><code>WHERE LENGTH(Password) > 16;</code></strong>
</pre><p>
For each account record displayed by the query, use the
<code class="literal">Host</code> and <code class="literal">User</code>
values and assign a password using the
<code class="literal">OLD_PASSWORD()</code> function and either
<code class="literal">SET PASSWORD</code> or
<code class="literal">UPDATE</code>, as described earlier.
</p></li></ol></div></li></ul></div><p>
<span class="bold"><strong>Note</strong></span>: In older versions of PHP,
the <code class="literal">mysql</code> extension does not support the
authentication protocol in MySQL 4.1.1 and higher. This is true
regardless of the PHP version being used. If you wish to use the
<code class="literal">mysql</code> extension with MySQL 4.1 or newer, you
may need to follow one of the options discussed above for
configuring MySQL to work with old clients. The
<code class="literal">mysqli</code> extension (stands for "MySQL,
Improved"; added in PHP 5) is compatible with the improved
password hashing employed in MySQL 4.1 and higher, and no
special configuration of MySQL need be done in order to use this
MySQL client library. For more information about the
<code class="literal">mysqli</code> extension, see
<a href="http://php.net/mysqli" target="_top">http://php.net/mysqli</a>.
</p><p>
For additional background on password hashing and
authentication, see <a href="database-administration.html#password-hashing" title="5.7.9. Password Hashing in MySQL 4.1">Section 5.7.9, “Password Hashing in MySQL 4.1”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="password-too-long"></a>A.2.4. Password Fails When Entered Interactively</h3></div></div></div><p>
MySQL client programs prompt for a password when invoked with a
<code class="option">--password</code> or <code class="option">-p</code> option that
has no following password value:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysql -u <em class="replaceable"><code>user_name</code></em> -p</code></strong>
Enter password:
</pre><p>
On some systems, you may find that your password works when
specified in an option file or on the command line, but not when
you enter it interactively at the <code class="literal">Enter
password:</code> prompt. This occurs when the library
provided by the system to read passwords limits password values
to a small number of characters (typically eight). That is a
problem with the system library, not with MySQL. To work around
it, change your MySQL password to a value that is eight or fewer
characters long, or put your password in an option file.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="blocked-host"></a>A.2.5. <code class="literal">Host '<em class="replaceable"><code>host_name</code></em>' is blocked</code></h3></div></div></div><p>
If you get the following error, it means that
<span><strong class="command">mysqld</strong></span> has received many connect requests
from the host
<code class="literal">'<em class="replaceable"><code>host_name</code></em>'</code> that
have been interrupted in the middle:
</p><pre class="programlisting">Host '<em class="replaceable"><code>host_name</code></em>' is blocked because of many connection errors.
Unblock with 'mysqladmin flush-hosts'
</pre><p>
The number of interrupted connect requests allowed is determined
by the value of the <code class="literal">max_connect_errors</code> system
variable. After <code class="literal">max_connect_errors</code> failed
requests, <span><strong class="command">mysqld</strong></span> assumes that something is
wrong (for example, that someone is trying to break in), and
blocks the host from further connections until you execute a
<span><strong class="command">mysqladmin flush-hosts</strong></span> command or issue a
<code class="literal">FLUSH HOSTS</code> statement. See
<a href="database-administration.html#server-system-variables" title="5.3.3. Server System Variables">Section 5.3.3, “Server System Variables”</a>.
</p><p>
By default, <span><strong class="command">mysqld</strong></span> blocks a host after 10
connection errors. You can adjust the value by starting the
server like this:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysqld_safe --max_connect_errors=10000 &</code></strong>
</pre><p>
If you get this error message for a given host, you should first
verify that there isn't anything wrong with TCP/IP connections
from that host. If you are having network problems, it does you
no good to increase the value of the
<code class="literal">max_connect_errors</code> variable.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="too-many-connections"></a>A.2.6. <code class="literal">Too many connections</code></h3></div></div></div><p>
If you get a <code class="literal">Too many connections</code> error when
you try to connect to the <span><strong class="command">mysqld</strong></span> server, this
means that all available connections are in use by other
clients.
</p><p>
The number of connections allowed is controlled by the
<code class="literal">max_connections</code> system variable. Its default
value is 100. If you need to support more connections, you
should restart <span><strong class="command">mysqld</strong></span> with a larger value for
this variable.
</p><p>
<span><strong class="command">mysqld</strong></span> actually allows
<code class="literal">max_connections+1</code> clients to connect. The
extra connection is reserved for use by accounts that have the
<code class="literal">SUPER</code> privilege. By granting the
<code class="literal">SUPER</code> privilege to administrators and not to
normal users (who should not need it), an administrator can
connect to the server and use <code class="literal">SHOW
PROCESSLIST</code> to diagnose problems even if the maximum
number of unprivileged clients are connected. See
<a href="sql-syntax.html#show-processlist" title="13.5.4.16. SHOW PROCESSLIST Syntax">Section 13.5.4.16, “<code class="literal">SHOW PROCESSLIST</code> Syntax”</a>.
</p><p>
The maximum number of connections MySQL can support depends on
the quality of the thread library on a given platform. Linux or
Solaris should be able to support 500-1000 simultaneous
connections, depending on how much RAM you have and what your
clients are doing. Static Linux binaries provided by MySQL AB
can support up to 4000 connections.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="out-of-memory"></a>A.2.7. <code class="literal">Out of memory</code></h3></div></div></div><p>
If you issue a query using the <span><strong class="command">mysql</strong></span> client
program and receive an error like the following one, it means
that <span><strong class="command">mysql</strong></span> does not have enough memory to
store the entire query result:
</p><pre class="programlisting">mysql: Out of memory at line 42, 'malloc.c'
mysql: needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)
ERROR 2008: MySQL client ran out of memory
</pre><p>
To remedy the problem, first check whether your query is
correct. Is it reasonable that it should return so many rows? If
not, correct the query and try again. Otherwise, you can invoke
<span><strong class="command">mysql</strong></span> with the <code class="option">--quick</code>
option. This causes it to use the
<code class="literal">mysql_use_result()</code> C API function to retrieve
the result set, which places less of a load on the client (but
more on the server).
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="gone-away"></a>A.2.8. <code class="literal">MySQL server has gone away</code></h3></div></div></div><a class="indexterm" name="id3131927"></a><a class="indexterm" name="id3131936"></a><p>
This section also covers the related <code class="literal">Lost connection to
server during query</code> error.
</p><p>
The most common reason for the <code class="literal">MySQL server has gone
away</code> error is that the server timed out and closed the
connection. In this case, you normally get one of the following
error codes (which one you get is operating system-dependent):
</p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><tbody><tr><td><span class="bold"><strong>Error Code</strong></span></td><td><span class="bold"><strong>Description</strong></span></td></tr><tr><td><code class="literal">CR_SERVER_GONE_ERROR</code></td><td>The client couldn't send a question to the server.</td></tr><tr><td><code class="literal">CR_SERVER_LOST</code></td><td>The client didn't get an error when writing to the server, but it didn't
get a full answer (or any answer) to the question.</td></tr></tbody></table></div><p>
By default, the server closes the connection after eight hours
if nothing has happened. You can change the time limit by
setting the <code class="literal">wait_timeout</code> variable when you
start <span><strong class="command">mysqld</strong></span>. See
<a href="database-administration.html#server-system-variables" title="5.3.3. Server System Variables">Section 5.3.3, “Server System Variables”</a>.
</p><p>
If you have a script, you just have to issue the query again for
the client to do an automatic reconnection. This assumes that
you have automatic reconnection in the client enabled (which is
the default for the <code class="literal">mysql</code> command-line
client).
</p><p>
Some other common reasons for the <code class="literal">MySQL server has gone
away</code> error are:
</p><div class="itemizedlist"><ul type="disc"><li><p>
You (or the db administrator) has killed the running thread
with a <code class="literal">KILL</code> statement or a
<span><strong class="command">mysqladmin kill</strong></span> command.
</p></li><li><p>
You tried to run a query after closing the connection to the
server. This indicates a logic error in the application that
should be corrected.
</p></li><li><p>
You got a timeout from the TCP/IP connection on the client
side. This may happens if you have been using the commands:
<code class="literal">mysql_options(...,
MYSQL_OPT_READ_TIMEOUT,...)</code> or
<code class="literal">mysql_options(...,
MYSQL_OPT_WRITE_TIMEOUT,...)</code>. In this case
increasing the timeout may help solve the problem.
</p></li><li><p>
You have encountered a timeout on the server side and the
automatic reconnection in the client is disabled (the
<code class="literal">reconnect</code> flag in the
<code class="literal">MYSQL</code> structure is equal to 0).
</p></li><li><p>
You are using a windows client and the server had dropped
the connection (probably because
<code class="literal">wait_timeout</code> expired) before the command
was issued.
</p><p>
The problem on windows is that in some cases MySQL doesn't
get an error from the OS when writing to the TCP/IP
connection to the server, but instead gets the error when
trying to read the answer from connection.
</p><p>
In this case, even if the <code class="literal">reconnect</code> flag
in the <code class="literal">MYSQL</code> structure is equal to 1,
MySQL does not automatically reconnect and re-issue the
query as it doesn't know if the server did get the original
query or not.
</p><p>
The solution to this is to either do a
<code class="literal">mysql_ping</code> on the connection if there has
been a long time since the last query (this is what
<code class="literal">MyODBC</code> does) or set
<code class="literal">wait_timeout</code> on the
<span><strong class="command">mysqld</strong></span> server so high that it in practice
never times out.
</p></li><li><p>
You can also get these errors if you send a query to the
server that is incorrect or too large. If
<span><strong class="command">mysqld</strong></span> receives a packet that is too
large or out of order, it assumes that something has gone
wrong with the client and closes the connection. If you need
big queries (for example, if you are working with big
<code class="literal">BLOB</code> columns), you can increase the query
limit by setting the server's
<code class="literal">max_allowed_packet</code> variable, which has a
default value of 1MB. You may also need to increase the
maximum packet size on the client end. More information on
setting the packet size is given in
<a href="problems.html#packet-too-large" title="A.2.9. Packet too large">Section A.2.9, “<code class="literal">Packet too large</code>”</a>.
</p></li><li><p>
You also get a lost connection if you are sending a packet
16MB or larger if your client is older than 4.0.8 and your
server is 4.0.8 and above, or the other way around.
</p></li><li><p>
You may also see the <code class="literal">MySQL server has gone
away</code> error if MySQL is started with the
<code class="option">--skip-networking</code> option.
</p></li><li><p>
You have encountered a bug where the server died while
executing the query.
</p></li></ul></div><p>
You can check whether the MySQL server died and restarted by
executing <span><strong class="command">mysqladmin version</strong></span> and examining
the server's uptime. If the client connection was broken because
<span><strong class="command">mysqld</strong></span> crashed and restarted, you should
concentrate on finding the reason for the crash. Start by
checking whether issuing the query again kills the server again.
See <a href="problems.html#crashing" title="A.4.2. What to Do If MySQL Keeps Crashing">Section A.4.2, “What to Do If MySQL Keeps Crashing”</a>.
</p><p>
You can get more information about the lost connections by
starting mysqld with the <code class="option">--log-warnings=2</code>
option. This logs some of the disconnected errors in the
<code class="literal">hostname.err</code> file. See
<a href="database-administration.html#error-log" title="5.11.1. The Error Log">Section 5.11.1, “The Error Log”</a>.
</p><p>
If you want to create a bug report regarding this problem, be
sure that you include the following information:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Indicate whether or not the MySQL server died. You can find
information about this in the server error log. See
<a href="problems.html#crashing" title="A.4.2. What to Do If MySQL Keeps Crashing">Section A.4.2, “What to Do If MySQL Keeps Crashing”</a>.
</p></li><li><p>
If a specific query kills <span><strong class="command">mysqld</strong></span> and the
tables involved were checked with <code class="literal">CHECK
TABLE</code> before you ran the query, can you provide a
reproducible test case? See
<a href="porting.html#reproduceable-test-case" title="E.1.6. Making a Test Case If You Experience Table Corruption">Section E.1.6, “Making a Test Case If You Experience Table Corruption”</a>.
</p></li><li><p>
What is the value of the <code class="literal">wait_timeout</code>
system variable in the MySQL server? (<span><strong class="command">mysqladmin
variables</strong></span> gives you the value of this variable.)
</p></li><li><p>
Have you tried to run <span><strong class="command">mysqld</strong></span> with the
<code class="option">--log</code> option to determine whether the
problem query appears in the log?
</p></li></ul></div><p>
See also See <a href="problems.html#communication-errors" title="A.2.10. Communication Errors and Aborted Connections">Section A.2.10, “Communication Errors and Aborted Connections”</a>.
</p><p>
See <a href="introduction.html#asking-questions" title="1.7.1.2. Asking Questions or Reporting Bugs">Section 1.7.1.2, “Asking Questions or Reporting Bugs”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="packet-too-large"></a>A.2.9. <code class="literal">Packet too large</code></h3></div></div></div><p>
A communication packet is a single SQL statement sent to the
MySQL server or a single row that is sent to the client.
</p><p>
The largest possible packet that can be transmitted to or from a
MySQL 5.0 server or client is 1GB.
</p><p>
When a MySQL client or the <span><strong class="command">mysqld</strong></span> server
receives a packet bigger than
<code class="literal">max_allowed_packet</code> bytes, it issues a
<code class="literal">Packet too large</code> error and closes the
connection. With some clients, you may also get a <code class="literal">Lost
connection to MySQL server during query</code> error if the
communication packet is too large.
</p><p>
Both the client and the server have their own
<code class="literal">max_allowed_packet</code> variable, so if you want
to handle big packets, you must increase this variable both in
the client and in the server.
</p><p>
If you are using the <span><strong class="command">mysql</strong></span> client program,
its default <code class="literal">max_allowed_packet</code> variable is
16MB. To set a larger value, start <span><strong class="command">mysql</strong></span> like
this:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>mysql --max_allowed_packet=32M</code></strong>
</pre><p>
That sets the packet size to 32MB.
</p><p>
The server's default <code class="literal">max_allowed_packet</code> value
is 1MB. You can increase this if the server needs to handle big
queries (for example, if you are working with big
<code class="literal">BLOB</code> columns). For example, to set the
variable to 16MB, start the server like this:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>mysqld --max_allowed_packet=16M</code></strong>
</pre><p>
You can also use an option file to set
<code class="literal">max_allowed_packet</code>. For example, to set the
size for the server to 16MB, add the following lines in an
option file:
</p><pre class="programlisting">[mysqld]
max_allowed_packet=16M
</pre><p>
It is safe to increase the value of this variable because the
extra memory is allocated only when needed. For example,
<span><strong class="command">mysqld</strong></span> allocates more memory only when you
issue a long query or when <span><strong class="command">mysqld</strong></span> must return
a large result row. The small default value of the variable is a
precaution to catch incorrect packets between the client and
server and also to ensure that you do not run out of memory by
using large packets accidentally.
</p><p>
You can also get strange problems with large packets if you are
using large <code class="literal">BLOB</code> values but have not given
<span><strong class="command">mysqld</strong></span> access to enough memory to handle the
query. If you suspect this is the case, try adding
<span><strong class="command">ulimit -d 256000</strong></span> to the beginning of the
<span><strong class="command">mysqld_safe</strong></span> script and restarting
<span><strong class="command">mysqld</strong></span>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="communication-errors"></a>A.2.10. Communication Errors and Aborted Connections</h3></div></div></div><a class="indexterm" name="id3132576"></a><a class="indexterm" name="id3132583"></a><a class="indexterm" name="id3132590"></a><p>
The server error log can be a useful source of information about
connection problems. See <a href="database-administration.html#error-log" title="5.11.1. The Error Log">Section 5.11.1, “The Error Log”</a>. If you
start the server with the <code class="option">--log-warnings</code>
option, you might find messages like this in your error log:
</p><pre class="programlisting">010301 14:38:23 Aborted connection 854 to db: 'users' user: 'josh'
</pre><p>
If <code class="literal">Aborted connections</code> messages appear in the
error log, the cause can be any of the following:
</p><div class="itemizedlist"><ul type="disc"><li><p>
The client program did not call
<code class="literal">mysql_close()</code> before exiting.
</p></li><li><p>
The client had been sleeping more than
<code class="literal">wait_timeout</code> or
<code class="literal">interactive_timeout</code> seconds without
issuing any requests to the server. See
<a href="database-administration.html#server-system-variables" title="5.3.3. Server System Variables">Section 5.3.3, “Server System Variables”</a>.
</p></li><li><p>
The client program ended abruptly in the middle of a data
transfer.
</p></li></ul></div><p>
When any of these things happen, the server increments the
<code class="literal">Aborted_clients</code> status variable.
</p><p>
The server increments the <code class="literal">Aborted_connects</code>
status variable when the following things happen:
</p><div class="itemizedlist"><ul type="disc"><li><p>
A client doesn't have privileges to connect to a database.
</p></li><li><p>
A client uses an incorrect password.
</p></li><li><p>
A connection packet doesn't contain the right information.
</p></li><li><p>
It takes more than <code class="literal">connect_timeout</code>
seconds to get a connect packet. See
<a href="database-administration.html#server-system-variables" title="5.3.3. Server System Variables">Section 5.3.3, “Server System Variables”</a>.
</p></li></ul></div><p>
If these kinds of things happen, it might indicate that someone
is trying to break into your server!
</p><p>
Other reasons for problems with aborted clients or aborted
connections:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Use of Ethernet protocol with Linux, both half and full
duplex. Many Linux Ethernet drivers have this bug. You
should test for this bug by transferring a huge file via FTP
between the client and server machines. If a transfer goes
in burst-pause-burst-pause mode, you are experiencing a
Linux duplex syndrome. The only solution is switching the
duplex mode for both your network card and hub/switch to
either full duplex or to half duplex and testing the results
to determine the best setting.
</p></li><li><p>
Some problem with the thread library that causes interrupts
on reads.
</p></li><li><p>
Badly configured TCP/IP.
</p></li><li><p>
Faulty Ethernets, hubs, switches, cables, and so forth. This
can be diagnosed properly only by replacing hardware.
</p></li><li><p>
The <code class="literal">max_allowed_packet</code> variable value is
too small or queries require more memory than you have
allocated for <span><strong class="command">mysqld</strong></span>. See
<a href="problems.html#packet-too-large" title="A.2.9. Packet too large">Section A.2.9, “<code class="literal">Packet too large</code>”</a>.
</p></li></ul></div><p>
See also See <a href="problems.html#gone-away" title="A.2.8. MySQL server has gone away">Section A.2.8, “<code class="literal">MySQL server has gone away</code>”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="full-table"></a>A.2.11. <code class="literal">The table is full</code></h3></div></div></div><a class="indexterm" name="id3132842"></a><p>
There are several ways a full-table error can occur:
</p><div class="itemizedlist"><ul type="disc"><li><p>
You are using a MySQL server older than 3.23 and an
in-memory temporary table becomes larger than
<code class="literal">tmp_table_size</code> bytes. To avoid this
problem, you can use the <code class="literal">-O
tmp_table_size=<em class="replaceable"><code>val</code></em></code>
option to make <span><strong class="command">mysqld</strong></span> increase the
temporary table size or use the SQL option
<code class="literal">SQL_BIG_TABLES</code> before you issue the
problematic query. See <a href="sql-syntax.html#set-option" title="13.5.3. SET Syntax">Section 13.5.3, “<code class="literal">SET</code> Syntax”</a>.
</p><p>
You can also start <span><strong class="command">mysqld</strong></span> with the
<code class="option">--big-tables</code> option. This is exactly the
same as using <code class="literal">SQL_BIG_TABLES</code> for all
queries.
</p><p>
As of MySQL 3.23, this problem should not occur. If an
in-memory temporary table becomes larger than
<code class="literal">tmp_table_size</code>, the server automatically
converts it to a disk-based <code class="literal">MyISAM</code> table.
</p></li><li><p>
You are using <code class="literal">InnoDB</code> tables and run out
of room in the <code class="literal">InnoDB</code> tablespace. In this
case, the solution is to extend the
<code class="literal">InnoDB</code> tablespace. See
<a href="storage-engines.html#adding-and-removing" title="14.2.7. Adding and Removing InnoDB Data and Log Files">Section 14.2.7, “Adding and Removing <code class="literal">InnoDB</code> Data and Log Files”</a>.
</p></li><li><p>
You are using <code class="literal">ISAM</code> or
<code class="literal">MyISAM</code> tables on an operating system that
supports files only up to 2GB in size and you have hit this
limit for the data file or index file.
</p></li><li><p>
You are using a <code class="literal">MyISAM</code> table and the
space required for the table exceeds what is allowed by the
internal pointer size. If you don't specify the
<code class="literal">MAX_ROWS</code> table option when you create a
table, MySQL uses the
<code class="literal">myisam_data_pointer_size</code> system variable.
From MySQL 5.0.6 on, the default value is 6 bytes, which is
enough to allow 65,536TB of data. Before MySQL 5.0.6, the
default value is 4 bytes, which is enough to allow only 4GB
of data. See <a href="database-administration.html#server-system-variables" title="5.3.3. Server System Variables">Section 5.3.3, “Server System Variables”</a>.
</p><p>
You can check the maximum data/index sizes by using this
statement:
</p><pre class="programlisting">SHOW TABLE STATUS FROM database LIKE '<em class="replaceable"><code>tbl_name</code></em>';
</pre><p>
You also can use <span><strong class="command">myisamchk -dv
/path/to/table-index-file</strong></span>.
</p><p>
If the pointer size is too small, you can fix the problem by
using <code class="literal">ALTER TABLE</code>:
</p><pre class="programlisting">ALTER TABLE <em class="replaceable"><code>tbl_name</code></em> MAX_ROWS=1000000000 AVG_ROW_LENGTH=<em class="replaceable"><code>nnn</code></em>;
</pre><p>
You have to specify <code class="literal">AVG_ROW_LENGTH</code> only
for tables with <code class="literal">BLOB</code> or
<code class="literal">TEXT</code> columns; in this case, MySQL can't
optimize the space required based only on the number of
rows.
</p></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="cannot-create"></a>A.2.12. <code class="literal">Can't create/write to file</code></h3></div></div></div><a class="indexterm" name="id3133067"></a><p>
If you get an error of the following type for some queries, it
means that MySQL cannot create a temporary file for the result
set in the temporary directory:
</p><pre class="programlisting">Can't create/write to file '\\sqla3fe_0.ism'.
</pre><p>
The preceding error is a typical message for Windows; the Unix
message is similar.
</p><p>
One fix is to start <span><strong class="command">mysqld</strong></span> with the
<code class="option">--tmpdir</code> option or to add the option to the
<code class="literal">[mysqld]</code> section of your option file. For
example, to specify a directory of <code class="filename">C:\temp</code>,
use these lines:
</p><pre class="programlisting">[mysqld]
tmpdir=C:/temp
</pre><p>
The <code class="filename">C:\temp</code> directory must exist and have
sufficient space for the MySQL server to write to. See
<a href="using-mysql-programs.html#option-files" title="4.3.2. Using Option Files">Section 4.3.2, “Using Option Files”</a>.
</p><p>
Another cause of this error can be permissions issues. Make sure
that the MySQL server can write to the <code class="literal">tmpdir</code>
directory.
</p><p>
Check also the error code that you get with
<span><strong class="command">perror</strong></span>. One reason the server cannot write to
a table is that the filesystem is full:
</p><pre class="programlisting">shell> <strong class="userinput"><code>perror 28</code></strong>
Error code 28: No space left on device
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="commands-out-of-sync"></a>A.2.13. <code class="literal">Commands out of sync</code></h3></div></div></div><a class="indexterm" name="id3133169"></a><p>
If you get <code class="literal">Commands out of sync; you can't run this
command now</code> in your client code, you are calling
client functions in the wrong order.
</p><p>
This can happen, for example, if you are using
<code class="literal">mysql_use_result()</code> and try to execute a new
query before you have called
<code class="literal">mysql_free_result()</code>. It can also happen if
you try to execute two queries that return data without calling
<code class="literal">mysql_use_result()</code> or
<code class="literal">mysql_store_result()</code> in between.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ignoring-user"></a>A.2.14. <code class="literal">Ignoring user</code></h3></div></div></div><p>
If you get the following error, it means that when
<span><strong class="command">mysqld</strong></span> was started or when it reloaded the
grant tables, it found an account in the <code class="literal">user</code>
table that had an invalid password.
</p><p>
<code class="literal">Found wrong password for user
'<em class="replaceable"><code>some_user</code></em>'@'<em class="replaceable"><code>some_host</code></em>';
ignoring user</code>
</p><p>
As a result, the account is simply ignored by the permission
system.
</p><p>
The following list indicates possible causes of and fixes for
this problem:
</p><div class="itemizedlist"><ul type="disc"><li><p>
You may be running a new version of
<span><strong class="command">mysqld</strong></span> with an old
<code class="literal">user</code> table. You can check this by
executing <span><strong class="command">mysqlshow mysql user</strong></span> to see
whether the <code class="literal">Password</code> column is shorter
than 16 characters. If so, you can correct this condition by
running the <code class="literal">scripts/add_long_password</code>
script.
</p></li><li><p>
The account has an old password (eight characters long) and
you didn't start <span><strong class="command">mysqld</strong></span> with the
<code class="option">--old-protocol</code> option. Update the account
in the <code class="literal">user</code> table to have a new password
or restart <span><strong class="command">mysqld</strong></span> with the
<code class="option">--old-protocol</code> option.
</p></li><li><p>
<a class="indexterm" name="id3133326"></a>
You have specified a password in the <code class="literal">user</code>
table without using the <code class="literal">PASSWORD()</code>
function. Use <span><strong class="command">mysql</strong></span> to update the account
in the <code class="literal">user</code> table with a new password,
making sure to use the <code class="literal">PASSWORD()</code>
function:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>UPDATE user SET Password=PASSWORD('<em class="replaceable"><code>newpwd</code></em>')</code></strong>
-> <strong class="userinput"><code>WHERE User='<em class="replaceable"><code>some_user</code></em>' AND Host='<em class="replaceable"><code>some_host</code></em>';</code></strong>
</pre></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="cannot-find-table"></a>A.2.15. <code class="literal">Table '<em class="replaceable"><code>tbl_name</code></em>' doesn't exist</code></h3></div></div></div><p>
If you get either of the following errors, it usually means that
no table exists in the current database with the given name:
</p><pre class="programlisting">Table '<em class="replaceable"><code>tbl_name</code></em>' doesn't exist
Can't find file: '<em class="replaceable"><code>tbl_name</code></em>' (errno: 2)
</pre><p>
In some cases, it may be that the table does exist but that you
are referring to it incorrectly:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Because MySQL uses directories and files to store databases
and tables, database and table names are case sensitive if
they are located on a filesystem that has case-sensitive
filenames.
</p></li><li><p>
Even for filesystems that are not case sensitive, such as on
Windows, all references to a given table within a query must
use the same lettercase.
</p></li></ul></div><p>
You can check which tables are in the current database with
<code class="literal">SHOW TABLES</code>. See <a href="sql-syntax.html#show" title="13.5.4. SHOW Syntax">Section 13.5.4, “<code class="literal">SHOW</code> Syntax”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="cannot-initialize-character-set"></a>A.2.16. <code class="literal">Can't initialize character set</code></h3></div></div></div><a class="indexterm" name="id3133472"></a><p>
You might see an error like this if you have character set
problems:
</p><pre class="programlisting">MySQL Connection Failed: Can't initialize character set charset_name
</pre><p>
This error can have any of the following causes:
</p><div class="itemizedlist"><ul type="disc"><li><p>
The character set is a multi-byte character set and you have
no support for the character set in the client. In this
case, you need to recompile the client by running
<span><strong class="command">configure</strong></span> with the
<code class="option">--with-charset=<em class="replaceable"><code>charset_name</code></em></code>
or
<code class="option">--with-extra-charsets=<em class="replaceable"><code>charset_name</code></em></code>
option. See <a href="installing.html#configure-options" title="2.8.2. Typical configure Options">Section 2.8.2, “Typical <span><strong class="command">configure</strong></span> Options”</a>.
</p><p>
All standard MySQL binaries are compiled with
<code class="option">--with-extra-character-sets=complex</code>, which
enables support for all multi-byte character sets. See
<a href="database-administration.html#character-sets" title="5.10.1. The Character Set Used for Data and Sorting">Section 5.10.1, “The Character Set Used for Data and Sorting”</a>.
</p></li><li><p>
The character set is a simple character set that is not
compiled into <span><strong class="command">mysqld</strong></span>, and the character
set definition files are not in the place where the client
expects to find them.
</p><p>
In this case, you need to use one of the following methods
to solve the problem:
</p><div class="itemizedlist"><ul type="circle"><li><p>
Recompile the client with support for the character set.
See <a href="installing.html#configure-options" title="2.8.2. Typical configure Options">Section 2.8.2, “Typical <span><strong class="command">configure</strong></span> Options”</a>.
</p></li><li><p>
Specify to the client the directory where the character
set definition files are located. For many clients, you
can do this with the
<code class="option">--character-sets-dir</code> option.
</p></li><li><p>
Copy the character definition files to the path where
the client expects them to be.
</p></li></ul></div></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="not-enough-file-handles"></a>A.2.17. File Not Found</h3></div></div></div><p>
If you get <code class="literal">ERROR '...' not found (errno: 23)</code>,
<code class="literal">Can't open file: ... (errno: 24)</code>, or any
other error with <code class="literal">errno 23</code> or <code class="literal">errno
24</code> from MySQL, it means that you haven't allocated
enough file descriptors for the MySQL server. You can use the
<span><strong class="command">perror</strong></span> utility to get a description of what
the error number means:
</p><pre class="programlisting">shell> <strong class="userinput"><code>perror 23</code></strong>
Error code 23: File table overflow
shell> <strong class="userinput"><code>perror 24</code></strong>
Error code 24: Too many open files
shell> <strong class="userinput"><code>perror 11</code></strong>
Error code 11: Resource temporarily unavailable
</pre><p>
The problem here is that <span><strong class="command">mysqld</strong></span> is trying to
keep open too many files simultaneously. You can either tell
<span><strong class="command">mysqld</strong></span> not to open so many files at once or
increase the number of file descriptors available to
<span><strong class="command">mysqld</strong></span>.
</p><p>
To tell <span><strong class="command">mysqld</strong></span> to keep open fewer files at a
time, you can make the table cache smaller by reducing the value
of the <code class="literal">table_cache</code> system variable (the
default value is 64). Reducing the value of
<code class="literal">max_connections</code> also reduces the number of
open files (the default value is 100).
</p><a class="indexterm" name="id3133696"></a><p>
To change the number of file descriptors available to
<span><strong class="command">mysqld</strong></span>, you can use the
<code class="option">--open-files-limit</code> option to
<span><strong class="command">mysqld_safe</strong></span> or (as of MySQL 3.23.30) set the
<code class="literal">open_files_limit</code> system variable. See
<a href="database-administration.html#server-system-variables" title="5.3.3. Server System Variables">Section 5.3.3, “Server System Variables”</a>. The easiest way to
set these values is to add an option to your option file. See
<a href="using-mysql-programs.html#option-files" title="4.3.2. Using Option Files">Section 4.3.2, “Using Option Files”</a>. If you have an old version of
<span><strong class="command">mysqld</strong></span> that doesn't support setting the open
files limit, you can edit the <span><strong class="command">mysqld_safe</strong></span>
script. There is a commented-out line <span><strong class="command">ulimit -n
256</strong></span> in the script. You can remove the
‘<code class="literal">#</code>’ character to uncomment this
line, and change the number <code class="literal">256</code> to set the
number of file descriptors to be made available to
<span><strong class="command">mysqld</strong></span>.
</p><p>
<code class="option">--open-files-limit</code> and
<span><strong class="command">ulimit</strong></span> can increase the number of file
descriptors, but only up to the limit imposed by the operating
system. There is also a “<span class="quote">hard</span>” limit that can be
overridden only if you start <span><strong class="command">mysqld_safe</strong></span> or
<span><strong class="command">mysqld</strong></span> as <code class="literal">root</code> (just
remember that you also need to start the server with the
<code class="option">--user</code> option in this case so that it does not
continue to run as <code class="literal">root</code> after it starts up).
If you need to increase the operating system limit on the number
of file descriptors available to each process, consult the
documentation for your system.
</p><p>
<span class="bold"><strong>Note</strong></span>: If you run the
<span><strong class="command">tcsh</strong></span> shell, <span><strong class="command">ulimit</strong></span> does
not work! <span><strong class="command">tcsh</strong></span> also reports incorrect values
when you ask for the current limits. In this case, you should
start <span><strong class="command">mysqld_safe</strong></span> using
<span><strong class="command">sh</strong></span>.
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="installation-issues"></a>A.3. Installation-Related Issues</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="problems.html#link-errors">A.3.1. Problems Linking to the MySQL Client Library</a></span></dt><dt><span class="section"><a href="problems.html#changing-mysql-user">A.3.2. How to Run MySQL as a Normal User</a></span></dt><dt><span class="section"><a href="problems.html#file-permissions">A.3.3. Problems with File Permissions</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="link-errors"></a>A.3.1. Problems Linking to the MySQL Client Library</h3></div></div></div><a class="indexterm" name="id3133862"></a><a class="indexterm" name="id3133872"></a><a class="indexterm" name="id3133882"></a><p>
When you are linking an application program to use the MySQL
client library, you might get undefined reference errors for
symbols that start with <code class="literal">mysql_</code>, such as those
shown here:
</p><pre class="programlisting">/tmp/ccFKsdPa.o: In function `main':
/tmp/ccFKsdPa.o(.text+0xb): undefined reference to `mysql_init'
/tmp/ccFKsdPa.o(.text+0x31): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x57): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x69): undefined reference to `mysql_error'
/tmp/ccFKsdPa.o(.text+0x9a): undefined reference to `mysql_close'
</pre><p>
You should be able to solve this problem by adding
<code class="literal">-Ldir_path -lmysqlclient</code> at the end of your
link command, where <code class="literal">dir_path</code> represents the
pathname of the directory where the client library is located.
To determine the correct directory, try this command:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysql_config --libs</code></strong>
</pre><p>
The output from <span><strong class="command">mysql_config</strong></span> might indicate
other libraries that should be specified on the link command as
well.
</p><p>
If you get <code class="literal">undefined reference</code> errors for the
<code class="literal">uncompress</code> or <code class="literal">compress</code>
function, add <code class="literal">-lz</code> to the end of your link
command and try again.
</p><p>
If you get <code class="literal">undefined reference</code> errors for a
function that should exist on your system, such as
<code class="literal">connect</code>, check the manual page for the
function in question to determine which libraries you should add
to the link command.
</p><p>
You might get <code class="literal">undefined reference</code> errors such
as the following for functions that don't exist on your system:
</p><pre class="programlisting">mf_format.o(.text+0x201): undefined reference to `__lxstat'
</pre><p>
This usually means that your MySQL client library was compiled
on a system that is not 100% compatible with yours. In this
case, you should download the latest MySQL source distribution
and compile MySQL yourself. See
<a href="installing.html#installing-source" title="2.8. MySQL Installation Using a Source Distribution">Section 2.8, “MySQL Installation Using a Source Distribution”</a>.
</p><p>
You might get undefined reference errors at runtime when you try
to execute a MySQL program. If these errors specify symbols that
start with <code class="literal">mysql_</code> or indicate that the
<code class="literal">mysqlclient</code> library can't be found, it means
that your system can't find the shared
<code class="filename">libmysqlclient.so</code> library. The fix for this
is to tell your system to search for shared libraries where the
library is located. Use whichever of the following methods is
appropriate for your system:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Add the path to the directory where
<code class="filename">libmysqlclient.so</code> is located to the
<code class="literal">LD_LIBRARY_PATH</code> environment variable.
</p></li><li><p>
Add the path to the directory where
<code class="filename">libmysqlclient.so</code> is located to the
<code class="literal">LD_LIBRARY</code> environment variable.
</p></li><li><p>
Copy <code class="filename">libmysqlclient.so</code> to some
directory that is searched by your system, such as
<code class="filename">/lib</code>, and update the shared library
information by executing <code class="literal">ldconfig</code>.
</p></li></ul></div><p>
Another way to solve this problem is by linking your program
statically with the <code class="literal">-static</code> option, or by
removing the dynamic MySQL libraries before linking your code.
Before trying the second method, you should be sure that no
other programs are using the dynamic libraries.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="changing-mysql-user"></a>A.3.2. How to Run MySQL as a Normal User</h3></div></div></div><a class="indexterm" name="id3134114"></a><a class="indexterm" name="id3134125"></a><p>
On Windows, you can run the server as a Windows service using a
normal user account.
</p><p>
On Unix, the MySQL server <span><strong class="command">mysqld</strong></span> can be
started and run by any user. However, you should avoid running
the server as the Unix <code class="literal">root</code> user for security
reasons. In order to change <span><strong class="command">mysqld</strong></span> to run as
a normal unprivileged Unix user
<em class="replaceable"><code>user_name</code></em>, you must do the following:
</p><div class="orderedlist"><ol type="1"><li><p>
Stop the server if it's running (use <span><strong class="command">mysqladmin
shutdown</strong></span>).
</p></li><li><p>
Change the database directories and files so that
<em class="replaceable"><code>user_name</code></em> has privileges to read
and write files in them (you might need to do this as the
Unix <code class="literal">root</code> user):
</p><pre class="programlisting">shell> <strong class="userinput"><code>chown -R <em class="replaceable"><code>user_name</code></em> <em class="replaceable"><code>/path/to/mysql/datadir</code></em></code></strong>
</pre><p>
If you do not do this, the server is not able to access
databases or tables when it runs as
<em class="replaceable"><code>user_name</code></em>.
</p><p>
If directories or files within the MySQL data directory are
symbolic links, you'll also need to follow those links and
change the directories and files they point to.
<code class="literal">chown -R</code> might not follow symbolic links
for you.
</p></li><li><p>
Start the server as user
<em class="replaceable"><code>user_name</code></em>. If you are using MySQL
3.22 or later, another alternative is to start
<span><strong class="command">mysqld</strong></span> as the Unix
<code class="literal">root</code> user and use the
<code class="option">--user=<em class="replaceable"><code>user_name</code></em></code>
option. <span><strong class="command">mysqld</strong></span> starts up, then switches
to run as the Unix user <em class="replaceable"><code>user_name</code></em>
before accepting any connections.
</p></li><li><p>
To start the server as the given user automatically at
system startup time, specify the username by adding a
<code class="literal">user</code> option to the
<code class="literal">[mysqld]</code> group of the
<code class="filename">/etc/my.cnf</code> option file or the
<code class="filename">my.cnf</code> option file in the server's data
directory. For example:
</p><pre class="programlisting">[mysqld]
user=<em class="replaceable"><code>user_name</code></em>
</pre></li></ol></div><p>
If your Unix machine itself isn't secured, you should assign
passwords to the MySQL <code class="literal">root</code> accounts in the
grant tables. Otherwise, any user with a login account on that
machine can run the <span><strong class="command">mysql</strong></span> client with a
<code class="option">--user=root</code> option and perform any operation.
(It is a good idea to assign passwords to MySQL accounts in any
case, but especially so when other login accounts exist on the
server host.) See <a href="installing.html#post-installation" title="2.9. Post-Installation Setup and Testing">Section 2.9, “Post-Installation Setup and Testing”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="file-permissions"></a>A.3.3. Problems with File Permissions</h3></div></div></div><a class="indexterm" name="id3134338"></a><a class="indexterm" name="id3134348"></a><a class="indexterm" name="id3134358"></a><a class="indexterm" name="id3134368"></a><a class="indexterm" name="id3134378"></a><p>
If you have problems with file permissions, the
<code class="literal">UMASK</code> environment variable might be set
incorrectly when <span><strong class="command">mysqld</strong></span> starts. For example,
MySQL might issue the following error message when you create a
table:
</p><pre class="programlisting">ERROR: Can't find file: 'path/with/filename.frm' (Errcode: 13)
</pre><p>
The default <code class="literal">UMASK</code> value is
<code class="literal">0660</code>. You can change this behavior by
starting <span><strong class="command">mysqld_safe</strong></span> as follows:
</p><pre class="programlisting">shell> <strong class="userinput"><code>UMASK=384 # = 600 in octal</code></strong>
shell> <strong class="userinput"><code>export UMASK</code></strong>
shell> <strong class="userinput"><code>mysqld_safe &</code></strong>
</pre><a class="indexterm" name="id3134440"></a><a class="indexterm" name="id3134450"></a><p>
By default, MySQL creates database and <code class="literal">RAID</code>
directories with an access permission value of
<code class="literal">0700</code>. You can modify this behavior by setting
the <code class="literal">UMASK_DIR</code> variable. If you set its value,
new directories are created with the combined
<code class="literal">UMASK</code> and <code class="literal">UMASK_DIR</code>
values. For example, if you want to give group access to all new
directories, you can do this:
</p><pre class="programlisting">shell> <strong class="userinput"><code>UMASK_DIR=504 # = 770 in octal</code></strong>
shell> <strong class="userinput"><code>export UMASK_DIR</code></strong>
shell> <strong class="userinput"><code>mysqld_safe &</code></strong>
</pre><p>
In MySQL 3.23.25 and above, MySQL assumes that the value for
<code class="literal">UMASK</code> and <code class="literal">UMASK_DIR</code> is in
octal if it starts with a zero.
</p><p>
See <a href="environment-variables.html" title="Appendix F. Environment Variables">Appendix F, <i>Environment Variables</i></a>.
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="administration-issues"></a>A.4. Administration-Related Issues</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="problems.html#resetting-permissions">A.4.1. How to Reset the Root Password</a></span></dt><dt><span class="section"><a href="problems.html#crashing">A.4.2. What to Do If MySQL Keeps Crashing</a></span></dt><dt><span class="section"><a href="problems.html#full-disk">A.4.3. How MySQL Handles a Full Disk</a></span></dt><dt><span class="section"><a href="problems.html#temporary-files">A.4.4. Where MySQL Stores Temporary Files</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-mysql-sock">A.4.5. How to Protect or Change the MySQL Socket File <code class="filename">/tmp/mysql.sock</code></a></span></dt><dt><span class="section"><a href="problems.html#timezone-problems">A.4.6. Time Zone Problems</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="resetting-permissions"></a>A.4.1. How to Reset the Root Password</h3></div></div></div><a class="indexterm" name="id3134552"></a><a class="indexterm" name="id3134562"></a><a class="indexterm" name="id3134572"></a><a class="indexterm" name="id3134582"></a><p>
If you have never set a <code class="literal">root</code> password for
MySQL, the server does not require a password at all for
connecting as <code class="literal">root</code>. However, it is
recommended to set a password for each account. See
<a href="database-administration.html#security-guidelines" title="5.6.1. General Security Guidelines">Section 5.6.1, “General Security Guidelines”</a>.
</p><p>
If you set a <code class="literal">root</code> password previously, but
have forgotten what it was, you can set a new password. The
following procedure is for Windows systems. The procedure for
Unix systems is given later in this section.
</p><p>
The procedure under Windows:
</p><div class="orderedlist"><ol type="1"><li><p>
Log on to your system as Administrator.
</p></li><li><p>
Stop the MySQL server if it is running. For a server that is
running as a Windows service, go to the Services manager:
</p><pre class="programlisting">Start Menu -> Control Panel -> Administrative Tools -> Services
</pre><p>
Then find the MySQL service in the list, and stop it.
</p><p>
If your server is not running as a service, you may need to
use the Task Manager to force it to stop.
</p></li><li><p>
Create a text file and place the following command within it
on a single line:
</p><pre class="programlisting">SET PASSWORD FOR 'root'@'localhost' = PASSWORD('MyNewPassword');
</pre><p>
Save the file with any name. For this example the file will
be <code class="filename">C:\mysql-init.txt</code>.
</p></li><li><p>
Open a console window to get to the DOS command prompt:
</p><pre class="programlisting">Start Menu -> Run -> cmd
</pre></li><li><p>
We are assuming that you installed MySQL to
<code class="filename">C:\mysql</code>. If you installed MySQL to
another location, adjust the following commands accordingly.
</p><p>
At the DOS command prompt, execute this command:
</p><pre class="programlisting">C:\> <strong class="userinput"><code>C:\mysql\bin\mysqld-nt --init-file=C:\mysql-init.txt</code></strong>
</pre><p>
The contents of the file named by the
<code class="option">--init-file</code> option are executed at server
startup, changing the <code class="literal">root</code> password.
After the server has started successfully, you should delete
<code class="filename">C:\mysql-init.txt</code>.
</p><p>
If you install MySQL using the MySQL Installation Wizard,
you may need to specify a <code class="option">--defaults-file</code>
option:
</p><pre class="programlisting">C:\> <strong class="userinput"><code>C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld-nt.exe</code></strong>
--defaults-file="C:\Program Files\MySQL\MySQL Server 5.0\my.ini"
--init-file=C:\mysql-init.txt
</pre><p>
The appropriate <code class="option">--defaults-file</code> setting can
be found using the Services Manager:
</p><pre class="programlisting">Start Menu -> Control Panel -> Administrative Tools -> Services
</pre><p>
Find the MySQL service in the list, right-click on it, and
choose the <code class="literal">Properties</code> option. The
<code class="literal">Path to executable</code> field contains the
<code class="option">--defaults-file</code> setting.
</p></li><li><p>
Stop the MySQL server, then restart it in normal mode again.
If you run the server as a service, start it from the
Windows Services window. If you start the server manually,
use whatever command you normally use.
</p></li><li><p>
You should be able to connect using the new password.
</p></li></ol></div><p>
In a Unix environment, the procedure for resetting the
<code class="literal">root</code> password is as follows:
</p><div class="orderedlist"><ol type="1"><li><p>
Log on to your system as either the Unix
<code class="literal">root</code> user or as the same user that the
<span><strong class="command">mysqld</strong></span> server runs as.
</p></li><li><p>
Locate the <code class="filename">.pid</code> file that contains the
server's process ID. The exact location and name of this
file depend on your distribution, hostname, and
configuration. Common locations are
<code class="filename">/var/lib/mysql/</code>,
<code class="filename">/var/run/mysqld/</code>, and
<code class="filename">/usr/local/mysql/data/</code>. Generally, the
filename has the extension of <code class="filename">.pid</code> and
begins with either <code class="filename">mysqld</code> or your
system's hostname.
</p><p>
You can stop the MySQL server by sending a normal
<code class="literal">kill</code> (not <code class="literal">kill -9</code>) to
the <span><strong class="command">mysqld</strong></span> process, using the pathname of
the <code class="filename">.pid</code> file in the following command:
</p><pre class="programlisting">shell> <strong class="userinput"><code>kill `cat /mysql-data-directory/host_name.pid`</code></strong>
</pre><p>
Note the use of backticks rather than forward quotes with
the <code class="literal">cat</code> command; these cause the output
of <code class="literal">cat</code> to be substituted into the
<code class="literal">kill</code> command.
</p></li><li><p>
Create a text file and place the following command within it
on a single line:
</p><pre class="programlisting">SET PASSWORD FOR 'root'@'localhost' = PASSWORD('MyNewPassword');
</pre><p>
Save the file with any name. For this example the file will
be <code class="filename">~/mysql-init</code>.
</p></li><li><p>
Restart the MySQL server with the special
<code class="option">--init-file=~/mysql-init</code> option:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysqld_safe --init-file=~/mysql-init &</code></strong>
</pre><p>
The contents of the init-file are executed at server
startup, changing the root password. After the server has
started successfully you should delete
<code class="filename">~/mysql-init</code>.
</p></li><li><p>
You should be able to connect using the new password.
</p></li></ol></div><p>
Alternatively, on any platform, you can set the new password
using the <span><strong class="command">mysql</strong></span> client(but this approach is
less secure):
</p><div class="orderedlist"><ol type="1"><li><p>
Stop <span><strong class="command">mysqld</strong></span> and restart it with the
<code class="option">--skip-grant-tables --user=root</code> options
(Windows users omit the <code class="option">--user=root</code>
portion).
</p></li><li><p>
Connect to the <span><strong class="command">mysqld</strong></span> server with this
command:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysql -u root</code></strong>
</pre></li><li><p>
Issue the following statements in the
<span><strong class="command">mysql</strong></span> client:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>UPDATE mysql.user SET Password=PASSWORD('<em class="replaceable"><code>newpwd</code></em>')</code></strong>
-> <strong class="userinput"><code>WHERE User='root';</code></strong>
mysql> <strong class="userinput"><code>FLUSH PRIVILEGES;</code></strong>
</pre><p>
Replace “<span class="quote"><em class="replaceable"><code>newpwd</code></em></span>”
with the actual <code class="literal">root</code> password that you
want to use.
</p></li><li><p>
You should be able to connect using the new password.
</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="crashing"></a>A.4.2. What to Do If MySQL Keeps Crashing</h3></div></div></div><a class="indexterm" name="id3135092"></a><p>
Each MySQL version is tested on many platforms before it is
released. This doesn't mean that there are no bugs in MySQL, but
if there are bugs, they should be very few and can be hard to
find. If you have a problem, it always helps if you try to find
out exactly what crashes your system, because you have a much
better chance of getting the problem fixed quickly.
</p><p>
First, you should try to find out whether the problem is that
the <span><strong class="command">mysqld</strong></span> server dies or whether your
problem has to do with your client. You can check how long your
<span><strong class="command">mysqld</strong></span> server has been up by executing
<span><strong class="command">mysqladmin version</strong></span>. If
<span><strong class="command">mysqld</strong></span> has died and restarted, you may find
the reason by looking in the server's error log. See
<a href="database-administration.html#error-log" title="5.11.1. The Error Log">Section 5.11.1, “The Error Log”</a>.
</p><p>
On some systems, you can find in the error log a stack trace of
where <span><strong class="command">mysqld</strong></span> died that you can resolve with
the <code class="literal">resolve_stack_dump</code> program. See
<a href="porting.html#using-stack-trace" title="E.1.4. Using a Stack Trace">Section E.1.4, “Using a Stack Trace”</a>. Note that the variable
values written in the error log may not always be 100% correct.
</p><p>
Many server crashes are caused by corrupted data files or index
files. MySQL updates the files on disk with the
<code class="literal">write()</code> system call after every SQL statement
and before the client is notified about the result. (This is not
true if you are running with <code class="option">--delay-key-write</code>,
in which case data files are written but not index files.) This
means that data file contents are safe even if
<span><strong class="command">mysqld</strong></span> crashes, because the operating system
ensures that the unflushed data is written to disk. You can
force MySQL to flush everything to disk after every SQL
statement by starting <span><strong class="command">mysqld</strong></span> with the
<code class="option">--flush</code> option.
</p><p>
The preceding means that normally you should not get corrupted
tables unless one of the following happens:
</p><div class="itemizedlist"><ul type="disc"><li><p>
The MySQL server or the server host was killed in the middle
of an update.
</p></li><li><p>
You have found a bug in <span><strong class="command">mysqld</strong></span> that
caused it to die in the middle of an update.
</p></li><li><p>
Some external program is manipulating data files or index
files at the same time as <span><strong class="command">mysqld</strong></span> without
locking the table properly.
</p></li><li><p>
You are running many <span><strong class="command">mysqld</strong></span> servers using
the same data directory on a system that doesn't support
good filesystem locks (normally handled by the
<code class="literal">lockd</code> lock manager), or you are running
multiple servers with the
<code class="option">--skip-external-locking</code> option.
</p></li><li><p>
You have a crashed data file or index file that contains
very corrupt data that confused <span><strong class="command">mysqld</strong></span>.
</p></li><li><p>
You have found a bug in the data storage code. This isn't
likely, but it's at least possible. In this case, you can
try to change the table type to another storage engine by
using <code class="literal">ALTER TABLE</code> on a repaired copy of
the table.
</p></li></ul></div><p>
Because it is very difficult to know why something is crashing,
first try to check whether things that work for others crash for
you. Please try the following things:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Stop the <span><strong class="command">mysqld</strong></span> server with
<span><strong class="command">mysqladmin shutdown</strong></span>, run
<span><strong class="command">myisamchk --silent --force */*.MYI</strong></span> from
the data directory to check all <code class="literal">MyISAM</code>
tables, and restart <span><strong class="command">mysqld</strong></span>. This ensures
that you are running from a clean state. See
<a href="database-administration.html" title="Chapter 5. Database Administration">Chapter 5, <i>Database Administration</i></a>.
</p></li><li><p>
Start <span><strong class="command">mysqld</strong></span> with the
<code class="option">--log</code> option and try to determine from the
information written to the log whether some specific query
kills the server. About 95% of all bugs are related to a
particular query. Normally, this is one of the last queries
in the log file just before the server restarts. See
<a href="database-administration.html#query-log" title="5.11.2. The General Query Log">Section 5.11.2, “The General Query Log”</a>. If you can repeatedly kill
MySQL with a specific query, even when you have checked all
tables just before issuing it, then you have been able to
locate the bug and should submit a bug report for it. See
<a href="introduction.html#bug-reports" title="1.7.1.3. How to Report Bugs or Problems">Section 1.7.1.3, “How to Report Bugs or Problems”</a>.
</p></li><li><p>
Try to make a test case that we can use to repeat the
problem. See <a href="porting.html#reproduceable-test-case" title="E.1.6. Making a Test Case If You Experience Table Corruption">Section E.1.6, “Making a Test Case If You Experience Table Corruption”</a>.
</p></li><li><p>
Try running the tests in the <code class="filename">mysql-test</code>
directory and the MySQL benchmarks. See
<a href="extending-mysql.html#mysql-test-suite" title="24.1.2. MySQL Test Suite">Section 24.1.2, “MySQL Test Suite”</a>. They should test MySQL
rather well. You can also add code to the benchmarks that
simulates your application. The benchmarks can be found in
the <code class="filename">sql-bench</code> directory in a source
distribution or, for a binary distribution, in the
<code class="filename">sql-bench</code> directory under your MySQL
installation directory.
</p></li><li><p>
Try the <code class="literal">fork_big.pl</code> script. (It is
located in the <code class="filename">tests</code> directory of
source distributions.)
</p></li><li><p>
If you configure MySQL for debugging, it is much easier to
gather information about possible errors if something goes
wrong. Configuring MySQL for debugging causes a safe memory
allocator to be included that can find some errors. It also
provides a lot of output about what is happening.
Reconfigure MySQL with the <code class="option">--with-debug</code> or
<code class="option">--with-debug=full</code> option to
<span><strong class="command">configure</strong></span> and then recompile. See
<a href="porting.html#debugging-server" title="E.1. Debugging a MySQL Server">Section E.1, “Debugging a MySQL Server”</a>.
</p></li><li><p>
Make sure that you have applied the latest patches for your
operating system.
</p></li><li><p>
Use the <code class="option">--skip-external-locking</code> option to
<span><strong class="command">mysqld</strong></span>. On some systems, the
<code class="literal">lockd</code> lock manager does not work
properly; the <code class="option">--skip-external-locking</code>
option tells <span><strong class="command">mysqld</strong></span> not to use external
locking. (This means that you cannot run two
<span><strong class="command">mysqld</strong></span> servers on the same data directory
and that you must be careful if you use
<span><strong class="command">myisamchk</strong></span>. Nevertheless, it may be
instructive to try the option as a test.)
</p></li><li><p>
Have you tried <span><strong class="command">mysqladmin -u root
processlist</strong></span> when <span><strong class="command">mysqld</strong></span> appears
to be running but not responding? Sometimes
<span><strong class="command">mysqld</strong></span> is not comatose even though you
might think so. The problem may be that all connections are
in use, or there may be some internal lock problem.
<span><strong class="command">mysqladmin -u root processlist</strong></span> usually is
able to make a connection even in these cases, and can
provide useful information about the current number of
connections and their status.
</p></li><li><p>
Run the command <span><strong class="command">mysqladmin -i 5 status</strong></span> or
<span><strong class="command">mysqladmin -i 5 -r status</strong></span> in a separate
window to produce statistics while you run your other
queries.
</p></li><li><p>
Try the following:
</p><div class="orderedlist"><ol type="1"><li><p>
Start <span><strong class="command">mysqld</strong></span> from
<span><strong class="command">gdb</strong></span> (or another debugger). See
<a href="porting.html#using-gdb-on-mysqld" title="E.1.3. Debugging mysqld under gdb">Section E.1.3, “Debugging <span><strong class="command">mysqld</strong></span> under <span><strong class="command">gdb</strong></span>”</a>.
</p></li><li><p>
Run your test scripts.
</p></li><li><p>
Print the backtrace and the local variables at the three
lowest levels. In <span><strong class="command">gdb</strong></span>, you can do
this with the following commands when
<span><strong class="command">mysqld</strong></span> has crashed inside
<span><strong class="command">gdb</strong></span>:
</p><pre class="programlisting">backtrace
info local
up
info local
up
info local
</pre><p>
With <span><strong class="command">gdb</strong></span>, you can also examine which
threads exist with <code class="literal">info threads</code> and
switch to a specific thread with <code class="literal">thread
<em class="replaceable"><code>N</code></em></code>, where
<em class="replaceable"><code>N</code></em> is the thread ID.
</p></li></ol></div></li><li><p>
Try to simulate your application with a Perl script to force
MySQL to crash or misbehave.
</p></li><li><p>
Send a normal bug report. See <a href="introduction.html#bug-reports" title="1.7.1.3. How to Report Bugs or Problems">Section 1.7.1.3, “How to Report Bugs or Problems”</a>.
Be even more detailed than usual. Because 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).
</p></li><li><p>
If you have a problem with tables containing dynamic-length
rows and you are using only <code class="literal">VARCHAR</code>
columns (not <code class="literal">BLOB</code> or
<code class="literal">TEXT</code> columns), you can try to change all
<code class="literal">VARCHAR</code> to <code class="literal">CHAR</code> with
<code class="literal">ALTER TABLE</code>. This forces MySQL to use
fixed-size rows. Fixed-size rows take a little extra space,
but are much more tolerant to corruption.
</p><p>
The current dynamic row code has been in use at MySQL AB for
several years with very few problems, but dynamic-length
rows are by nature more prone to errors, so it may be a good
idea to try this strategy to see whether it helps.
</p></li><li><p>
Do not rule out your server hardware when diagnosing
problems. Defective hardware can be the cause of data
corruption. Particular attention should be paid to both RAMS
and hard-drives when troubleshooting hardware.
</p></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="full-disk"></a>A.4.3. How MySQL Handles a Full Disk</h3></div></div></div><a class="indexterm" name="id3135723"></a><a class="indexterm" name="id3135730"></a><p>
This section describes how MySQL responds to disk-full errors
(such as “<span class="quote">no space left on device</span>”), and to
quota-exceeded errors (such as “<span class="quote">write failed</span>” or
“<span class="quote">user block limit reached</span>”).
</p><p>
This section is relevant for writes to <code class="literal">MyISAM</code>
tables. It also applies for writes to binary log files and
binary log index file, except that references to
“<span class="quote">row</span>” and “<span class="quote">record</span>” should be
understood to mean “<span class="quote">event</span>”.
</p><p>
When a disk-full condition occurs, MySQL does the following:
</p><div class="itemizedlist"><ul type="disc"><li><p>
It checks once every minute to see whether there is enough
space to write the current row. If there is enough space, it
continues as if nothing had happened.
</p></li><li><p>
Every 10 minutes it writes an entry to the log file, warning
about the disk-full condition.
</p></li></ul></div><p>
To alleviate the problem, you can take the following actions:
</p><div class="itemizedlist"><ul type="disc"><li><p>
To continue, you only have to free enough disk space to
insert all records.
</p></li><li><p>
To abort the thread, you must use <span><strong class="command">mysqladmin
kill</strong></span>. The thread is aborted the next time it
checks the disk (in one minute).
</p></li><li><p>
Other threads might be waiting for the table that caused the
disk-full condition. If you have several
“<span class="quote">locked</span>” threads, killing the one thread that
is waiting on the disk-full condition allows the other
threads to continue.
</p></li></ul></div><p>
Exceptions to the preceding behavior are when you use
<code class="literal">REPAIR TABLE</code> or <code class="literal">OPTIMIZE
TABLE</code> or when the indexes are created in a batch after
<code class="literal">LOAD DATA INFILE</code> or after an <code class="literal">ALTER
TABLE</code> statement. All of these statements may create
large temporary files that, if left to themselves, would cause
big problems for the rest of the system. If the disk becomes
full while MySQL is doing any of these operations, it removes
the big temporary files and mark the table as crashed. The
exception is that for <code class="literal">ALTER TABLE</code>, the old
table is left unchanged.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="temporary-files"></a>A.4.4. Where MySQL Stores Temporary Files</h3></div></div></div><p>
MySQL uses the value of the <code class="literal">TMPDIR</code>
environment variable as the pathname of the directory in which
to store temporary files. If you don't have
<code class="literal">TMPDIR</code> set, MySQL uses the system default,
which is normally <code class="filename">/tmp</code>,
<code class="filename">/var/tmp</code>, or <code class="filename">/usr/tmp</code>.
If the filesystem containing your temporary file directory is
too small, you can use the <code class="option">--tmpdir</code> option to
<span><strong class="command">mysqld</strong></span> to specify a directory in a filesystem
where you have enough space.
</p><p>
In MySQL 5.0, the <code class="option">--tmpdir</code> option
can be set to a list of several paths that are used in
round-robin fashion. Paths should be separated by colon
characters (‘<code class="literal">:</code>’) on Unix and
semicolon characters (‘<code class="literal">;</code>’) on
Windows, NetWare, and OS/2.
<span class="bold"><strong>Note</strong></span>: To spread the load
effectively, these paths should be located on different
<span class="emphasis"><em>physical</em></span> disks, not different partitions of
the same disk.
</p><p>
If the MySQL server is acting as a replication slave, you should
not set <code class="option">--tmpdir</code> to point to a directory on a
memory-based filesystem or to a directory that is cleared when
the server host restarts. A replication slave needs some of its
temporary files to survive a machine restart so that it can
replicate temporary tables or <code class="literal">LOAD DATA
INFILE</code> operations. If files in the temporary file
directory are lost when the server restarts, replication fails.
</p><p>
MySQL creates all temporary files as hidden files. This ensures
that the temporary files are removed if
<span><strong class="command">mysqld</strong></span> is terminated. The disadvantage of
using hidden files is that you do not see a big temporary file
that fills up the filesystem in which the temporary file
directory is located.
</p><p>
When sorting (<code class="literal">ORDER BY</code> or <code class="literal">GROUP
BY</code>), MySQL normally uses one or two temporary files.
The maximum disk space required is determined by the following
expression:
</p><pre class="programlisting">(length of what is sorted + sizeof(row pointer))
* number of matched rows
* 2
</pre><p>
The row pointer size is usually four bytes, but may grow in the
future for really big tables.
</p><p>
For some <code class="literal">SELECT</code> queries, MySQL also creates
temporary SQL tables. These are not hidden and have names of the
form <code class="filename">SQL_*</code>.
</p><p>
<code class="literal">ALTER TABLE</code> creates a temporary table in the
same directory as the original table.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="problems-with-mysql-sock"></a>A.4.5. How to Protect or Change the MySQL Socket File <code class="filename">/tmp/mysql.sock</code></h3></div></div></div><a class="indexterm" name="id3136056"></a><a class="indexterm" name="id3136067"></a><p>
The default location for the Unix socket file that the server
uses for communication with local clients is
<code class="filename">/tmp/mysql.sock</code>. This might cause problems,
because on some versions of Unix, anyone can delete files in the
<code class="filename">/tmp</code> directory.
</p><p>
On most versions of Unix, you can protect your
<code class="filename">/tmp</code> directory so that files can be deleted
only by their owners or the superuser (<code class="literal">root</code>).
To do this, set the <code class="literal">sticky</code> bit on the
<code class="filename">/tmp</code> directory by logging in as
<code class="literal">root</code> and using the following command:
</p><pre class="programlisting">shell> <strong class="userinput"><code>chmod +t /tmp</code></strong>
</pre><p>
You can check whether the <code class="literal">sticky</code> bit is set
by executing <code class="literal">ls -ld /tmp</code>. If the last
permission character is <code class="literal">t</code>, the bit is set.
</p><a class="indexterm" name="id3136143"></a><p>
Another approach is to change the place where the server creates
the Unix socket file. If you do this, you should also let client
programs know the new location of the file. You can specify the
file location in several ways:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Specify the path in a global or local option file. For
example, put the following lines in
<code class="literal">/etc/my.cnf</code>:
</p><pre class="programlisting">[mysqld]
socket=/path/to/socket
[client]
socket=/path/to/socket
</pre><p>
See <a href="using-mysql-programs.html#option-files" title="4.3.2. Using Option Files">Section 4.3.2, “Using Option Files”</a>.
</p></li><li><p>
Specify a <code class="option">--socket</code> option on the command
line to <span><strong class="command">mysqld_safe</strong></span> and when you run
client programs.
</p></li><li><p>
Set the <code class="literal">MYSQL_UNIX_PORT</code> environment
variable to the path of the Unix socket file.
</p></li><li><p>
Recompile MySQL from source to use a different default Unix
socket file location. Define the path to the file with the
<code class="option">--with-unix-socket-path</code> option when you run
<span><strong class="command">configure</strong></span>. See
<a href="installing.html#configure-options" title="2.8.2. Typical configure Options">Section 2.8.2, “Typical <span><strong class="command">configure</strong></span> Options”</a>.
</p></li></ul></div><p>
You can test whether the new socket location works by attempting
to connect to the server with this command:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysqladmin --socket=/path/to/socket version</code></strong>
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="timezone-problems"></a>A.4.6. Time Zone Problems</h3></div></div></div><a class="indexterm" name="id3136261"></a><a class="indexterm" name="id3136268"></a><a class="indexterm" name="id3136278"></a><a class="indexterm" name="id3136287"></a><p>
If you have a problem with <code class="literal">SELECT NOW()</code>
returning values in GMT and not your local time, you have to
tell the server your current time zone. The same applies if
<code class="literal">UNIX_TIMESTAMP()</code> returns the wrong value.
This should be done for the environment in which the server
runs; for example, in <span><strong class="command">mysqld_safe</strong></span> or
<span><strong class="command">mysql.server</strong></span>. See
<a href="environment-variables.html" title="Appendix F. Environment Variables">Appendix F, <i>Environment Variables</i></a>.
</p><p>
You can set the time zone for the server with the
<code class="option">--timezone=<em class="replaceable"><code>timezone_name</code></em></code>
option to <span><strong class="command">mysqld_safe</strong></span>. You can also set it by
setting the <code class="literal">TZ</code> environment variable before
you start <span><strong class="command">mysqld</strong></span>.
</p><p>
The allowable values for <code class="option">--timezone</code> or
<code class="literal">TZ</code> are system-dependent. Consult your
operating system documentation to see what values are
acceptable.
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="query-issues"></a>A.5. Query-Related Issues</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="problems.html#case-sensitivity">A.5.1. Case Sensitivity in Searches</a></span></dt><dt><span class="section"><a href="problems.html#using-date">A.5.2. Problems Using <code class="literal">DATE</code> Columns</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-null">A.5.3. Problems with <code class="literal">NULL</code> Values</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-alias">A.5.4. Problems with Column Aliases</a></span></dt><dt><span class="section"><a href="problems.html#non-transactional-tables">A.5.5. Rollback Failure for Non-Transactional Tables</a></span></dt><dt><span class="section"><a href="problems.html#deleting-from-related-tables">A.5.6. Deleting Rows from Related Tables</a></span></dt><dt><span class="section"><a href="problems.html#no-matching-rows">A.5.7. Solving Problems with No Matching Rows</a></span></dt><dt><span class="section"><a href="problems.html#problems-with-float">A.5.8. Problems with Floating-Point Comparisons</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="case-sensitivity"></a>A.5.1. Case Sensitivity in Searches</h3></div></div></div><a class="indexterm" name="id3136389"></a><a class="indexterm" name="id3136399"></a><a class="indexterm" name="id3136409"></a><a class="indexterm" name="id3136416"></a><p>
By default, MySQL searches are not case sensitive (although
there are some character sets that are never case insensitive,
such as <code class="literal">czech</code>). This means that if you search
with <code class="literal"><em class="replaceable"><code>col_name</code></em> LIKE
'a%'</code>, you get all column values that start with
<code class="literal">A</code> or <code class="literal">a</code>. If you want to
make this search case sensitive, make sure that one of the
operands has a case sensitive or binary collation. For example,
if you are comparing a column and a string that both have the
<code class="literal">latin1</code> character set, you can use the
<code class="literal">COLLATE</code> operator to cause either operand to
have the <code class="literal">latin1_general_cs</code> or
<code class="literal">latin1_bin</code> collation. For example:
</p><pre class="programlisting"><em class="replaceable"><code>col_name</code></em> COLLATE latin1_general_cs LIKE 'a%'
<em class="replaceable"><code>col_name</code></em> LIKE 'a%' COLLATE latin1_general_cs
<em class="replaceable"><code>col_name</code></em> COLLATE latin1_bin LIKE 'a%'
<em class="replaceable"><code>col_name</code></em> LIKE 'a%' COLLATE latin1_bin
</pre><p>
If you want a column always to be treated in case-sensitive
fashion, declare it with a case sensitive or binary collation.
See <a href="sql-syntax.html#create-table" title="13.1.5. CREATE TABLE Syntax">Section 13.1.5, “<code class="literal">CREATE TABLE</code> Syntax”</a>.
</p><p>
Simple comparison operations (<code class="literal">>=, >, =, <,
<=</code>, sorting, and grouping) are based on each
character's “<span class="quote">sort value.</span>” Characters with the same
sort value (such as ‘<code class="literal">E</code>’,
‘<code class="literal">e</code>’, and
‘<code class="literal">é</code>’) are treated as the same
character.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="using-date"></a>A.5.2. Problems Using <code class="literal">DATE</code> Columns</h3></div></div></div><a class="indexterm" name="id3136539"></a><a class="indexterm" name="id3136548"></a><a class="indexterm" name="id3136558"></a><p>
The format of a <code class="literal">DATE</code> value is
<code class="literal">'YYYY-MM-DD'</code>. According to standard SQL, no
other format is allowed. You should use this format in
<code class="literal">UPDATE</code> expressions and in the
<code class="literal">WHERE</code> clause of <code class="literal">SELECT</code>
statements. For example:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT * FROM <em class="replaceable"><code>tbl_name</code></em> WHERE date >= '2003-05-05';</code></strong>
</pre><p>
As a convenience, MySQL automatically converts a date to a
number if the date is used in a numeric context (and vice
versa). It is also smart enough to allow a
“<span class="quote">relaxed</span>” string form when updating and in a
<code class="literal">WHERE</code> clause that compares a date to a
<code class="literal">TIMESTAMP</code>, <code class="literal">DATE</code>, or
<code class="literal">DATETIME</code> column. (“<span class="quote">Relaxed form</span>”
means that any punctuation character may be used as the
separator between parts. For example,
<code class="literal">'2004-08-15'</code> and
<code class="literal">'2004#08#15'</code> are equivalent.) MySQL can also
convert a string containing no separators (such as
<code class="literal">'20040815'</code>), provided it makes sense as a
date.
</p><p>
When you compare a <code class="literal">DATE</code>,
<code class="literal">TIME</code>, <code class="literal">DATETIME</code>, or
<code class="literal">TIMESTAMP</code> to a constant string with the
<code class="literal"><</code>, <code class="literal"><=</code>,
<code class="literal">=</code>, <code class="literal">>=</code>,
<code class="literal">></code>, or <code class="literal">BETWEEN</code>
operators, MySQL normally converts the string to an internal
long integer for faster comparision (and also for a bit more
“<span class="quote">relaxed</span>” string checking). However, this
conversion is subject to the following exceptions:
</p><div class="itemizedlist"><ul type="disc"><li><p>
When you compare two columns
</p></li><li><p>
When you compare a <code class="literal">DATE</code>,
<code class="literal">TIME</code>, <code class="literal">DATETIME</code>, or
<code class="literal">TIMESTAMP</code> column to an expression
</p></li><li><p>
When you use any other comparison method than those just
listed, such as <code class="literal">IN</code> or
<code class="literal">STRCMP()</code>.
</p></li></ul></div><p>
For these exceptional cases, the comparison is done by
converting the objects to strings and performing a string
comparison.
</p><p>
To keep things safe, assume that strings are compared as strings
and use the appropriate string functions if you want to compare
a temporal value to a string.
</p><p>
The special date <code class="literal">'0000-00-00'</code> can be stored
and retrieved as <code class="literal">'0000-00-00'.</code> When using a
<code class="literal">'0000-00-00'</code> date through MyODBC, it is
automatically converted to <code class="literal">NULL</code> in MyODBC
2.50.12 and above, because ODBC can't handle this kind of date.
</p><p>
Because MySQL performs the conversions described above, the
following statements work:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (idate) VALUES (19970505);</code></strong>
mysql> <strong class="userinput"><code>INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (idate) VALUES ('19970505');</code></strong>
mysql> <strong class="userinput"><code>INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (idate) VALUES ('97-05-05');</code></strong>
mysql> <strong class="userinput"><code>INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (idate) VALUES ('1997.05.05');</code></strong>
mysql> <strong class="userinput"><code>INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (idate) VALUES ('1997 05 05');</code></strong>
mysql> <strong class="userinput"><code>INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (idate) VALUES ('0000-00-00');</code></strong>
mysql> <strong class="userinput"><code>SELECT idate FROM <em class="replaceable"><code>tbl_name</code></em> WHERE idate >= '1997-05-05';</code></strong>
mysql> <strong class="userinput"><code>SELECT idate FROM <em class="replaceable"><code>tbl_name</code></em> WHERE idate >= 19970505;</code></strong>
mysql> <strong class="userinput"><code>SELECT MOD(idate,100) FROM <em class="replaceable"><code>tbl_name</code></em> WHERE idate >= 19970505;</code></strong>
mysql> <strong class="userinput"><code>SELECT idate FROM <em class="replaceable"><code>tbl_name</code></em> WHERE idate >= '19970505';</code></strong>
</pre><p>
However, the following does not work:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT idate FROM <em class="replaceable"><code>tbl_name</code></em> WHERE STRCMP(idate,'20030505')=0;</code></strong>
</pre><p>
<code class="literal">STRCMP()</code> is a string function, so it converts
<code class="literal">idate</code> to a string in
<code class="literal">'YYYY-MM-DD'</code> format and performs a string
comparison. It does not convert <code class="literal">'20030505'</code> to
the date <code class="literal">'2003-05-05'</code> and perform a date
comparison.
</p><p>
If you are using the <code class="literal">ALLOW_INVALID_DATES</code> SQL
mode, MySQL allows you to store dates that are given only
limited checking: MySQL requires only that the day is in the
range from 1 to 31 and the month is in the range from 1 to 12.
</p><p>
This makes MySQL very convenient for Web applications where you
obtain year, month, and day in three different fields and you
want to store exactly what the user inserted (without date
validation).
</p><p>
If you are not using the <code class="literal">NO_ZERO_IN_DATE</code> SQL
mode, the day or month part can be zero. This is convenient if
you want to store a birthdate in a <code class="literal">DATE</code>
column and you know only part of the date.
</p><p>
If you are not using the <code class="literal">NO_ZERO_DATE</code> SQL
mode, MySQL also allows you to store
<code class="literal">'0000-00-00'</code> as a “<span class="quote">dummy date.</span>”
This is in some cases more convenient than using
<code class="literal">NULL</code> values.
</p><p>
If the date cannot be converted to any reasonable value, a
<code class="literal">0</code> is stored in the <code class="literal">DATE</code>
column, which is retrieved as <code class="literal">'0000-00-00'</code>.
This is both a speed and a convenience issue. We believe that
the database server's responsibility is to retrieve the same
date you stored (even if the data was not logically correct in
all cases). We think it is up to the application and not the
server to check the dates.
</p><p>
If you want MySQL to check all dates and accept only legal dates
(unless overriden by IGNORE), you should set
<code class="literal">sql_mode</code> to
<code class="literal">"NO_ZERO_IN_DATE,NO_ZERO_DATE"</code>.
</p><p>
Date handling in MySQL 5.0.1 and earlier works like MySQL 5.0.2
with the <code class="literal">ALLOW_INVALID_DATES</code> SQL mode
enabled.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="problems-with-null"></a>A.5.3. Problems with <code class="literal">NULL</code> Values</h3></div></div></div><a class="indexterm" name="id3137030"></a><a class="indexterm" name="id3137042"></a><p>
The concept of the <code class="literal">NULL</code> value is a common
source of confusion for newcomers to SQL, who often think that
<code class="literal">NULL</code> is the same thing as an empty string
<code class="literal">''</code>. This is not the case. For example, the
following statements are completely different:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>INSERT INTO my_table (phone) VALUES (NULL);</code></strong>
mysql> <strong class="userinput"><code>INSERT INTO my_table (phone) VALUES ('');</code></strong>
</pre><p>
Both statements insert a value into the <code class="literal">phone</code>
column, but the first inserts a <code class="literal">NULL</code> value
and the second inserts an empty string. The meaning of the first
can be regarded as “<span class="quote">phone number is not known</span>” and
the meaning of the second can be regarded as “<span class="quote">the person
is known to have no phone, and thus no phone number.</span>”
</p><p>
To help with <code class="literal">NULL</code> handling, you can use the
<code class="literal">IS NULL</code> and <code class="literal">IS NOT NULL</code>
operators and the <code class="literal">IFNULL()</code> function.
</p><p>
In SQL, the <code class="literal">NULL</code> value is never true in
comparison to any other value, even <code class="literal">NULL</code>. An
expression that contains <code class="literal">NULL</code> always produces
a <code class="literal">NULL</code> value unless otherwise indicated in
the documentation for the operators and functions involved in
the expression. All columns in the following example return
<code class="literal">NULL</code>:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT NULL, 1+NULL, CONCAT('Invisible',NULL);</code></strong>
</pre><p>
If you want to search for column values that are
<code class="literal">NULL</code>, you cannot use an <code class="literal">expr =
NULL</code> test. The following statement returns no rows,
because <code class="literal">expr = NULL</code> is never true for any
expression:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT * FROM my_table WHERE phone = NULL;</code></strong>
</pre><p>
To look for <code class="literal">NULL</code> values, you must use the
<code class="literal">IS NULL</code> test. The following statements show
how to find the <code class="literal">NULL</code> phone number and the
empty phone number:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT * FROM my_table WHERE phone IS NULL;</code></strong>
mysql> <strong class="userinput"><code>SELECT * FROM my_table WHERE phone = '';</code></strong>
</pre><p>
See <a href="tutorial.html#working-with-null" title="3.3.4.6. Working with NULL Values">Section 3.3.4.6, “Working with <code class="literal">NULL</code> Values”</a> for additional
information and examples.
</p><p>
You can add an index on a column that can have
<code class="literal">NULL</code> values if you are using the
<code class="literal">MyISAM</code>, <code class="literal">InnoDB</code>, or
<code class="literal">BDB</code>, or <code class="literal">MEMORY</code> storage
engine. Otherwise, you must declare an indexed column
<code class="literal">NOT NULL</code>, and you cannot insert
<code class="literal">NULL</code> into the column.
</p><a class="indexterm" name="id3137255"></a><p>
When reading data with <code class="literal">LOAD DATA INFILE</code>,
empty or missing columns are updated with <code class="literal">''</code>.
If you want a <code class="literal">NULL</code> value in a column, you
should use <code class="literal">\N</code> in the data file. The literal
word “<span class="quote"><code class="literal">NULL</code></span>” may also be used
under some circumstances. See <a href="sql-syntax.html#load-data" title="13.2.5. LOAD DATA INFILE Syntax">Section 13.2.5, “<code class="literal">LOAD DATA INFILE</code> Syntax”</a>.
</p><p>
When using <code class="literal">DISTINCT</code>, <code class="literal">GROUP
BY</code>, or <code class="literal">ORDER BY</code>, all
<code class="literal">NULL</code> values are regarded as equal.
</p><p>
When using <code class="literal">ORDER BY</code>, <code class="literal">NULL</code>
values are presented first, or last if you specify
<code class="literal">DESC</code> to sort in descending order.
</p><p>
Aggregate (summary) functions such as
<code class="literal">COUNT()</code>, <code class="literal">MIN()</code>, and
<code class="literal">SUM()</code> ignore <code class="literal">NULL</code> values.
The exception to this is <code class="literal">COUNT(*)</code>, which
counts rows and not individual column values. For example, the
following statement produces two counts. The first is a count of
the number of rows in the table, and the second is a count of
the number of non-<code class="literal">NULL</code> values in the
<code class="literal">age</code> column:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT COUNT(*), COUNT(age) FROM person;</code></strong>
</pre><a class="indexterm" name="id3137373"></a><a class="indexterm" name="id3137388"></a><a class="indexterm" name="id3137403"></a><a class="indexterm" name="id3137420"></a><p>
For some column types, MySQL handles <code class="literal">NULL</code>
values specially. If you insert <code class="literal">NULL</code> into a
<code class="literal">TIMESTAMP</code> column, the current date and time
is inserted. If you insert <code class="literal">NULL</code> into an
integer column that has the <code class="literal">AUTO_INCREMENT</code>
attribute, the next number in the sequence is inserted.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="problems-with-alias"></a>A.5.4. Problems with Column Aliases</h3></div></div></div><a class="indexterm" name="id3137474"></a><p>
You can use an alias to refer to a column in <code class="literal">GROUP
BY</code>, <code class="literal">ORDER BY</code>, or
<code class="literal">HAVING</code> clauses. Aliases can also be used to
give columns better names:
</p><pre class="programlisting">SELECT SQRT(a*b) AS root FROM <em class="replaceable"><code>tbl_name</code></em> GROUP BY root HAVING root > 0;
SELECT id, COUNT(*) AS cnt FROM <em class="replaceable"><code>tbl_name</code></em> GROUP BY id HAVING cnt > 0;
SELECT id AS 'Customer identity' FROM <em class="replaceable"><code>tbl_name</code></em>;
</pre><p>
Standard SQL doesn't allow you to refer to a column alias in a
<code class="literal">WHERE</code> clause. This is because when the
<code class="literal">WHERE</code> code is executed, the column value may
not yet be determined. For example, the following query is
illegal:
</p><pre class="programlisting">SELECT id, COUNT(*) AS cnt FROM <em class="replaceable"><code>tbl_name</code></em> WHERE cnt > 0 GROUP BY id;
</pre><p>
The <code class="literal">WHERE</code> statement is executed to determine
which rows should be included in the <code class="literal">GROUP BY</code>
part, whereas <code class="literal">HAVING</code> is used to decide which
rows from the result set should be used.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="non-transactional-tables"></a>A.5.5. Rollback Failure for Non-Transactional Tables</h3></div></div></div><a class="indexterm" name="id3137574"></a><p>
If you receive the following message when trying to perform a
<code class="literal">ROLLBACK</code>, it means that one or more of the
tables you used in the transaction do not support transactions:
</p><pre class="programlisting">Warning: Some non-transactional changed tables couldn't be rolled back
</pre><p>
These non-transactional tables are not affected by the
<code class="literal">ROLLBACK</code> statement.
</p><p>
If you were not deliberately mixing transactional and
non-transactional tables within the transaction, the most likely
cause for this message is that a table you thought was
transactional actually is not. This can happen if you try to
create a table using a transactional storage engine that is not
supported by your <span><strong class="command">mysqld</strong></span> server (or that was
disabled with a startup option). If <span><strong class="command">mysqld</strong></span>
doesn't support a storage engine, it instead creates the table
as a <code class="literal">MyISAM</code> table, which is
non-transactional.
</p><p>
You can check the table type for a table by using either of
these statements:
</p><pre class="programlisting">SHOW TABLE STATUS LIKE '<em class="replaceable"><code>tbl_name</code></em>';
SHOW CREATE TABLE <em class="replaceable"><code>tbl_name</code></em>;
</pre><p>
See <a href="sql-syntax.html#show-table-status" title="13.5.4.18. SHOW TABLE STATUS Syntax">Section 13.5.4.18, “<code class="literal">SHOW TABLE STATUS</code> Syntax”</a> and
<a href="sql-syntax.html#show-create-table" title="13.5.4.5. SHOW CREATE TABLE Syntax">Section 13.5.4.5, “<code class="literal">SHOW CREATE TABLE</code> Syntax”</a>.
</p><p>
You can check which storage engines your
<span><strong class="command">mysqld</strong></span> server supports by using this
statement:
</p><pre class="programlisting">SHOW ENGINES;
</pre><p>
You can also use the following statement, and check the value of
the variable that is associated with the storage engine in which
you are interested:
</p><pre class="programlisting">SHOW VARIABLES LIKE 'have_%';
</pre><p>
For example, to determine whether the <code class="literal">InnoDB</code>
storage engine is available, check the value of the
<code class="literal">have_innodb</code> variable.
</p><p>
See <a href="sql-syntax.html#show-engines" title="13.5.4.8. SHOW ENGINES Syntax">Section 13.5.4.8, “<code class="literal">SHOW ENGINES</code> Syntax”</a> and
<a href="sql-syntax.html#show-variables" title="13.5.4.21. SHOW VARIABLES Syntax">Section 13.5.4.21, “<code class="literal">SHOW VARIABLES</code> Syntax”</a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deleting-from-related-tables"></a>A.5.6. Deleting Rows from Related Tables</h3></div></div></div><a class="indexterm" name="id3137725"></a><a class="indexterm" name="id3137735"></a><a class="indexterm" name="id3137745"></a><p>
If the total length of the <code class="literal">DELETE</code> statement
for <code class="literal">related_table</code> is more than 1MB (the
default value of the <code class="literal">max_allowed_packet</code>
system variable), you should split it into smaller parts and
execute multiple <code class="literal">DELETE</code> statements. You
probably get the fastest <code class="literal">DELETE</code> by specifying
only 100 to 1,000 <code class="literal">related_column</code> values per
statement if the <code class="literal">related_column</code> is indexed.
If the <code class="literal">related_column</code> isn't indexed, the
speed is independent of the number of arguments in the
<code class="literal">IN</code> clause.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="no-matching-rows"></a>A.5.7. Solving Problems with No Matching Rows</h3></div></div></div><a class="indexterm" name="id3137812"></a><a class="indexterm" name="id3137818"></a><p>
If you have a complicated query that uses many tables but that
doesn't return any rows, you should use the following procedure
to find out what is wrong:
</p><div class="orderedlist"><ol type="1"><li><p>
Test the query with <code class="literal">EXPLAIN</code> to check
whether you can find something that is obviously wrong. See
<a href="optimization.html#explain" title="7.2.1. EXPLAIN Syntax (Get Information About a SELECT)">Section 7.2.1, “<code class="literal">EXPLAIN</code> Syntax (Get Information About a <code class="literal">SELECT</code>)”</a>.
</p></li><li><p>
Select only those columns that are used in the
<code class="literal">WHERE</code> clause.
</p></li><li><p>
Remove one table at a time from the query until it returns
some rows. If the tables are large, it's a good idea to use
<code class="literal">LIMIT 10</code> with the query.
</p></li><li><p>
Issue a <code class="literal">SELECT</code> for the column that should
have matched a row against the table that was last removed
from the query.
</p></li><li><p>
If you are comparing <code class="literal">FLOAT</code> or
<code class="literal">DOUBLE</code> columns with numbers that have
decimals, you can't use equality (<code class="literal">=</code>)
comparisons. This problem is common in most computer
languages because not all floating-point values can be
stored with exact precision. In some cases, changing the
<code class="literal">FLOAT</code> to a <code class="literal">DOUBLE</code>
fixes this. See <a href="problems.html#problems-with-float" title="A.5.8. Problems with Floating-Point Comparisons">Section A.5.8, “Problems with Floating-Point Comparisons”</a>.
</p></li><li><p>
If you still can't figure out what's wrong, create a minimal
test that can be run with <code class="literal">mysql test <
query.sql</code> that shows your problems. You can create
a test file by dumping the tables with <span><strong class="command">mysqldump
--quick db_name <em class="replaceable"><code>tbl_name_1</code></em> ...
<em class="replaceable"><code>tbl_name_n</code></em> >
query.sql</strong></span>. Open the file in an editor, remove some
insert lines (if there are more than needed to demonstrate
the problem), and add your <code class="literal">SELECT</code>
statement at the end of the file.
</p><p>
Verify that the test file demonstrates the problem by
executing these commands:
</p><pre class="programlisting">shell> <strong class="userinput"><code>mysqladmin create test2</code></strong>
shell> <strong class="userinput"><code>mysql test2 < query.sql</code></strong>
</pre><p>
Post the test file using <span><strong class="command">mysqlbug</strong></span> to the
general MySQL mailing list. See
<a href="introduction.html#mailing-list" title="1.7.1.1. The MySQL Mailing Lists">Section 1.7.1.1, “The MySQL Mailing Lists”</a>.
</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="problems-with-float"></a>A.5.8. Problems with Floating-Point Comparisons</h3></div></div></div><p>
Note that the following section is relevant primarily for
versions of MySQL older than 5.0.3. As of version 5.0.3, MySQL
performs <code class="literal">DECIMAL</code> operations with a precision
of 64 decimal digits, which should solve most common inaccuracy
problems when it comes to <code class="literal">DECIMAL</code> columns.
For <code class="literal">DOUBLE</code> and <code class="literal">FLOAT</code>
columns, the problems remain because inexactness is the basic
nature of floating point numbers.
</p><p>
Floating-point numbers sometimes cause confusion because they
are not stored as exact values inside computer architecture.
What you can see on the screen usually is not the exact value of
the number. The column types <code class="literal">FLOAT</code>,
<code class="literal">DOUBLE</code>, and <code class="literal">DECIMAL</code> are
such. <code class="literal">DECIMAL</code> columns store values with exact
precision because they are represented as strings, but
calculations on <code class="literal">DECIMAL</code> values before MySQL
5.0.3 are done using floating-point operations.
</p><p>
The following example (for older MySQL version than 5.0.3)
demonstrate the problem. It shows that even for the
<code class="literal">DECIMAL</code> column type, calculations that are
done using floating-point operations are subject to
floating-point error. (In all MySQL versions, you would have
similar problems if you would replace the
<code class="literal">DECIMAL</code> columns with
<code class="literal">FLOAT</code>).
</p><pre class="programlisting">mysql> <strong class="userinput"><code>CREATE TABLE t1 (i INT, d1 DECIMAL(9,2), d2 DECIMAL(9,2));</code></strong>
mysql> <strong class="userinput"><code>INSERT INTO t1 VALUES (1, 101.40, 21.40), (1, -80.00, 0.00),</code></strong>
-> <strong class="userinput"><code>(2, 0.00, 0.00), (2, -13.20, 0.00), (2, 59.60, 46.40),</code></strong>
-> <strong class="userinput"><code>(2, 30.40, 30.40), (3, 37.00, 7.40), (3, -29.60, 0.00),</code></strong>
-> <strong class="userinput"><code>(4, 60.00, 15.40), (4, -10.60, 0.00), (4, -34.00, 0.00),</code></strong>
-> <strong class="userinput"><code>(5, 33.00, 0.00), (5, -25.80, 0.00), (5, 0.00, 7.20),</code></strong>
-> <strong class="userinput"><code>(6, 0.00, 0.00), (6, -51.40, 0.00);</code></strong>
mysql> <strong class="userinput"><code>SELECT i, SUM(d1) AS a, SUM(d2) AS b</code></strong>
-> <strong class="userinput"><code>FROM t1 GROUP BY i HAVING a <> b;</code></strong>
+------+--------+-------+
| i | a | b |
+------+--------+-------+
| 1 | 21.40 | 21.40 |
| 2 | 76.80 | 76.80 |
| 3 | 7.40 | 7.40 |
| 4 | 15.40 | 15.40 |
| 5 | 7.20 | 7.20 |
| 6 | -51.40 | 0.00 |
+------+--------+-------+
</pre><p>
The result is correct. Although the first five records look like
they shouldn't pass the comparison test (the values of
<code class="literal">a</code> and <code class="literal">b</code> do not appear to
be different), they may do so because the difference between the
numbers shows up around the tenth decimal or so, depending on
computer architecture.
</p><p>
As of MySQL 5.0.3, you will get only the last row in the above
result.
</p><p>
The problem cannot be solved by using <code class="literal">ROUND()</code>
or similar functions, because the result is still a
floating-point number:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT i, ROUND(SUM(d1), 2) AS a, ROUND(SUM(d2), 2) AS b</code></strong>
-> <strong class="userinput"><code>FROM t1 GROUP BY i HAVING a <> b;</code></strong>
+------+--------+-------+
| i | a | b |
+------+--------+-------+
| 1 | 21.40 | 21.40 |
| 2 | 76.80 | 76.80 |
| 3 | 7.40 | 7.40 |
| 4 | 15.40 | 15.40 |
| 5 | 7.20 | 7.20 |
| 6 | -51.40 | 0.00 |
+------+--------+-------+
</pre><p>
This is what the numbers in column <code class="literal">a</code> look
like when displayed with more decimal places:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT i, ROUND(SUM(d1), 2)*1.0000000000000000 AS a,</code></strong>
-> <strong class="userinput"><code>ROUND(SUM(d2), 2) AS b FROM t1 GROUP BY i HAVING a <> b;</code></strong>
+------+----------------------+-------+
| i | a | b |
+------+----------------------+-------+
| 1 | 21.3999999999999986 | 21.40 |
| 2 | 76.7999999999999972 | 76.80 |
| 3 | 7.4000000000000004 | 7.40 |
| 4 | 15.4000000000000004 | 15.40 |
| 5 | 7.2000000000000002 | 7.20 |
| 6 | -51.3999999999999986 | 0.00 |
+------+----------------------+-------+
</pre><p>
Depending on your computer architecture, you may or may not see
similar results. Different CPUs may evaluate floating-point
numbers differently. For example, on some machines you may get
the “<span class="quote">correct</span>” results by multiplying both arguments
by 1, as the following example shows.
</p><p>
<span class="bold"><strong>Warning:</strong></span> Never use this method
in your applications. It is not an example of a trustworthy
method!
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT i, ROUND(SUM(d1), 2)*1 AS a, ROUND(SUM(d2), 2)*1 AS b</code></strong>
-> <strong class="userinput"><code>FROM t1 GROUP BY i HAVING a <> b;</code></strong>
+------+--------+------+
| i | a | b |
+------+--------+------+
| 6 | -51.40 | 0.00 |
+------+--------+------+
</pre><p>
The reason that the preceding example seems to work is that on
the particular machine where the test was done, CPU
floating-point arithmetic happens to round the numbers to the
same value. However, there is no rule that any CPU should do so,
so this method cannot be trusted.
</p><p>
The correct way to do floating-point number comparison is to
first decide on an acceptable tolerance for differences between
the numbers and then do the comparison against the tolerance
value. For example, if we agree that floating-point numbers
should be regarded the same if they are same within a precision
of one in ten thousand (0.0001), the comparison should be
written to find differences larger than the tolerance value:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1</code></strong>
-> <strong class="userinput"><code>GROUP BY i HAVING ABS(a - b) > 0.0001;</code></strong>
+------+--------+------+
| i | a | b |
+------+--------+------+
| 6 | -51.40 | 0.00 |
+------+--------+------+
1 row in set (0.00 sec)
</pre><p>
Conversely, to get rows where the numbers are the same, the test
should find differences within the tolerance value:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1</code></strong>
-> <strong class="userinput"><code>GROUP BY i HAVING ABS(a - b) <= 0.0001;</code></strong>
+------+-------+-------+
| i | a | b |
+------+-------+-------+
| 1 | 21.40 | 21.40 |
| 2 | 76.80 | 76.80 |
| 3 | 7.40 | 7.40 |
| 4 | 15.40 | 15.40 |
| 5 | 7.20 | 7.20 |
+------+-------+-------+
</pre></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="optimizer-issues"></a>A.6. Optimizer-Related Issues</h2></div></div></div><p>
MySQL uses a cost-based optimizer to determine the best way to
resolve a query. In many cases, MySQL can calculate the best
possible query plan, but sometimes MySQL doesn't have enough
information about the data at hand and has to make
“<span class="quote">educated</span>” guesses about the data.
</p><p>
For the cases when MySQL does not do the "right" thing, tools that
you have available to help MySQL are:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Use the <code class="literal">EXPLAIN</code> statement to get
information about how MySQL processes a query. To use it, just
add the keyword <code class="literal">EXPLAIN</code> to the front of
your <code class="literal">SELECT</code> statement:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>EXPLAIN SELECT * FROM t1, t2 WHERE t1.i = t2.i;</code></strong>
</pre><p>
<code class="literal">EXPLAIN</code> is discussed in more detail in
<a href="optimization.html#explain" title="7.2.1. EXPLAIN Syntax (Get Information About a SELECT)">Section 7.2.1, “<code class="literal">EXPLAIN</code> Syntax (Get Information About a <code class="literal">SELECT</code>)”</a>.
</p></li><li><p>
Use <code class="literal">ANALYZE TABLE
<em class="replaceable"><code>tbl_name</code></em></code> to update the
key distributions for the scanned table. See
<a href="sql-syntax.html#analyze-table" title="13.5.2.1. ANALYZE TABLE Syntax">Section 13.5.2.1, “<code class="literal">ANALYZE TABLE</code> Syntax”</a>.
</p></li><li><p>
<a class="indexterm" name="id3138404"></a>
Use <code class="literal">FORCE INDEX</code> for the scanned table to
tell MySQL that table scans are very expensive compared to
using the given index. See <a href="sql-syntax.html#select" title="13.2.7. SELECT Syntax">Section 13.2.7, “<code class="literal">SELECT</code> Syntax”</a>.
</p><pre class="programlisting">SELECT * FROM t1, t2 FORCE INDEX (index_for_column)
WHERE t1.col_name=t2.col_name;
</pre><p>
<code class="literal">USE INDEX</code> and <code class="literal">IGNORE
INDEX</code> may also be useful.
</p></li><li><p>
Global and table-level <code class="literal">STRAIGHT_JOIN</code>. See
<a href="sql-syntax.html#select" title="13.2.7. SELECT Syntax">Section 13.2.7, “<code class="literal">SELECT</code> Syntax”</a>.
</p></li><li><p>
You can tune global or thread-specific system variables. For
example, Start <span><strong class="command">mysqld</strong></span> with the
<code class="option">--max-seeks-for-key=1000</code> option or use
<code class="literal">SET max_seeks_for_key=1000</code> to tell the
optimizer to assume that no key scan causes more than 1,000
key seeks. See <a href="database-administration.html#server-system-variables" title="5.3.3. Server System Variables">Section 5.3.3, “Server System Variables”</a>.
</p></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="table-definition-issues"></a>A.7. Table Definition-Related Issues</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="problems.html#alter-table-problems">A.7.1. Problems with <code class="literal">ALTER TABLE</code></a></span></dt><dt><span class="section"><a href="problems.html#change-column-order">A.7.2. How to Change the Order of Columns in a Table</a></span></dt><dt><span class="section"><a href="problems.html#temporary-table-problems">A.7.3. <code class="literal">TEMPORARY TABLE</code> Problems</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="alter-table-problems"></a>A.7.1. Problems with <code class="literal">ALTER TABLE</code></h3></div></div></div><a class="indexterm" name="id3138511"></a><a class="indexterm" name="id3138520"></a><a class="indexterm" name="id3138530"></a><p>
<code class="literal">ALTER TABLE</code> changes a table to the current
character set. If you get a duplicate-key error during
<code class="literal">ALTER TABLE</code>, the cause is either that the new
character sets maps two keys to the same value or that the table
is corrupted. In the latter case, you should run <code class="literal">REPAIR
TABLE</code> on the table.
</p><p>
If <code class="literal">ALTER TABLE</code> dies with the following error,
the problem may be that MySQL crashed during an earlier
<code class="literal">ALTER TABLE</code> operation and there is an old
table named
<code class="filename">A-<em class="replaceable"><code>xxx</code></em></code> or
<code class="filename">B-<em class="replaceable"><code>xxx</code></em></code> lying
around:
</p><pre class="programlisting">Error on rename of './database/name.frm'
to './database/B-<em class="replaceable"><code>xxx</code></em>.frm' (Errcode: 17)
</pre><p>
In this case, go to the MySQL data directory and delete all
files that have names starting with <code class="literal">A-</code> or
<code class="literal">B-</code>. (You may want to move them elsewhere
instead of deleting them.)
</p><p>
<code class="literal">ALTER TABLE</code> works in the following way:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Create a new table named
<code class="filename">A-<em class="replaceable"><code>xxx</code></em></code> with
the requested structural changes.
</p></li><li><p>
Copy all rows from the original table to
<code class="filename">A-<em class="replaceable"><code>xxx</code></em></code>.
</p></li><li><p>
Rename the original table to
<code class="filename">B-<em class="replaceable"><code>xxx</code></em></code>.
</p></li><li><p>
Rename <code class="filename">A-<em class="replaceable"><code>xxx</code></em></code>
to your original table name.
</p></li><li><p>
Delete
<code class="filename">B-<em class="replaceable"><code>xxx</code></em></code>.
</p></li></ul></div><p>
If something goes wrong with the renaming operation, MySQL tries
to undo the changes. If something goes seriously wrong (although
this shouldn't happen), MySQL may leave the old table as
<code class="filename">B-<em class="replaceable"><code>xxx</code></em></code>. A simple
rename of the table files at the system level should get your
data back.
</p><p>
If you use <code class="literal">ALTER TABLE</code> on a transactional
table or if you are using Windows or OS/2, <code class="literal">ALTER
TABLE</code> unlocks the table if you had done a
<code class="literal">LOCK TABLE</code> on it. This is because
<code class="literal">InnoDB</code> and these operating systems cannot
drop a table that is in use.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="change-column-order"></a>A.7.2. How to Change the Order of Columns in a Table</h3></div></div></div><a class="indexterm" name="id3138732"></a><a class="indexterm" name="id3138742"></a><a class="indexterm" name="id3138752"></a><a class="indexterm" name="id3138763"></a><p>
First, consider whether you really need to change the column
order in a table. The whole point of SQL is to abstract the
application from the data storage format. You should always
specify the order in which you wish to retrieve your data. The
first of the following statements returns columns in the order
<em class="replaceable"><code>col_name1</code></em>,
<em class="replaceable"><code>col_name2</code></em>,
<em class="replaceable"><code>col_name3</code></em>, whereas the second returns
them in the order <em class="replaceable"><code>col_name1</code></em>,
<em class="replaceable"><code>col_name3</code></em>,
<em class="replaceable"><code>col_name2</code></em>:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT <em class="replaceable"><code>col_name1</code></em>, <em class="replaceable"><code>col_name2</code></em>, <em class="replaceable"><code>col_name3</code></em> FROM <em class="replaceable"><code>tbl_name</code></em>;</code></strong>
mysql> <strong class="userinput"><code>SELECT <em class="replaceable"><code>col_name1</code></em>, <em class="replaceable"><code>col_name3</code></em>, <em class="replaceable"><code>col_name2</code></em> FROM <em class="replaceable"><code>tbl_name</code></em>;</code></strong>
</pre><p>
If you decide to change the order of table columns anyway, you
can do so as follows:
</p><div class="orderedlist"><ol type="1"><li><p>
Create a new table with the columns in the new order.
</p></li><li><p>
Execute this statement:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>INSERT INTO new_table</code></strong>
-> <strong class="userinput"><code>SELECT columns-in-new-order FROM old_table;</code></strong>
</pre></li><li><p>
Drop or rename <code class="literal">old_table</code>.
</p></li><li><p>
Rename the new table to the original name:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>ALTER TABLE new_table RENAME old_table;</code></strong>
</pre></li></ol></div><p>
<code class="literal">SELECT *</code> is quite suitable for testing
queries. However, in an application, you should
<span class="emphasis"><em>never</em></span> rely on using <code class="literal">SELECT
*</code> and retrieving the columns based on their position.
The order and position in which columns are returned does not
remain the same if you add, move, or delete columns. A simple
change to your table structure could cause your application to
fail.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="temporary-table-problems"></a>A.7.3. <code class="literal">TEMPORARY TABLE</code> Problems</h3></div></div></div><a class="indexterm" name="id3138942"></a><p>
The following list indicates limitations on the use of
<code class="literal">TEMPORARY</code> tables:
</p><div class="itemizedlist"><ul type="disc"><li><p>
A <code class="literal">TEMPORARY</code> table can only be of type
<code class="literal">HEAP</code>, <code class="literal">ISAM</code>,
<code class="literal">MyISAM</code>, <code class="literal">MERGE</code>, or
<code class="literal">InnoDB</code>.
</p></li><li><p>
You cannot refer to a <code class="literal">TEMPORARY</code> table
more than once in the same query. For example, the following
does not work:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT * FROM temp_table, temp_table AS t2;</code></strong>
ERROR 1137: Can't reopen table: 'temp_table'
</pre></li><li><p>
The <code class="literal">SHOW TABLES</code> statement does not list
<code class="literal">TEMPORARY</code> tables.
</p></li><li><p>
You cannot use <code class="literal">RENAME</code> to rename a
<code class="literal">TEMPORARY</code> table. However, you can use
<code class="literal">ALTER TABLE</code> instead:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>ALTER TABLE orig_name RENAME new_name;</code></strong>
</pre></li></ul></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="bugs"></a>A.8. Known Issues in MySQL</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="problems.html#open-bugs">A.8.1. Open Issues in MySQL</a></span></dt></dl></div><a class="indexterm" name="id3139069"></a><a class="indexterm" name="id3139079"></a><a class="indexterm" name="id3139089"></a><a class="indexterm" name="id3139099"></a><p>
This section is a list of the known issues in recent versions of
MySQL.
</p><p>
For information about platform-specific issues, see the
installation and porting instructions in
<a href="installing.html#operating-system-specific-notes" title="2.12. Operating System-Specific Notes">Section 2.12, “Operating System-Specific Notes”</a> and
<a href="porting.html" title="Appendix E. Porting to Other Systems">Appendix E, <i>Porting to Other Systems</i></a>.
</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="open-bugs"></a>A.8.1. Open Issues in MySQL</h3></div></div></div><p>
The following problems are known and fixing them is a high
priority:
</p><div class="itemizedlist"><ul type="disc"><li><p>
If you compare a <code class="literal">NULL</code> value to a subquery
using <code class="literal">ALL/ANY/SOME</code> and the subquery
returns an empty result, the comparison might evaluate to
the non-standard result of <code class="literal">NULL</code> rather
than to <code class="literal">TRUE</code> or <code class="literal">FALSE</code>.
This will be fixed in MySQL 5.1.
</p></li><li><p>
Subquery optimization for <code class="literal">IN</code> is not as
effective as for <code class="literal">=</code>.
</p></li><li><p>
Even if you use <code class="literal">lower_case_table_names=2</code>
(which enables MySQL to remember the case used for databases
and table names), MySQL does not remember the case used for
database names for the function
<code class="literal">DATABASE()</code> or within the various logs (on
case-insensitive systems).
</p></li><li><p>
Dropping a <code class="literal">FOREIGN KEY</code> constraint doesn't
work in replication because the constraint may have another
name on the slave.
</p></li><li><p>
<code class="literal">REPLACE</code> (and <code class="literal">LOAD DATA</code>
with the <code class="literal">REPLACE</code> option) does not trigger
<code class="literal">ON DELETE CASCADE</code>.
</p></li><li><p>
<code class="literal">DISTINCT</code> with <code class="literal">ORDER BY</code>
doesn't work inside <code class="literal">GROUP_CONCAT()</code> if you
don't use all and only those columns that are in the
<code class="literal">DISTINCT</code> list.
</p></li><li><p>
If one user has a long-running transaction and another user
drops a table that is updated in the transaction, there is
small chance that the binary log may contain the
<code class="literal">DROP TABLE</code> command before the table is
used in the transaction itself. We plan to fix this by
having the <code class="literal">DROP TABLE</code> command wait until
the table is not being used in any transaction.
</p></li><li><p>
When inserting a big integer value (between
2<sup>63</sup> and
2<sup>64</sup>–1) into a decimal or
string column, it is inserted as a negative value because
the number is evaluated in a signed integer context.
</p></li><li><p>
<code class="literal">FLUSH TABLES WITH READ LOCK</code> does not
block <code class="literal">COMMIT</code> if the server is running
without binary logging, which may cause a problem (of
consistency between tables) when doing a full backup.
</p></li><li><p>
<code class="literal">ANALYZE TABLE</code> on a <code class="literal">BDB</code>
table may in some cases make the table unusable until you
restart <span><strong class="command">mysqld</strong></span>. If this happens, look for
errors of the following form in the MySQL error file:
</p><pre class="programlisting">001207 22:07:56 bdb: log_flush: LSN past current end-of-log
</pre></li><li><p>
Don't execute <code class="literal">ALTER TABLE</code> on a
<code class="literal">BDB</code> table on which you are running
multiple-statement transactions until all those transactions
complete. (The transaction might be ignored.)
</p></li><li><p>
<code class="literal">ANALYZE TABLE</code>, <code class="literal">OPTIMIZE
TABLE</code>, and <code class="literal">REPAIR TABLE</code> may
cause problems on tables for which you are using
<code class="literal">INSERT DELAYED</code>.
</p></li><li><p>
Performing <code class="literal">LOCK TABLE ...</code> and
<code class="literal">FLUSH TABLES ...</code> doesn't guarantee that
there isn't a half-finished transaction in progress on the
table.
</p></li><li><p>
<code class="literal">BDB</code> tables are relatively slow to open.
If you have many <code class="literal">BDB</code> tables in a
database, it takes a long time to use the
<span><strong class="command">mysql</strong></span> client on the database if you are
not using the <code class="literal">-A</code> option or if you are
using <code class="literal">rehash</code>. This is especially
noticeable when you have a large table cache.
</p></li><li><p>
Replication uses query-level logging: The master writes the
executed queries to the binary log. This is a very fast,
compact, and efficient logging method that works perfectly
in most cases.
</p><p>
It is possible for the data on the master and slave to
become different if a query is designed in such a way that
the data modification is non-deterministic (generally not a
recommended practice, even outside of replication).
</p><p>
For example:
</p><div class="itemizedlist"><ul type="circle"><li><p>
<code class="literal">CREATE ... SELECT</code> or <code class="literal">INSERT
... SELECT</code> statements that insert zero or
<code class="literal">NULL</code> values into an
<code class="literal">AUTO_INCREMENT</code> column.
</p></li><li><p>
<code class="literal">DELETE</code> if you are deleting rows from
a table that has foreign keys with <code class="literal">ON DELETE
CASCADE</code> properties.
</p></li><li><p>
<code class="literal">REPLACE ... SELECT</code>, <code class="literal">INSERT
IGNORE ... SELECT</code> if you have duplicate key
values in the inserted data.
</p></li></ul></div><p>
<span class="bold"><strong>If and only if the preceding queries
have no <code class="literal">ORDER BY</code> clause guaranteeing a
deterministic order</strong></span>.
</p><p>
For example, for <code class="literal">INSERT ... SELECT</code> with
no <code class="literal">ORDER BY</code>, the
<code class="literal">SELECT</code> may return rows in a different
order (which results in a row having different ranks, hence
getting a different number in the
<code class="literal">AUTO_INCREMENT</code> column), depending on the
choices made by the optimizers on the master and slave.
</p><p>
A query is optimized differently on the master and slave
only if:
</p><div class="itemizedlist"><ul type="circle"><li><p>
The table is stored using a different storage engine on
the master than on the slave. (It is possible to use
different storage engines on the master and slave. For
example, you can use <code class="literal">InnoDB</code> on the
master, but <code class="literal">MyISAM</code> on the slave if
the slave has less available disk space.)
</p></li><li><p>
MySQL buffer sizes (<code class="literal">key_buffer_size</code>,
and so on) are different on the master and slave.
</p></li><li><p>
The master and slave run different MySQL versions, and
the optimizer code differs between these versions.
</p></li></ul></div><p>
This problem may also affect database restoration using
<span><strong class="command">mysqlbinlog|mysql</strong></span>.
</p><p>
The easiest way to avoid this problem is to add an
<code class="literal">ORDER BY</code> clause to the aforementioned
non-deterministic queries to ensure that the rows are always
stored or modified in the same order.
</p><p>
In future MySQL versions, we will automatically add an
<code class="literal">ORDER BY</code> clause when needed.
</p></li></ul></div><p>
The following issues are known and will be fixed in due time:
</p><div class="itemizedlist"><ul type="disc"><li><p>
Log filenames are based on the server hostname (if you don't
specify a filename with the startup option). You have to use
options such as
<code class="option">--log-bin=<em class="replaceable"><code>old_host_name</code></em>-bin</code>
if you change your hostname to something else. Another
option is to rename the old files to reflect your hostname
change (if these are binary logs, you need to edit the
binary log index file and fix the binlog names there as
well). See <a href="database-administration.html#server-options" title="5.3.1. mysqld Command-Line Options">Section 5.3.1, “<span><strong class="command">mysqld</strong></span> Command-Line Options”</a>.
</p></li><li><p>
<span><strong class="command">mysqlbinlog</strong></span> does not delete temporary
files left after a <code class="literal">LOAD DATA INFILE</code>
command. See <a href="client-side-scripts.html#mysqlbinlog" title="8.6. mysqlbinlog — Utility for Processing Binary Log Files">Section 8.6, “mysqlbinlog — Utility for Processing Binary Log Files”</a>.
</p></li><li><p>
<code class="literal">RENAME</code> doesn't work with
<code class="literal">TEMPORARY</code> tables or tables used in a
<code class="literal">MERGE</code> table.
</p></li><li><p>
Due to the way table definition files are stored, you cannot
use character 255 (<code class="literal">CHAR(255)</code>) in table
names, column names, or enumerations. This is scheduled to
be fixed in version 5.1 when we implement new table
definition format files.
</p></li><li><p>
When using <code class="literal">SET CHARACTER SET</code>, you can't
use translated characters in database, table, and column
names.
</p></li><li><p>
You can't use ‘<code class="literal">_</code>’ or
‘<code class="literal">%</code>’ with
<code class="literal">ESCAPE</code> in <code class="literal">LIKE ...
ESCAPE</code>.
</p></li><li><p>
If you have a <code class="literal">DECIMAL</code> column in which the
same number is stored in different formats (for example,
<code class="literal">+01.00</code>, <code class="literal">1.00</code>,
<code class="literal">01.00</code>), <code class="literal">GROUP BY</code> may
regard each value as a different value.
</p></li><li><p>
You cannot build the server in another directory when using
MIT-pthreads. Because this requires changes to MIT-pthreads,
we are not likely to fix this. See
<a href="installing.html#mit-pthreads" title="2.8.5. MIT-pthreads Notes">Section 2.8.5, “MIT-pthreads Notes”</a>.
</p></li><li><p>
<code class="literal">BLOB</code> and <code class="literal">TEXT</code> values
can't reliably be used in <code class="literal">GROUP BY</code>,
<code class="literal">ORDER BY</code> or <code class="literal">DISTINCT</code>.
Only the first <code class="literal">max_sort_length</code> bytes are
used when comparing <code class="literal">BLOB</code> values in these
cases. The default value of
<code class="literal">max_sort_length</code> is 1024 and can be
changed at server startup time or at runtime.
</p></li><li><p>
Numeric calculations are done with <code class="literal">BIGINT</code>
or <code class="literal">DOUBLE</code> (both are normally 64 bits
long). Which precision you get depends on the function. The
general rule is that bit functions are performed with
<code class="literal">BIGINT</code> precision, <code class="literal">IF</code>
and <code class="literal">ELT()</code> with <code class="literal">BIGINT</code>
or <code class="literal">DOUBLE</code> precision, and the rest with
<code class="literal">DOUBLE</code> precision. You should try to avoid
using unsigned long long values if they resolve to be larger
than 63 bits (9223372036854775807) for anything other than
bit fields.
</p></li><li><p>
You can have up to 255 <code class="literal">ENUM</code> and
<code class="literal">SET</code> columns in one table.
</p></li><li><p>
In <code class="literal">MIN()</code>, <code class="literal">MAX()</code>, and
other aggregate functions, MySQL currently compares
<code class="literal">ENUM</code> and <code class="literal">SET</code> columns
by their string value rather than by the string's relative
position in the set.
</p></li><li><p>
<span><strong class="command">mysqld_safe</strong></span> redirects all messages from
<span><strong class="command">mysqld</strong></span> to the <span><strong class="command">mysqld</strong></span>
log. One problem with this is that if you execute
<span><strong class="command">mysqladmin refresh</strong></span> to close and reopen
the log, <code class="literal">stdout</code> and
<code class="literal">stderr</code> are still redirected to the old
log. If you use <code class="option">--log</code> extensively, you
should edit <span><strong class="command">mysqld_safe</strong></span> to log to
<code class="filename"><em class="replaceable"><code>host_name</code></em>.err</code>
instead of
<code class="filename"><em class="replaceable"><code>host_name</code></em>.log</code>
so that you can easily reclaim the space for the old log by
deleting it and executing <span><strong class="command">mysqladmin
refresh</strong></span>.
</p></li><li><p>
In an <code class="literal">UPDATE</code> statement, columns are
updated from left to right. If you refer to an updated
column, you get the updated value instead of the original
value. For example, the following statement increments
<code class="literal">KEY</code> by <code class="literal">2</code>,
<span class="bold"><strong>not</strong></span> <code class="literal">1</code>:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>UPDATE <em class="replaceable"><code>tbl_name</code></em> SET KEY=KEY+1,KEY=KEY+1;</code></strong>
</pre></li><li><p>
You can refer to multiple temporary tables in the same
query, but you cannot refer to any given temporary table
more than once. For example, the following doesn't work:
</p><pre class="programlisting">mysql> <strong class="userinput"><code>SELECT * FROM temp_table, temp_table AS t2;</code></strong>
ERROR 1137: Can't reopen table: 'temp_table'
</pre></li><li><p>
The optimizer may handle <code class="literal">DISTINCT</code>
differently when you are using “<span class="quote">hidden</span>” columns
in a join than when you are not. In a join, hidden columns
are counted as part of the result (even if they are not
shown), whereas in normal queries, hidden columns don't
participate in the <code class="literal">DISTINCT</code> comparison.
We will probably change this in the future to never compare
the hidden columns when executing
<code class="literal">DISTINCT</code>.
</p><p>
An example of this is:
</p><pre class="programlisting">SELECT DISTINCT mp3id FROM band_downloads
WHERE userid = 9 ORDER BY id DESC;
</pre><p>
and
</p><pre class="programlisting">SELECT DISTINCT band_downloads.mp3id
FROM band_downloads,band_mp3
WHERE band_downloads.userid = 9
AND band_mp3.id = band_downloads.mp3id
ORDER BY band_downloads.id DESC;
</pre><p>
In the second case, using MySQL Server 3.23.x, you may get
two identical rows in the result set (because the values in
the hidden <code class="literal">id</code> column may differ).
</p><p>
Note that this happens only for queries where that do not
have the <code class="literal">ORDER BY</code> columns in the result.
</p></li><li><p>
If you execute a <code class="literal">PROCEDURE</code> on a query
that returns an empty set, in some cases the
<code class="literal">PROCEDURE</code> does not transform the columns.
</p></li><li><p>
Creation of a table of type <code class="literal">MERGE</code> doesn't
check whether the underlying tables are compatible types.
</p></li><li><p>
If you use <code class="literal">ALTER TABLE</code> to add a
<code class="literal">UNIQUE</code> index to a table used in a
<code class="literal">MERGE</code> table and then add a normal index
on the <code class="literal">MERGE</code> table, the key order is
different for the tables if there was an old,
non-<code class="literal">UNIQUE</code> key in the table. This is
because <code class="literal">ALTER TABLE</code> puts
<code class="literal">UNIQUE</code> indexes before normal indexes to
be able to detect duplicate keys as early as possible.
</p></li></ul></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="extending-mysql.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="error-handling.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 24. Extending MySQL </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix B. Error Codes and Messages</td></tr></table></div></body></html>
distrib
>
Mandriva
>
2008.1
>
x86_64
>
media
>
main-release
>
by-pkgid
>
ebb1914cf182a88528b4547490db1dd8
>
files
>
384
