The following limitations apply to use of MySQL on the Windows platform:
Number of file descriptors
The number of open file descriptors on Windows is limited to a maximum of 2048, which may limit the ability to open a large number of tables simultaneously. This limit is due not to Windows but to C runtime library compatibility functions used to open files on Windows that use the POSIX compatibility layer.
This limitation will also cause problems if you try to set
open_files_limit to a value greater than
the 2048 file limit.
On Windows 32-bit platforms it is not possible by default to use more than 2GB of RAM within a single process, including MySQL. This is because the physical address limit on Windows 32-bit is 4GB and the default setting within Windows is to split the RAM between kernel (2GB) and user/applications (2GB).
You can increase this limit to 3GB by specifying the
/3GB option in the
boot.ini file. This changes the
kernel/application memory split to 1GB and 3GB respectively.
This boot option is available on Windows XP, Windows Server
2003, and Windows Server 2008.
Some versions of Windows have a boot time setting to enable larger applications by reducing the kernel application. Alternatively, to use more than 2GB, use a 64-bit version of Windows.
File system aliases
MyISAM tables, you cannot use
aliases within Windows link to the data files on another
volume and then link back to the main MySQL
This facility is often used to move the data and index files
to a RAID or other fast solution, while retaining the main
.frm files in the default data
directory configured with the
Limited number of ports
Windows systems have about 4,000 ports available for client connections, and after a connection on a port closes, it takes two to four minutes before the port can be reused. In situations where clients connect to and disconnect from the server at a high rate, it is possible for all available ports to be used up before closed ports become available again. If this happens, the MySQL server appears to be unresponsive even though it is running. Note that ports may be used by other applications running on the machine as well, in which case the number of ports available to MySQL is lower.
For more information about this problem, see http://support.microsoft.com/default.aspx?scid=kb;en-us;196271.
MySQL depends on the
pwrite() calls to be able to mix
SELECT. Currently, we use
mutexes to emulate
will, in the long run, replace the file level interface with
a virtual interface so that we can use the
interface on NT, 2000, and XP to get more speed. The current
implementation limits the number of open files that MySQL
can use to 2,048 (1,024 before MySQL 4.0.19), which means
that you cannot run as many concurrent threads on NT, 2000,
XP, and 2003 as on Unix.
This problem is fixed in MySQL 5.5.
MySQL uses a blocking read for each connection. That has the following implications if named-pipe connections are enabled:
A connection is not disconnected automatically after eight hours, as happens with the Unix version of MySQL.
If a connection hangs, it is impossible to break it without killing MySQL.
mysqladmin kill does not work on a sleeping connection.
mysqladmin shutdown cannot abort as long as there are sleeping connections.
These problems are fixed in MySQL 5.1. (Bug #31621)
While you are executing an
TABLE statement, the table is locked from being
used by other threads. This has to do with the fact that on
Windows, you cannot delete a file that is in use by another
thread. In the future, we may find some way to work around
DROP TABLE on a table that is
in use by a
MERGE table does not work on
Windows because the
MERGE handler does
the table mapping hidden from the upper layer of MySQL.
Because Windows does not permit you to drop files that are
open, you first must flush all
TABLES) or drop the
before dropping the table. We will fix this at the same time
we introduce views.
DATA DIRECTORY and
DATA DIRECTORY and
DIRECTORY options for
TABLE are ignored on Windows, because MySQL does
not support Windows symbolic links. These options also are
ignored on systems that have a nonfunctional
You cannot drop a database that is in use by another session.
File names are not case sensitive on Windows, so MySQL database and table names are also not case sensitive on Windows. The only restriction is that database and table names must be specified using the same case throughout a given statement. See Section 8.2.2, “Identifier Case Sensitivity”.
Directory and file names
On Windows, MySQL Server supports only directory and file names that are compatible with the current ANSI code pages. For example, the following Japanese directory name will not work in the Western locale (code page 1252):
The same limitation applies to directory and file names
referred to in SQL statements, such as the data file path
\” path name separator
Path name components in Windows are separated by the
\” character, which is also
the escape character in MySQL. If you are using
SELECT ... INTO
OUTFILE, use Unix-style file names with
LOAD DATA INFILE 'C:/tmp/skr.txt' INTO TABLE skr;mysql>
SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
Alternatively, you must double the
LOAD DATA INFILE 'C:\\tmp\\skr.txt' INTO TABLE skr;mysql>
SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;
Problems with pipes
Pipes do not work reliably from the Windows command-line
prompt. If the pipe includes the character
thinks that it has encountered end-of-file and aborts the
This is a problem mainly when you try to apply a binary log as follows:
binary_log_file| mysql --user=root
If you have a problem applying the log and suspect that it
is because of a
CHAR(24) character, you can use the
mysql --user=root --execute "source /tmp/bin.sql"
The latter command also can be used to reliably read in any SQL file that may contain binary data.
Killing MySQL from the Task Manager
On Windows 95, you cannot kill MySQL from the Task Manager
or with the shutdown utility. You must stop it with
mysqladmin shutdown or the
STOP ... command.
Windows 95 and threads
Windows 95 leaks about 200 bytes of main memory for each thread creation. Each connection in MySQL creates a new thread, so you should not run mysqld for an extended time on Windows 95 if your server handles many connections! Newer versions of Windows do not suffer from this bug.