The MySQL server maintains many system variables that indicate how
it is configured. Each system variable has a default value. System
variables can be set at server startup using options on the
command line or in an option file. As of MySQL 4.0.3, most of them
can be changed dynamically while the server is running by means of
the SET
statement, which enables you to modify operation of the server
without having to stop and restart it. You can refer to system
variable values in expressions.
There are several ways to see the names and values of system variables:
To see the values that a server will use based on its
compiled-in defaults and any option files that it reads, use
this command (omit --verbose
before MySQL 4.1.1):
mysqld --verbose --help
To see the values that a server will use based on its
compiled-in defaults, ignoring the settings in any option
files, use this command (omit
--verbose
before MySQL 4.1.1):
mysqld --no-defaults --verbose --help
To see the current values used by a running server, use the
SHOW VARIABLES
statement.
This section provides a description of each system variable. Variables with no version indicated have been present since at least MySQL 3.22.
The following table lists all available system variables:
For additional system variable information, see these sections:
Section 5.1.4, “Using System Variables”, discusses the syntax for setting and displaying system variable values.
Section 5.1.4.2, “Dynamic System Variables”, lists the variables that can be set at runtime.
Information on tuning system variables can be found in Section 7.8.2, “Tuning Server Parameters”.
Section 13.2.4, “InnoDB
Startup Options and System Variables”, lists
InnoDB
system variables.
Section 15.3.4.3, “MySQL Cluster System Variables”, lists system variables which are specific to MySQL Cluster.
For information on server system variables specific to replication, see Section 14.8, “Replication and Binary Logging Options and Variables”.
Some of the following variable descriptions refer to
“enabling” or “disabling” a variable.
These variables can be enabled with the
SET
statement by setting them to ON
or
1
, or disabled by setting them to
OFF
or 0
. However, to set
such a variable on the command line or in an option file, you
must set it to 1
or 0
;
setting it to ON
or OFF
will not work. For example, on the command line,
--delay_key_write=1
works but
--delay_key_write=ON
does not.
Some system variables control the size of buffers or caches. For a given buffer, the server might need to allocate internal data structures. These structures typically are allocated from the total memory allocated to the buffer, and the amount of space required might be platform dependent. This means that when you assign a value to a system variable that controls a buffer size, the amount of space actually available might differ from the value assigned. In some cases, the amount might be less than the value assigned. It is also possible that the server will adjust a value upward. For example, if you assign a value of 0 to a variable for which the minimal value is 1024, the server will set the value to 1024.
Values for buffer sizes, lengths, and stack sizes are given in bytes unless otherwise specified.
Some system variables take file name values. Unless otherwise
specified, the default file location is the data directory if the
value is a relative path name. To specify the location explicitly,
use an absolute path name. Suppose that the data directory is
/var/mysql/data
. If a file-valued variable is
given as a relative path name, it will be located under
/var/mysql/data
. If the value is an absolute
path name, its location is as given by the path name.
This is ON
if mysqld was
started with --ansi
. See
Section 1.9.3, “Running MySQL in ANSI Mode”. This variable was added in MySQL
3.23.6 and removed in 3.23.41. See the description for
sql_mode
.
The autocommit mode. If set to 1, all changes to a table take
effect immediately. If set to 0, you must use
COMMIT
to accept a transaction
or ROLLBACK
to cancel it. If autocommit
is 0 and you change it to 1, MySQL performs an automatic
COMMIT
of any open transaction.
Another way to begin a transaction is to use a
START
TRANSACTION
or
BEGIN
statement. See Section 12.3.1, “START TRANSACTION
,
COMMIT
, and
ROLLBACK
Syntax”.
By default, client connections begin with
autocommit
set to 1. To cause
clients to begin with a default of 0, set the server's
init_connect
system variable.
See the description of that variable for instructions that
show how to do this.
The number of outstanding connection requests MySQL can have.
This comes into play when the main MySQL thread gets very many
connection requests in a very short time. It then takes some
time (although very little) for the main thread to check the
connection and start a new thread. The
back_log
value indicates how
many requests can be stacked during this short time before
MySQL momentarily stops answering new requests. You need to
increase this only if you expect a large number of connections
in a short period of time.
In other words, this value is the size of the listen queue for
incoming TCP/IP connections. Your operating system has its own
limit on the size of this queue. The manual page for the Unix
listen()
system call should have more
details. Check your OS documentation for the maximum value for
this variable. back_log
cannot be set higher than your operating system limit.
The MySQL installation base directory. This variable can be
set with the --basedir
option.
Relative path names for other variables usually are resolved
relative to the base directory.
The size of the buffer that is allocated for caching indexes
and rows for BDB
tables. If you do not use
BDB
tables, you should start
mysqld with
--skip-bdb
to not allocate
memory for this cache. This variable was added in MySQL
3.23.14.
The base directory for BDB
tables. This
should be assigned the same value as the
datadir
variable. This
variable was added in MySQL 3.23.14.
The size of the buffer that is allocated for caching indexes
and rows for BDB
tables. If you do not use
BDB
tables, you should set this to 0 or
start mysqld with
--skip-bdb
in order not to
allocate memory for this cache. This variable was added in
MySQL 3.23.31.
The directory where the BDB
storage engine
writes its log files. This variable can be set with the
--bdb-logdir
option. This
variable was added in MySQL 3.23.14.
The maximum number of locks that can be active for a
BDB
table (10,000 by default). You should
increase this value if errors such as the following occur when
you perform long transactions or when
mysqld has to examine many rows to
calculate a query:
bdb: Lock table is out of available locks Got error 12 from ...
This variable was added in MySQL 3.23.29.
This is ON
if you are using
--bdb-shared-data
to start
Berkeley DB in multi-process mode. (Do not use
DB_PRIVATE
when initializing Berkeley DB.)
This variable was added in MySQL 3.23.29.
The BDB
temporary file directory. This
variable was added in MySQL 3.23.14.
See the description for
version_bdb
.
If set to 1, all temporary tables are stored on disk rather
than in memory. This is a little slower, but the error
The table
does not occur for
tbl_name
is
fullSELECT
operations that require
a large temporary table. The default value for a new
connection is 0 (use in-memory temporary tables). As of MySQL
4.0, you should normally never need to set this variable,
because MySQL automatically converts in-memory tables to
disk-based tables as necessary.
This variable was formerly named
sql_big_tables
.
The size of the cache to hold the SQL statements for the
binary log during a transaction. A binary log cache is
allocated for each client if the server supports any
transactional storage engines and, starting from MySQL 4.1.2,
if the server has the binary log enabled
(--log-bin
option). If you
often use large, multiple-statement transactions, you can
increase this cache size to get more performance. The
Binlog_cache_use
and
Binlog_cache_disk_use
status
variables can be useful for tuning the size of this variable.
This variable was added in MySQL 3.23.29. See
Section 5.3.4, “The Binary Log”.
MyISAM
uses a special tree-like cache to
make bulk inserts faster for
INSERT ...
SELECT
, INSERT ... VALUES (...), (...),
...
, and
LOAD DATA
INFILE
when adding data to nonempty tables. This
variable limits the size of the cache tree in bytes per
thread. Setting it to 0 disables this optimization. The
default value is 8MB. Before MySQL 4.0.3. this variable was
named myisam_bulk_insert_tree_size
.
The default character set. This variable was added in MySQL
3.23.3, then removed in MySQL 4.1.1 and replaced by the
various
character_set_
variables.
xxx
The character set for statements that arrive from the client. This variable was added in MySQL 4.1.1.
The session value of this variable is set using the character
set requested by the client when the client connects to the
server. (Many clients support a
--default-character-set
option to enable this
character set to be specified explicitly. See also
Section 9.1.4, “Connection Character Sets and Collations”.) The global value of the
variable is used to set the session value in cases when the
client-requested value is unknown or not available, or the
server is configured to ignore client requests:
The client is from a version of MySQL older than MySQL 4.1, and thus does not request a character set.
The client requests a character set not known to the
server. For example, a Japanese-enabled client requests
sjis
when connecting to a server not
configured with sjis
support.
mysqld was started with the
--skip-character-set-client-handshake
option, which causes it to ignore client character set
configuration. This reproduces MySQL 4.0 behavior and is
useful should you wish to upgrade the server without
upgrading all the clients.
ucs2
cannot be used as a client character
set, which means that it also does not work for SET
NAMES
or SET CHARACTER SET
.
The character set used for literals that do not have a character set introducer and for number-to-string conversion. This variable was added in MySQL 4.1.1.
The character set used by the default database. The server
sets this variable whenever the default database changes. If
there is no default database, the variable has the same value
as character_set_server
. This
variable was added in MySQL 4.1.1.
The character set used for returning query results such as result sets or error messages to the client. This variable was added in MySQL 4.1.1.
The server default character set. This variable was added in MySQL 4.1.1.
The character set used by the server for storing identifiers.
The value is always utf8
. This variable was
added in MySQL 4.1.1.
The supported character sets. This variable was added in MySQL
3.23.15 and removed in MySQL 4.1.1. (Use
SHOW CHARACTER SET
for a list
of character sets.)
The directory where character sets are installed. This variable was added in MySQL 4.1.2.
The collation of the connection character set. This variable was added in MySQL 4.1.1.
The collation used by the default database. The server sets
this variable whenever the default database changes. If there
is no default database, the variable has the same value as
collation_server
. This
variable was added in MySQL 4.1.1.
The server default collation. This variable was added in MySQL 4.1.1.
If ON
(the default), MySQL permits
INSERT
and
SELECT
statements to run
concurrently for MyISAM
tables that have no
free blocks in the middle of the data file. If
OFF
, concurrent inserts are disabled. If
you start mysqld with
--skip-new
,
this variable is set to OFF
. This variable
was added in MySQL 3.23.7.
See also Section 7.6.3, “Concurrent Inserts”.
The number of seconds that the mysqld
server waits for a connect packet before responding with
Bad handshake
. The default value is 5
seconds.
Increasing the
connect_timeout
value might
help if clients frequently encounter errors of the form
Lost connection to MySQL server at
'
.
XXX
', system error:
errno
The current character set mapping that was set by SET
CHARACTER SET
. This variable was removed in MySQL
4.1.
The MySQL data directory. This variable can be set with the
--datadir
option.
This variable is unused.
This variable is unused.
The default mode value to use for the
WEEK()
function. See
Section 11.7, “Date and Time Functions”. This variable is
available as of MySQL 4.0.14.
This option applies only to MyISAM
tables.
It can have one of the following values to affect handling of
the DELAY_KEY_WRITE
table option that can
be used in CREATE TABLE
statements.
Option | Description |
---|---|
OFF |
DELAY_KEY_WRITE is ignored. |
ON |
MySQL honors any DELAY_KEY_WRITE option specified in
CREATE TABLE
statements. This is the default value. |
ALL |
All new opened tables are treated as if they were created with the
DELAY_KEY_WRITE option enabled. |
If DELAY_KEY_WRITE
is enabled for a table,
the key buffer is not flushed for the table on every index
update, but only when the table is closed. This speeds up
writes on keys a lot, but if you use this feature, you should
add automatic checking of all MyISAM
tables
by starting the server with the
--myisam-recover
option (for
example,
--myisam-recover=BACKUP,FORCE
).
See Section 5.1.2, “Server Command Options”, and
Section 13.1.1, “MyISAM
Startup Options”.
If you enable external locking with
--external-locking
, there is
no protection against index corruption for tables that use
delayed key writes.
This variable was added in MySQL 3.23.8.
After inserting
delayed_insert_limit
delayed
rows, the INSERT DELAYED
handler thread checks whether there are any
SELECT
statements pending. If
so, it permits them to execute before continuing to insert
delayed rows.
How many seconds an INSERT
DELAYED
handler thread should wait for
INSERT
statements before
terminating.
This is a per-table limit on the number of rows to queue when
handling INSERT DELAYED
statements. If the queue becomes full, any client that issues
an INSERT DELAYED
statement
waits until there is room in the queue again.
The number of errors that resulted from the last statement
that generated messages. This variable is read only. See
Section 12.4.5.11, “SHOW ERRORS
Syntax”.
This variable was added in MySQL 4.1.0.
The number of days for automatic binary log file removal. The default is 0, which means “no automatic removal.” Possible removals happen at startup and when the binary log is flushed. Log flushing occurs as indicated in Section 5.3, “MySQL Server Logs”. This variable was added in MySQL 4.1.0.
To remove binary log files manually, use the
PURGE BINARY LOGS
statement.
See Section 12.5.1.1, “PURGE BINARY LOGS
Syntax”.
If ON
, the server flushes (synchronizes)
all changes to disk after each SQL statement. Normally, MySQL
does a write of all changes to disk only after each SQL
statement and lets the operating system handle the
synchronizing to disk. See Section B.5.4.2, “What to Do If MySQL Keeps Crashing”. This
variable is set to ON
if you start
mysqld with the
--flush
option. This variable
was added in MySQL 3.22.9.
If this is set to a nonzero value, all tables are closed every
flush_time
seconds to free up
resources and synchronize unflushed data to disk. This option
is best used only on Windows 9x or Me, or on systems with
minimal resources. This variable was added in MySQL 3.22.18.
If set to 1 (the default), foreign key constraints for
InnoDB
tables are checked. If set to 0,
they are ignored. Disabling foreign key checking can be useful
for reloading InnoDB
tables in an order
different from that required by their parent/child
relationships. This variable was added in MySQL 3.23.52. See
Section 13.2.5.4, “FOREIGN KEY
Constraints”.
Setting foreign_key_checks
to
0 also affects data definition statements:
DROP DATABASE
drops a database
even if it contains tables that have foreign keys that are
referred to by tables outside the database, and
DROP TABLE
drops tables that
have foreign keys that are referred to by other tables.
Setting foreign_key_checks
to 1 does not trigger a scan of the existing table data.
Therefore, rows added to the table while
foreign_key_checks = 0
will
not be verified for consistency.
The list of operators supported by boolean full-text searches
performed using IN BOOLEAN MODE
. See
Section 11.9.2, “Boolean Full-Text Searches”. This variable was added as
a read-only variable in MySQL 4.0.1. It can be modified as of
MySQL 4.1.2.
The default variable value is
'+ -><()~*:""&|'
. The rules
for changing the value are as follows:
Operator function is determined by position within the string.
The replacement value must be 14 characters.
Each character must be an ASCII nonalphanumeric character.
Either the first or second character must be a space.
No duplicates are permitted except the phrase quoting operators in positions 11 and 12. These two characters are not required to be the same, but they are the only two that may be.
Positions 10, 13, and 14 (which by default are set to
“:
”,
“&
”, and
“|
”) are reserved for
future extensions.
The maximum length of the word to be included in a
FULLTEXT
index. This variable was added in
MySQL 4.0.0.
FULLTEXT
indexes must be rebuilt after
changing this variable. Use REPAIR TABLE
.
tbl_name
QUICK
The minimum length of the word to be included in a
FULLTEXT
index. This variable was added in
MySQL 4.0.0.
FULLTEXT
indexes must be rebuilt after
changing this variable. Use REPAIR TABLE
.
tbl_name
QUICK
The number of top matches to use for full-text searches
performed using WITH QUERY EXPANSION
. This
variable was added in MySQL 4.1.1.
The file from which to read the list of stopwords for
full-text searches. The server looks for the file in the data
directory unless an absolute path name is given to specify a
different directory. All the words from the file are used;
comments are not honored. By default, a
built-in list of stopwords is used (as defined in the
myisam/ft_static.c
file). Setting this
variable to the empty string (''
) disables
stopword filtering. See also
Section 11.9.4, “Full-Text Stopwords”. This variable was added
in MySQL 4.0.10.
FULLTEXT
indexes must be rebuilt after
changing this variable or the contents of the stopword file.
Use REPAIR TABLE
.
tbl_name
QUICK
The maximum permitted result length in bytes for the
GROUP_CONCAT()
function. The
default is 1024. This variable was added in MySQL 4.1.0.
YES
if mysqld supports
ARCHIVE
tables, NO
if
not. This variable was added in MySQL 4.1.3.
YES
if mysqld supports
BDB
tables. DISABLED
if
--skip-bdb
is used. This
variable was added in MySQL 3.23.30.
YES
if mysqld supports
BLACKHOLE
tables, NO
if
not. This variable was added in MySQL 4.1.11.
YES
if the zlib
compression library is available to the server,
NO
if not. If not, the
COMPRESS()
and
UNCOMPRESS()
functions cannot
be used. This variable was added in MySQL 4.1.1.
YES
if the crypt()
system call is available to the server, NO
if not. If not, the ENCRYPT()
function cannot be used. This variable was added in MySQL
4.0.10.
YES
if mysqld supports
ARCHIVE
tables, NO
if
not. This variable was added in MySQL 4.1.4.
YES
if mysqld supports
EXAMPLE
tables, NO
if
not. This variable was added in MySQL 4.1.4.
YES
if the server supports spatial data
types, NO
if not. This variable was added
in MySQL 4.1.3.
YES
if mysqld supports
InnoDB
tables. DISABLED
if
--skip-innodb
is used. This variable was added in MySQL 3.23.37.
YES
if mysqld supports
ISAM
tables. DISABLED
if
--skip-isam
is used. This
variable was added in MySQL 3.23.30.
YES
if mysqld supports
MERGE
tables. DISABLED
if --skip-merge
is used. This
variable was added in MySQL 4.1.21.
YES
if mysqld supports
SSL (encryption) connections, NO
if not.
This variable was added in MySQL 3.23.43.
YES
if mysqld supports
the query cache, NO
if not. This variable
was added in MySQL 4.0.2.
YES
if mysqld supports
the RAID
option, NO
if
not. This variable was added in MySQL 3.23.30.
YES
if RTREE
indexes are
available, NO
if not. (These are used for
spatial indexes in MyISAM
tables.) This
variable was added in MySQL 4.1.3.
YES
if symbolic link support is enabled,
NO
if not. This is required on Unix for
support of the DATA DIRECTORY
and
INDEX DIRECTORY
table options, and on
Windows for support of data directory symlinks.
This variable was added in MySQL 4.0.0.
This variable is a synonym for the
last_insert_id
variable. It
exists for compatibility with other database systems. As of
MySQL 3.23.25, you can read its value with SELECT
@@identity
. As of MySQL 4.0.3, you can also set its
value with SET identity
.
A string to be executed by the server for each client that
connects. The string consists of one or more SQL statements.
To specify multiple statements, separate them by semicolon
characters. For example, each client begins by default with
autocommit mode enabled. There is no global system variable to
specify that autocommit should be disabled by default, but
init_connect
can be used to
achieve the same effect:
SET GLOBAL init_connect='SET autocommit=0';
This variable can also be set on the command line or in an option file. To set the variable as just shown using an option file, include these lines:
[mysqld] init_connect='SET autocommit=0'
The content of init_connect
is not executed for users that have the
SUPER
privilege. This is done
so that an erroneous value for
init_connect
does not prevent
all clients from connecting. For example, the value might
contain a statement that has a syntax error, thus causing
client connections to fail. Not executing
init_connect
for users that
have the SUPER
privilege
enables them to open a connection and fix the
init_connect
value.
This variable was added in MySQL 4.1.2.
The name of the file specified with the
--init-file
option when you
start the server. This should be a file containing SQL
statements that you want the server to execute when it starts.
Each statement must be on a single line and should not include
comments. No statement terminator such as
;
, \g
, or
\G
should be given at the end of each
statement. This variable was added in MySQL 3.23.2.
innodb_
xxx
InnoDB
system variables are listed in
Section 13.2.4, “InnoDB
Startup Options and System Variables”.
The value to be used by the following
INSERT
or
ALTER TABLE
statement when
inserting an AUTO_INCREMENT
value. This is
mainly used with the binary log.
The number of seconds the server waits for activity on an
interactive connection before closing it. An interactive
client is defined as a client that uses the
CLIENT_INTERACTIVE
option to
mysql_real_connect()
. See also
wait_timeout
.
The minimum size of the buffer that is used for plain index
scans, range index scans, and joins that do not use indexes
and thus perform full table scans. Normally, the best way to
get fast joins is to add indexes. Increase the value of
join_buffer_size
to get a
faster full join when adding indexes is not possible. One join
buffer is allocated for each full join between two tables. For
a complex join between several tables for which indexes are
not used, multiple join buffers might be necessary. There is
no gain from setting the buffer larger than required to hold
each matching row, and all joins allocate at least the minimum
size, so use caution in setting this variable to a large value
globally. It is better to keep the global setting small and
change to a larger setting only in sessions that are doing
large joins. Memory allocation time can cause substantial
performance drops if the global size is larger than needed by
most queries that use it.
Index blocks for MyISAM
and
ISAM
tables are buffered and are shared by
all threads. key_buffer_size
is the size of the buffer used for index blocks. The key
buffer is also known as the key cache.
The maximum permissible setting for
key_buffer_size
is 4GB. The
effective maximum size might be less, depending on your
available physical RAM and per-process RAM limits imposed by
your operating system or hardware platform. The value of this
variable indicates the amount of memory requested. Internally,
the server allocates as much memory as possible up to this
amount, but the actual allocation might be less.
You can increase the value to get better index handling for
all reads and multiple writes; on a system whose primary
function is to run MySQL using the
MyISAM
storage engine, 25% of the
machine's total memory is an acceptable value for this
variable. However, you should be aware that, if you make the
value too large (for example, more than 50% of the
machine's total memory), your system might start to page
and become extremely slow. This is because MySQL relies on the
operating system to perform file system caching for data
reads, so you must leave some room for the file system cache.
You should also consider the memory requirements of any other
storage engines that you may be using in addition to
MyISAM
.
For even more speed when writing many rows at the same time,
use LOCK TABLES
. See
Section 7.3.2.1, “Speed of INSERT
Statements”.
You can check the performance of the key buffer by issuing a
SHOW STATUS
statement and
examining the
Key_read_requests
,
Key_reads
,
Key_write_requests
, and
Key_writes
status variables.
(See Section 12.4.5, “SHOW
Syntax”.) The
Key_reads/Key_read_requests
ratio should
normally be less than 0.01. The
Key_writes/Key_write_requests
ratio is
usually near 1 if you are using mostly updates and deletes,
but might be much smaller if you tend to do updates that
affect many rows at the same time or if you are using the
DELAY_KEY_WRITE
table option.
The fraction of the key buffer in use can be determined using
key_buffer_size
in
conjunction with the
Key_blocks_unused
status
variable and the buffer block size. From MySQL 4.1.1 on, the
buffer block size is available from the
key_cache_block_size
server
variable. The fraction of the buffer in use is:
1 - ((Key_blocks_unused * key_cache_block_size) / key_buffer_size)
This value is an approximation because some space in the key buffer is allocated internally for administrative structures. Factors that influence the amount of overhead for these structures include block size and pointer size. As block size increases, the percentage of the key buffer lost to overhead tends to decrease. Larger blocks results in a smaller number of read operations (because more keys are obtained per read), but conversely an increase in reads of keys that are not examined (if not all keys in a block are relevant to a query).
Before MySQL 4.1.1, key cache blocks are 1024 bytes, and
before MySQL 4.1.2,
Key_blocks_unused
is
unavailable. The
Key_blocks_used
variable can
be used as follows to determine the fraction of the key buffer
in use:
(Key_blocks_used × 1024) / key_buffer_size
However, Key_blocks_used
indicates the maximum number of blocks that have ever been in
use at once, so this formula does not necessarily represent
the current fraction of the buffer that is in use.
As of MySQL 4.1, it is possible to create multiple
MyISAM
key caches. The size limit of 4GB
applies to each cache individually, not as a group. See
Section 7.5.1, “The MyISAM
Key Cache”.
This value controls the demotion of buffers from the hot
sublist of a key cache to the warm sublist. Lower values cause
demotion to happen more quickly. The minimum value is 100. The
default value is 300. This variable was added in MySQL 4.1.1.
See Section 7.5.1, “The MyISAM
Key Cache”.
The size in bytes of blocks in the key cache. The default
value is 1024. This variable was added in MySQL 4.1.1. See
Section 7.5.1, “The MyISAM
Key Cache”.
The division point between the hot and warm sublists of the
key cache buffer list. The value is the percentage of the
buffer list to use for the warm sublist. Permissible values
range from 1 to 100. The default value is 100. This variable
was added in MySQL 4.1.1. See
Section 7.5.1, “The MyISAM
Key Cache”.
The directory where error messages are located. See Section 9.3, “Setting the Error Message Language”.
Whether mysqld was compiled with options for large file support. This variable was added in MySQL 3.23.28.
The value to be returned from
LAST_INSERT_ID()
. This is
stored in the binary log when you use
LAST_INSERT_ID()
in a statement
that updates a table. Setting this variable does not update
the value returned by the
mysql_insert_id()
C API
function.
This variable specifies the locale that controls the language
used to display day and month names and abbreviations. This
variable affects the output from the
DATE_FORMAT()
,
DAYNAME()
and
MONTHNAME()
functions. Locale
names are POSIX-style values such as
'ja_JP'
or 'pt_BR'
. The
default value is 'en_US'
regardless of your
system's locale setting. For further information, see
Section 9.8, “MySQL Server Locale Support”. This variable was added in
MySQL 4.1.21.
The type of license the server has. This variable was added in MySQL 4.0.19.
Whether LOCAL
is supported for
LOAD DATA
INFILE
statements. See
Section 5.4.5, “Security Issues with LOAD
DATA LOCAL
”. This variable was added in
MySQL 4.0.3.
Whether mysqld was locked in memory with
--memlock
. This variable was
added in MySQL 3.23.25.
Whether logging of all statements to the general query log is enabled. See Section 5.3.2, “The General Query Log”.
The location of the error log. This variable was added in MySQL 4.0.10.
Whether slow queries should be logged. “Slow” is
determined by the value of the
long_query_time
variable.
This variable was added in MySQL 4.0.2. See
Section 5.3.5, “The Slow Query Log”.
Whether the update log is enabled. This variable was added in MySQL 3.22.18. Note that the binary log is preferable to the update log, which is unavailable as of MySQL 5.0. See Section 5.3.3, “The Update Log”.
Whether to produce additional warning messages. This variable was added in MySQL 4.0.3. It is enabled by default as of MySQL 4.0.19 and 4.1.2. As of MySQL 4.0.21 and 4.1.3, the variable can take values greater than 1 and aborted connections are not logged to the error log unless the value is greater than 1.
If a query takes longer than this many seconds, the server
increments the Slow_queries
status variable. If you are using the
--log-slow-queries
option, the
query is logged to the slow query log file. This value is
measured in real time, not CPU time, so a query that is under
the threshold on a lightly loaded system might be above the
threshold on a heavily loaded one. The minimum value is 1. The
default is 10. See Section 5.3.5, “The Slow Query Log”.
If set to 1
, all
INSERT
,
UPDATE
,
DELETE
, and LOCK TABLE
WRITE
statements wait until there is no pending
SELECT
or LOCK TABLE
READ
on the affected table. This affects only
storage engines that use only table-level locking (such as
MyISAM
, MEMORY
, and
MERGE
). Before MySQL 3.22.5, this variable
was named sql_low_priority_updates
.
This variable describes the case sensitivity of file names on
the file system where the data directory is located.
OFF
means file names are case sensitive,
ON
means they are not case sensitive. This
variable is read only because it reflects a file system
attribute and setting it would have no effect on the file
system. This variable was added in MySQL 4.0.19.
If set to 0, table names are stored as specified and comparisons are case sensitive. If set to 1, table names are stored in lowercase on disk and comparisons are not case sensitive. This variable was added in MySQL 3.23.6. If set to 2 (new in 4.0.18), table names are stored as given but compared in lowercase. From MySQL 4.0.2, this option also applies to database names. From 4.1.1, it also applies to table aliases. For additional information, see Section 8.2.2, “Identifier Case Sensitivity”.
You should not set this variable to 0 if
you are running MySQL on a system that does not have
case-sensitive file names (such as Windows or Mac OS X). If
you set this variable to 0 on such a system and access
MyISAM
tablenames using different
lettercases, index corruption may result. New in
4.0.18: If this variable is not set at startup and
the file system on which the data directory is located does
not have case-sensitive file names, MySQL automatically sets
lower_case_table_names
to 2.
If you are using InnoDB
tables, you should
set this variable to 1 on all platforms to force names to be
converted to lowercase.
The setting of this variable has no effect on replication filtering options. See Section 14.9, “How Servers Evaluate Replication Filtering Rules”, for more information.
You should not use different settings for
lower_case_table_names
on replication
masters and slaves. In particular, you should not do this when
the slave uses a case-sensitive file system, as this can cause
replication to fail. For more information, see
Section 14.7.20, “Replication and Variables”.
The maximum size of one packet or any generated/intermediate string.
The packet message buffer is initialized to
net_buffer_length
bytes, but
can grow up to
max_allowed_packet
bytes when
needed. This value by default is small, to catch large
(possibly incorrect) packets.
You must increase this value if you are using large
BLOB
columns or long strings.
It should be as big as the largest
BLOB
you want to use. The
protocol limit for
max_allowed_packet
is 16MB
before MySQL 4.0 and 1GB thereafter. The value should be a
multiple of 1024; nonmultiples are rounded down to the nearest
multiple.
When you change the message buffer size by changing the value
of the max_allowed_packet
variable, you should also change the buffer size on the client
side if your client program permits it. On the client side,
max_allowed_packet
has a
default of 1GB. Some programs such as mysql
and mysqldump enable you to change the
client-side value by setting
max_allowed_packet
on the
command line or in an option file.
If there are more than this number of interrupted connections
from a host, that host is blocked from further connections.
You can unblock blocked hosts with the
FLUSH HOSTS
statement. If a connection is established successfully within
fewer than max_connect_errors
attempts after a previous connection was interrupted, the
error count for the host is cleared to zero. However, once a
host is blocked, the
FLUSH HOSTS
statement is the only way to unblock it.
The maximum permitted number of simultaneous client
connections. By default, this is 100. See
Section B.5.2.7, “Too many connections
”, for more information.
Increasing this value increases the number of file descriptors that mysqld requires. See Section 7.7.2, “How MySQL Opens and Closes Tables”, for comments on file descriptor limits.
Do not start more than this number of threads to handle
INSERT DELAYED
statements. If
you try to insert data into a new table after all
INSERT DELAYED
threads are in
use, the row is inserted as if the DELAYED
attribute was not specified. If you set this to 0, MySQL never
creates a thread to handle DELAYED
rows; in
effect, doing so disables DELAYED
entirely.
This variable was added in MySQL 3.23.0.
For the SESSION
value of this variable, the
only valid values are 0 or the GLOBAL
value.
The maximum number of error, warning, and note messages to be
stored for display by the SHOW
ERRORS
or SHOW
WARNINGS
statements. This variable was added in
MySQL 4.1.0.
This variable sets the maximum size to which user-created
MEMORY
(HEAP
) tables are
permitted to grow. The value of the variable is used to
calculate MEMORY
table
MAX_ROWS
values. Setting this variable has
no effect on any existing MEMORY
table,
unless the table is re-created with a statement such as
CREATE TABLE
, or altered with
ALTER TABLE
or
TRUNCATE TABLE
. A server
restart also sets the maximum size of existing
MEMORY
tables to the global
max_heap_table_size
value.
This variable was added in MySQL 3.23.0.
This variable is also used in conjunction with
tmp_table_size
to limit the
size of internal in-memory tables. See
Section 7.7.4, “How MySQL Uses Internal Temporary Tables”.
This variable is a synonym for
max_delayed_threads
. It was
added in MySQL 4.0.19.
Do not permit SELECT
statements
that probably need to examine more than
max_join_size
rows (for
single-table statements) or row combinations (for
multiple-table statements) or that are likely to do more than
max_join_size
disk seeks. By
setting this value, you can catch
SELECT
statements where keys
are not used properly and that would probably take a long
time. Set it if your users tend to perform joins that lack a
WHERE
clause, that take a long time, or
that return millions of rows.
Setting this variable to a value other than
DEFAULT
resets the value of
sql_big_selects
to
0
. If you set the
sql_big_selects
value again,
the max_join_size
variable is
ignored.
If a query result is in the query cache, no result size check is performed, because the result has previously been computed and it does not burden the server to send it to the client.
This variable previously was named
sql_max_join_size
.
The cutoff on the size of index values that determines which
filesort
algorithm to use. See
Section 7.3.1.7, “ORDER BY
Optimization”. This variable was
added in MySQL 4.1.1
This variable limits the total number of prepared statements in the server. It can be used in environments where there is the potential for denial-of-service attacks based on running the server out of memory by preparing huge numbers of statements. If the value is set lower than the current number of prepared statements, existing statements are not affected and can be used, but no new statements can be prepared until the current number drops below the limit. The default value is 16,382. The permissible range of values is from 0 to 1 million. Setting the value to 0 disables prepared statements. This variable was added in MySQL 4.1.19.
If a write by a replication slave to its relay log causes the
current log file size to exceed the value of this variable,
the slave rotates the relay logs (closes the current file and
opens the next one). If
max_relay_log_size
is 0, the
server uses max_binlog_size
for both the binary log and the relay log. If
max_relay_log_size
is greater
than 0, it constrains the size of the relay log, which enables
you to have different sizes for the two logs. You must set
max_relay_log_size
to between
4096 bytes and 1GB (inclusive), or to 0
.
The default value is 0
. This variable was
added in MySQL 4.0.14. See
Section 14.3, “Replication Implementation Details”.
Limit the assumed maximum number of seeks when looking up rows
based on a key. The MySQL optimizer assumes that no more than
this number of key seeks are required when searching for
matching rows in a table by scanning an index, regardless of
the actual cardinality of the index (see
Section 12.4.5.13, “SHOW INDEX
Syntax”). By setting this to a low value
(say, 100), you can force MySQL to prefer indexes instead of
table scans.
This variable was added in MySQL 4.0.14.
The number of bytes to use when sorting
BLOB
or
TEXT
values. Only the first
max_sort_length
bytes of each
value are used; the rest are ignored.
The maximum number of temporary tables a client can keep open at the same time. (This variable does not yet do anything.)
The maximum number of simultaneous connections permitted to
any given MySQL user account. A value of 0
means “no limit.” This variable was added in
MySQL 3.23.34.
This variable has only a global form.
After this many write locks, permit some pending read lock requests to be processed in between. This variable was added in MySQL 3.23.7.
The default pointer size in bytes, to be used by
CREATE TABLE
for
MyISAM
tables when no
MAX_ROWS
option is specified. This variable
cannot be less than 2 or larger than 7. The default value is
4
. This variable was added in MySQL 4.1.2.
See Section B.5.2.12, “The table is full
”.
myisam_max_extra_sort_file_size
If the temporary file used for fast MyISAM
index creation would be larger than using the key cache by the
amount specified here, prefer the key cache method. This is
mainly used to force long character keys in large tables to
use the slower key cache method to create the index. This
variable was added in MySQL 3.23.37.
The value is given in megabytes before 4.0.3 and in bytes thereafter.
The maximum size of the temporary file that MySQL is permitted
to use while re-creating a MyISAM
index
(during REPAIR TABLE
,
ALTER TABLE
, or
LOAD DATA
INFILE
). If the file size would be larger than this
value, the index is created using the key cache instead, which
is slower. This variable was added in MySQL 3.23.37.
The value is given in megabytes before 4.0.3 and in bytes thereafter.
The default value is 2GB. If MyISAM
index
files exceed this size and disk space is available, increasing
the value may help performance. The space must be available in
the file system containing the directory where the original
index file is located.
The value of the
--myisam-recover
option. See
Section 5.1.2, “Server Command Options”. This variable was added in
MySQL 3.23.36.
If this value is greater than 1, MyISAM
table indexes are created in parallel (each index in its own
thread) during the Repair by sorting
process. The default value is 1.
Multi-threaded repair is still beta-quality code. This variable was added in MySQL 4.0.13.
The size of the buffer that is allocated when sorting
MyISAM
indexes during a
REPAIR TABLE
or when creating
indexes with CREATE INDEX
or
ALTER TABLE
. This variable was
added in MySQL 3.23.16.
How the server treats NULL
values when
collecting statistics about the distribution of index values
for MyISAM
tables. This variable has three
possible values, nulls_equal
,
nulls_unequal
, and
nulls_ignored
. For
nulls_equal
, all NULL
index values are considered equal and form a single value
group that has a size equal to the number of
NULL
values. For
nulls_unequal
, NULL
values are considered unequal, and each
NULL
forms a distinct value group of size
1. For nulls_ignored
,
NULL
values are ignored.
The method that is used for generating table statistics
influences how the optimizer chooses indexes for query
execution, as described in
Section 7.4.4, “MyISAM
Index Statistics Collection”.
Any unique prefix of a valid value may be used to set the value of this variable.
This variable was added in MySQL 4.1.15. For older versions,
the statistics collection method is equivalent to
nulls_equal
.
On Windows, indicates whether the server supports connections over named pipes. This variable was added in MySQL 3.23.50.
Each client thread is associated with a connection buffer and
result buffer. Both begin with a size given by
net_buffer_length
but are
dynamically enlarged up to
max_allowed_packet
bytes as
needed. The result buffer shrinks to
net_buffer_length
after each
SQL statement.
This variable should not normally be changed, but if you have
very little memory, you can set it to the expected length of
statements sent by clients. If statements exceed this length,
the connection buffer is automatically enlarged. The maximum
value to which
net_buffer_length
can be set
is 1MB.
The number of seconds to wait for more data from a connection
before aborting the read. This timeout applies only to TCP/IP
connections, not to connections made through Unix socket
files, named pipes, or shared memory. When the server is
reading from the client,
net_read_timeout
is the
timeout value controlling when to abort. When the server is
writing to the client,
net_write_timeout
is the
timeout value controlling when to abort. See also
slave_net_timeout
. This
variable was added in MySQL 3.23.20.
If a read on a communication port is interrupted, retry this many times before giving up. This value should be set quite high on FreeBSD because internal interrupts are sent to all threads. This variable was added in MySQL 3.23.7.
The number of seconds to wait for a block to be written to a
connection before aborting the write. This timeout applies
only to TCP/IP connections, not to connections made using Unix
socket files, named pipes, or shared memory. See also
net_read_timeout
. This
variable was added in MySQL 3.23.20.
This variable is used in MySQL 4.0 to turn on some 4.1 behaviors. This variable was added in MySQL 4.0.12.
Whether the server should use pre-4.1-style passwords for MySQL user accounts. This variable was added in MySQL 4.1.1.
This is not a variable, but it can be used when setting some
variables. It is described in Section 12.4.4, “SET
Syntax”.
The number of files that the operating system permits
mysqld to open. This is the real value
permitted by the system and might be different from the value
you gave using the
--open-files-limit
option to
mysqld or mysqld_safe.
The value is 0 on systems where MySQL cannot change the number
of open files. This variable was added in MySQL 3.23.20.
The path name of the process ID (PID) file. This variable can
be set with the --pid-file
option. This variable was added in MySQL 3.23.23.
The path name of the plugin directory. This variable was added in MySQL 4.1.25. If the value is nonempty, user-defined function object files must be located in this directory. If the value is empty, the behavior that is used before 4.1.25 applies: The UDF object files must be located in a directory that is searched by your system's dynamic linker.
If the plugin directory is writable by the server, it may be
possible for a user to write executable code to a file in the
directory using SELECT
... INTO DUMPFILE
. This can be prevented by making
plugin_dir
read only to the
server.
The number of the port on which the server listens for TCP/IP
connections. This variable can be set with the
--port
option.
The size of the buffer that is allocated when preloading indexes. This variable was added in MySQL 4.1.1.
The current number of prepared statements. (The maximum number
of statements is given by the
max_prepared_stmt_count
system variable.) This variable was added in MySQL 4.1.19. In
MySQL 4.1.23, it was converted to the global
Prepared_stmt_count
status
variable.
The version of the client/server protocol used by the MySQL server. This variable was added in MySQL 3.23.18.
Variable Name | pseudo_thread_id |
||
Variable Scope | Session | ||
Dynamic Variable | Yes | ||
Permitted Values | |||
Type | numeric |
This variable is for internal server use.
The allocation size of memory blocks that are allocated for objects created during statement parsing and execution. If you have problems with memory fragmentation, it might help to increase this parameter. This variable was added in MySQL 4.0.16.
Do not cache results that are larger than this number of bytes. The default value is 1MB. This variable was added in MySQL 4.0.1.
The minimum size for blocks allocated by the query cache. The default value is 4KB. Tuning information for this variable is given in Section 7.5.3.3, “Query Cache Configuration”. This variable is present from MySQL 4.1.
The amount of memory allocated for caching query results. The
default value is 0
, which disables the
query cache. The permissible values are multiples of 1024;
other values are rounded down to the nearest multiple. Note
that query_cache_size
bytes
of memory are allocated even if
query_cache_type
is set to
0
. This variable was added in MySQL 4.0.1.
The query cache needs a minimum size of about 40KB to allocate
its structures. (The exact size depends on system
architecture.) If you set the value of
query_cache_size
too small, a
warning will occur, as described in
Section 7.5.3.3, “Query Cache Configuration”.
Set the query cache type. Setting the
GLOBAL
value sets the type for all clients
that connect thereafter. Individual clients can set the
SESSION
value to affect their own use of
the query cache.
Option | Description |
---|---|
0 or OFF
|
Do not cache results in or retrieve results from the query cache. Note
that this does not deallocate the query cache buffer.
To do that, you should set
query_cache_size to
0. |
1 or ON
|
Cache all cacheable query results except for those that begin with
SELECT SQL_NO_CACHE . |
2 or DEMAND
|
Cache results only for cacheable queries that begin with SELECT
SQL_CACHE . |
This variable defaults to ON
.
Any unique prefix of a valid value may be used to set the value of this variable.
This variable was added in MySQL 4.0.3.
Normally, when one client acquires a WRITE
lock on a MyISAM
table, other clients are
not blocked from issuing statements that read from the table
if the query results are present in the query cache. Setting
this variable to 1 causes acquisition of a
WRITE
lock for a table to invalidate any
queries in the query cache that refer to the table. This
forces other clients that attempt to access the table to wait
while the lock is in effect. This variable was added in MySQL
4.0.19.
The size of the persistent buffer used for statement parsing
and execution. This buffer is not freed between statements. If
you are running complex queries, a larger
query_prealloc_size
value
might be helpful in improving performance, because it can
reduce the need for the server to perform memory allocation
during query execution operations.
This variable was added in MySQL 4.0.16.
The rand_seed1
and
rand_seed2
variables exist as
session variables only, and can be set but not read. They are
not shown in the output of SHOW
VARIABLES
. These two variables were added in MySQL
4.0.5.
The purpose of these variables is to support replication of
the RAND()
function. For
statements that invoke RAND()
,
the master passes two values to the slave, where they are used
to seed the random number generator. The slave uses these
values to set the session variables
rand_seed1
and
rand_seed2
so that
RAND()
on the slave generates
the same value as on the master.
See the description for
rand_seed1
.
The size of blocks that are allocated when doing range optimization. This variable was added in MySQL 4.0.16.
Each thread that does a sequential scan allocates a buffer of this size (in bytes) for each table it scans. If you do many sequential scans, you might want to increase this value.
read_buffer_size
and
read_rnd_buffer_size
are not
specific to any storage engine and apply in a general manner
for optimization. See Section 7.8.4, “How MySQL Uses Memory”, for
example.
Before MySQL 4.0.3, this variable was named
record_buffer
.
This variable is off by default. When it is enabled, the
server permits no updates except from users that have the
SUPER
privilege or (on a slave
server) from updates performed by slave threads. On a slave
server, this can be useful to ensure that the slave accepts
updates only from its master server and not from clients.
read_only
exists only as a
GLOBAL
variable, so changes to its value
require the SUPER
privilege.
Changes to read_only
on a
master server are not replicated to slave servers. The value
can be set on a slave server independent of the setting on the
master.
This variable was added in MySQL 4.0.14.
When reading rows in sorted order following a key-sorting
operation, the rows are read through this buffer to avoid disk
seeks. See Section 7.3.1.7, “ORDER BY
Optimization”. Setting
the variable to a large value can improve ORDER
BY
performance by a lot. However, this is a buffer
allocated for each client, so you should not set the global
variable to a large value. Instead, change the session
variable only from within those clients that need to run large
queries.
read_buffer_size
and
read_rnd_buffer_size
are not
specific to any storage engine and apply in a general manner
for optimization. See Section 7.8.4, “How MySQL Uses Memory”, for
example.
Before MySQL 4.0.3, this variable was named
record_rnd_buffer
.
Disables or enables automatic purging of relay log files as
soon as they are not needed any more. The default value is 1
(ON
).
The maximum amount of space to use for all relay logs.
Do not show databases for which the user has no database or
table privileges. This can improve security if you are
concerned about people being able to see what databases other
users have. See also
skip_show_database
.
This variable was removed in MySQL 4.0.5. Beginning with this
version, you should instead use the SHOW
DATABASES
privilege to control access by MySQL
accounts to databases.
If the MySQL server has been started with the
--secure-auth
option, it blocks
connections from all accounts that have passwords stored in
the old (pre-4.1) format. In that case, the value of this
variable is ON
, otherwise it is
OFF
.
You should enable this option if you want to prevent all use of passwords in the old format (and hence insecure communication over the network). This variable was added in MySQL 4.1.1.
Server startup fails with an error if this option is enabled and the privilege tables are in pre-4.1 format.
The server ID, used in replication to give each master and
slave a unique identity. This variable is set by the
--server-id
option. For each
server participating in replication, you should pick a
positive integer in the range from 1 to
232 – 1 to act as that
server's ID.
(Windows only.) Whether the server permits shared-memory connections. This variable was added in MySQL 4.1.1.
(Windows only.) The name of shared memory to use for shared-memory connections. This is useful when running multiple MySQL instances on a single physical machine. This variable was added in MySQL 4.1.0.
This is OFF
if mysqld
uses external locking, ON
if external
locking is disabled. Before MySQL 4.0.3, this variable was
named skip_locking
.
This is ON
if the server permits only local
(non-TCP/IP) connections. On Unix, local connections use a
Unix socket file. On Windows, local connections use a named
pipe or shared memory. On NetWare, only TCP/IP connections are
supported, so do not set this variable to
ON
. This variable can be set to
ON
with the
--skip-networking
option. This
variable was added in MySQL 3.22.23.
This prevents people from using the SHOW
DATABASES
statement if they do not have the
SHOW DATABASES
privilege. This
can improve security if you are concerned about people being
able to see what databases other users have. See also
safe_show_database
. This
variable was added in MySQL 3.23.4. As of MySQL 4.0.2, its
effect also depends on the SHOW
DATABASES
privilege: If the variable value is
ON
, the SHOW
DATABASES
statement is permitted only to users who
have the SHOW DATABASES
privilege, and the statement displays all database names. If
the value is OFF
, SHOW
DATABASES
is permitted to all users, but displays
each database name only if the user has the
SHOW DATABASES
privilege or
some privilege for the database. Note that any global
privilege is a privilege for the database.
If creating a thread takes longer than this many seconds, the
server increments the
Slow_launch_threads
status
variable. This variable was added in MySQL 3.23.15.
On Unix platforms, this variable is the name of the socket
file that is used for local client connections. The default is
/tmp/mysql.sock
. (For some distribution
formats, the directory might be different, such as
/var/lib/mysql
for RPMs.)
On Windows, this variable is the name of the named pipe that
is used for local client connections. The default value is
MySQL
(not case sensitive).
Each session that needs to do a sort allocates a buffer of
this size. sort_buffer_size
is not specific to any storage engine and applies in a general
manner for optimization. See
Section 7.3.1.7, “ORDER BY
Optimization”, for example.
If you see many
Sort_merge_passes
per second
in SHOW GLOBAL
STATUS
output, you can consider increasing the
sort_buffer_size
value to
speed up ORDER BY
or GROUP
BY
operations that cannot be improved with query
optimization or improved indexing. The entire buffer is
allocated even if it is not all needed, so setting it larger
than required globally will slow down most queries that sort.
It is best to increase it as a session setting, and only for
the sessions that need a larger size. On Linux, there are
thresholds of 256KB and 2MB where larger values may
significantly slow down memory allocation, so you should
consider staying below one of those values. Experiment to find
the best value for your workload. See
Section B.5.4.4, “Where MySQL Stores Temporary Files”.
Variable Name | sql_auto_is_null |
||
Variable Scope | Session | ||
Dynamic Variable | Yes |
If this variable is set to 1 (the default), then after a
statement that successfully inserts an automatically generated
AUTO_INCREMENT
value, you can find that
value by issuing a statement of the following form:
SELECT * FROMtbl_name
WHEREauto_col
IS NULL
If the statement returns a row, the value returned is the same
as if you invoked the
LAST_INSERT_ID()
function. For
details, including the return value after a multiple-row
insert, see Section 11.13, “Information Functions”. If no
AUTO_INCREMENT
value was successfully
inserted, the SELECT
statement
returns no row.
The behavior of retrieving an
AUTO_INCREMENT
value by using an
IS NULL
comparison is used by
some ODBC programs, such as Access. See
Section 17.1.7.1.1, “Obtaining Auto-Increment Values”.
This behavior can be disabled by setting
sql_auto_is_null
to 0.
Variable Name | sql_big_selects |
||
Variable Scope | Session | ||
Dynamic Variable | Yes | ||
Permitted Values | |||
Type | boolean |
||
Default | 1 |
If set to 0, MySQL aborts
SELECT
statements that are
likely to take a very long time to execute (that is,
statements for which the optimizer estimates that the number
of examined rows exceeds the value of
max_join_size
). This is
useful when an inadvisable WHERE
statement
has been issued. The default value for a new connection is 1,
which permits all SELECT
statements.
If you set the max_join_size
system variable to a value other than
DEFAULT
,
sql_big_selects
is set to 0.
Variable Name | sql_buffer_result |
||
Variable Scope | Session | ||
Dynamic Variable | Yes | ||
Permitted Values | |||
Type | boolean |
||
Default | 0 |
If set to 1,
sql_buffer_result
forces
results from SELECT
statements
to be put into temporary tables. This helps MySQL free the
table locks early and can be beneficial in cases where it
takes a long time to send results to the client. The default
value is 0. This variable was added in MySQL 3.23.13.
Variable Name | sql_log_bin |
||
Variable Scope | Session | ||
Dynamic Variable | Yes | ||
Permitted Values | |||
Type | boolean |
If set to 0, no logging is done to the binary log for the
client. The client must have the
SUPER
privilege to set this
option. The default value is 1. This variable was added in
MySQL 3.23.16.
Variable Name | sql_log_off |
||
Variable Scope | Session | ||
Dynamic Variable | Yes | ||
Permitted Values | |||
Type | boolean |
||
Default | 0 |
If set to 1, no logging is done to the general query log for
this client. The client must have the
SUPER
privilege to set this
option. The default value is 0.
Variable Name | sql_log_update |
||
Variable Scope | Session | ||
Dynamic Variable | Yes | ||
Deprecated | 5.0, by sql_log_bin
|
||
Permitted Values | |||
Type | boolean |
If set to 0
, no logging is done to the
update log for the client. The client must have the
SUPER
privilege to set this
option. The default value is 1. This variable was added in
MySQL 3.22.5.
The current server SQL mode. This variable was added in MySQL 3.23.41. It can be set dynamically as of MySQL 4.1.1. See Section 5.1.6, “Server SQL Modes”.
If set to 1 (the default), warnings of Note
level are recorded. If set to 0, Note
warnings are suppressed. mysqldump includes
output to set this variable to 0 so that reloading the dump
file does not produce warnings for events that do not affect
the integrity of the reload operation.
sql_notes
was added in MySQL
4.1.11.
If set to 1 (the default), the server quotes identifiers for
SHOW CREATE TABLE
and
SHOW CREATE DATABASE
statements. If set to 0, quoting is disabled. This option is
enabled by default so that replication works for identifiers
that require quoting. See Section 12.4.5.7, “SHOW CREATE TABLE
Syntax”,
and Section 12.4.5.6, “SHOW CREATE DATABASE
Syntax”. This variable was
added in MySQL 3.23.26.
If set to 1, MySQL aborts
UPDATE
or
DELETE
statements that do not
use a key in the WHERE
clause or a
LIMIT
clause. This makes it possible to
catch UPDATE
or
DELETE
statements where keys
are not used properly and that would probably change or delete
a large number of rows. The default value is 0. This variable
was added in MySQL 3.22.32.
The maximum number of rows to return from
SELECT
statements. The default
value for a new connection is the maximum number of rows that
the server permits per table, which depends on the server
configuration and may be affected if the server build was
configured with
--with-big-tables
. Typical
default values are (232)–1 or
(264)–1. If you have changed
the limit, the default value can be restored by assigning a
value of DEFAULT
.
If a SELECT
has a
LIMIT
clause, the LIMIT
takes precedence over the value of
sql_select_limit
.
sql_select_limit
does not
apply to SELECT
statements
executed within stored routines. It also does not apply to
SELECT
statements that do not
produce a result set to be returned to the client. These
include SELECT
statements in
subqueries,
CREATE TABLE ...
SELECT
, and
INSERT INTO ...
SELECT
.
This variable controls whether single-row
INSERT
statements produce an
information string if warnings occur. The default is 0. Set
the value to 1 to produce an information string. This variable
was added in MySQL 3.22.11.
This variable is a synonym for
table_type
. It was added in
MySQL 4.1.2.
If this variable is set to 1, when any nontemporary table is
created its .frm
file is synchronized to
disk (using fdatasync()
). This is slower
but safer in case of a crash. The default is 1. This was added
as a command-line option in MySQL 4.0.18. It is also a
settable global variable as of MySQL 4.1.3.
The server system time zone. When the server begins executing,
it inherits a time zone setting from the machine defaults,
possibly modified by the environment of the account used for
running the server or the startup script. The value is used to
set system_time_zone
.
Typically the time zone is specified by the
TZ
environment variable. It also can be
specified using the
--timezone
option of the
mysqld_safe script.
The system_time_zone
variable
differs from time_zone
.
Although they might have the same value, the latter variable
is used to initialize the time zone for each client that
connects. See Section 9.7, “MySQL Server Time Zone Support”.
system_time_zone
was added in
MySQL 4.1.3.
The number of open tables for all threads. Increasing this
value increases the number of file descriptors that
mysqld requires. You can check whether you
need to increase the table cache by checking the
Opened_tables
status
variable. See Section 5.1.5, “Server Status Variables”. If
the value of Opened_tables
is large and you do not do
FLUSH TABLES
often (which just forces all tables to be closed and
reopened), then you should increase the value of the
table_cache
variable. For
more information about the table cache, see
Section 7.7.2, “How MySQL Opens and Closes Tables”.
The default table type (storage engine). To set the table type
at server startup, use the
--default-table-type
option.
This variable was added in MySQL 3.23.0. See
Section 5.1.2, “Server Command Options”.
How many threads the server should cache for reuse. When a
client disconnects, the client's threads are put in the cache
if there are fewer than
thread_cache_size
threads
there. Requests for threads are satisfied by reusing threads
taken from the cache if possible, and only when the cache is
empty is a new thread created. This variable can be increased
to improve performance if you have a lot of new connections.
Normally, this does not provide a notable performance
improvement if you have a good thread implementation. However,
if your server sees hundreds of connections per second you
should normally set
thread_cache_size
high enough
so that most new connections use cached threads. By examining
the difference between the
Connections
and
Threads_created
status
variables, you can see how efficient the thread cache is. For
details, see Section 5.1.5, “Server Status Variables”. This
variable was added in MySQL 3.23.16.
This variable is specific to Solaris systems, for which
mysqld invokes the
thr_setconcurrency()
with the variable
value. This function enables applications to give the threads
system a hint about the desired number of threads that should
be run at the same time. This variable was added in MySQL
3.23.7.
The stack size for each thread. Many of the limits detected by
the crash-me
test are dependent on this
value. The default is large enough for normal operation. See
Section 7.1.3, “The MySQL Benchmark Suite”. The default is 64KB before
MySQL 4.0.10 and 192KB thereafter. If the thread stack size is
too small, it limits the complexity of the SQL statements that
the server can handle, the recursion depth of stored
procedures, and other memory-consuming actions.
This variable is unused.
The current time zone. This variable is used to initialize the
time zone for each client that connects. By default, the
initial value of this is 'SYSTEM'
(which
means, “use the value of
system_time_zone
”).
The value can be specified explicitly at server startup with
the --default-time-zone
option.
See Section 9.7, “MySQL Server Time Zone Support”. This variable was
added in MySQL 4.1.3.
timestamp =
{
timestamp_value
|
DEFAULT}
Set the time for this client. This is used to get the original
timestamp if you use the binary log to restore rows.
timestamp_value
should be a Unix
epoch timestamp, not a MySQL timestamp.
The time zone for the server. This is set from the
TZ
environment variable when
mysqld is started. The time zone also can
be set by giving a
--timezone
argument to
mysqld_safe. This variable was added in
MySQL 3.23.15. As of MySQL 4.1.3, it is obsolete and has been
replaced by the
system_time_zone
variable.
See Section B.5.4.6, “Time Zone Problems”.
The maximum size of internal in-memory temporary tables. (The
actual limit is determined as the minimum of
tmp_table_size
and
max_heap_table_size
.) If an
in-memory temporary table exceeds the limit, MySQL
automatically converts it to an on-disk
MyISAM
table. Increase the value of
tmp_table_size
(and
max_heap_table_size
if
necessary) if you do many advanced GROUP BY
queries and you have lots of memory. This variable does not
apply to user-created MEMORY
tables.
You can compare the number of internal on-disk temporary
tables created to the total number of internal temporary
tables created by comparing the values of the
Created_tmp_disk_tables
and
Created_tmp_tables
variables.
See also Section 7.7.4, “How MySQL Uses Internal Temporary Tables”.
The directory used for temporary files and temporary tables.
Starting from MySQL 4.1, this variable can be set to a list of
several paths that are used in round-robin fashion. Paths
should be separated by colon characters
(“:
”) on Unix and semicolon
characters (“;
”) on Windows,
NetWare, and OS/2.
The multiple-directory feature can be used to spread the load
between several physical disks. If the MySQL server is acting
as a replication slave, you should not set
tmpdir
to point to a
directory on a memory-based file system 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
LOAD DATA
INFILE
operations. If files in the temporary file
directory are lost when the server restarts, replication
fails. However, if you are using MySQL 4.0.0 or later, you can
set the slave's temporary directory using the
slave_load_tmpdir
variable.
In that case, the slave will not use the general
tmpdir
value and you can set
tmpdir
to a nonpermanent
location.
This variable was added in MySQL 3.22.4.
The amount in bytes by which to increase a per-transaction
memory pool which needs memory. See the description of
transaction_prealloc_size
.
This variable was added in MySQL 4.0.16.
There is a per-transaction memory pool from which various
transaction-related allocations take memory. The initial size
of the pool in bytes is
transaction_prealloc_size
.
For every allocation that cannot be satisfied from the pool
because it has insufficient memory available, the pool is
increased by
transaction_alloc_block_size
bytes. When the transaction ends, the pool is truncated to
transaction_prealloc_size
bytes.
By making
transaction_prealloc_size
sufficiently large to contain all statements within a single
transaction, you can avoid many malloc()
calls. This variable was added in MySQL 4.0.16.
The default transaction isolation level. This variable was added in MySQL 4.0.3.
This variable is set by the
SET
TRANSACTION ISOLATION LEVEL
statement. See
Section 12.3.6, “SET TRANSACTION
Syntax”. If you set
tx_isolation
directly to an
isolation level name that contains a space, the name should be
enclosed within quotation marks, with the space replaced by a
dash. For example:
SET tx_isolation = 'READ-COMMITTED';
Any unique prefix of a valid value may be used to set the value of this variable.
Variable Name | unique_checks |
||
Variable Scope | Session | ||
Dynamic Variable | Yes | ||
Permitted Values | |||
Type | boolean |
||
Default | 1 |
If set to 1 (the default), uniqueness checks for secondary
indexes in InnoDB
tables are performed. If
set to 0, storage engines are permitted to assume that
duplicate keys are not present in input data. If you know for
certain that your data does not contain uniqueness violations,
you can set this to 0 to speed up large table imports to
InnoDB
. This variable was added in MySQL
3.23.52.
Note that setting this variable to 0 does not require storage engines to ignore duplicate keys. An engine is still permitted to check for them and issue duplicate-key errors if it detects them.
The version number for the server.
The BDB
storage engine version. This
variable was added in MySQL 3.23.31 with the name
bdb_version
and renamed to
version_bdb
in MySQL 4.1.1.
Variable Name | version_comment |
||
Variable Scope | Global | ||
Dynamic Variable | No | ||
Permitted Values | |||
Type | string |
The configure script has a
--with-comment
option that permits a comment
to be specified when building MySQL. This variable contains
the value of that comment. This variable was added in MySQL
4.0.17.
Variable Name | version_compile_machine |
||
Variable Scope | Global | ||
Dynamic Variable | No | ||
Permitted Values | |||
Type | string |
The type of machine or architecture on which MySQL was built. This variable was added in MySQL 4.1.1.
The type of operating system on which MySQL was built. This variable was added in MySQL 4.0.19.
The number of seconds the server waits for activity on a noninteractive connection before closing it. This timeout applies only to TCP/IP and Unix socket file connections, not to connections made using named pipes, or shared memory.
On thread startup, the session
wait_timeout
value is
initialized from the global
wait_timeout
value or from
the global
interactive_timeout
value,
depending on the type of client (as defined by the
CLIENT_INTERACTIVE
connect option to
mysql_real_connect()
). See
also interactive_timeout
.
The number of errors, warnings, and notes that resulted from
the last statement that generated messages. This variable is
read only. See Section 12.4.5.26, “SHOW WARNINGS
Syntax”.
This variable was added in MySQL 4.1.0.
User Comments
if you set
[mysqld]
ft_min_word_len=3
you should also set
[myisamchk]
ft_min_word_len=3
if you use myisamchk
If your queries are mysteriously failing after running for sometime, even though the SQL syntax is correct, check how long the query was running compared to the interactive_timeout and wait_timeout variables. Prior to mysql 4.1.16 on BSD systems (including Mac OS X), the timeout period was not enforced. If you've recently upgraded to >4.1.16 and are getting these failures... this is most likely the problem.
Note that you can increase these variables, but show variables will not show the new setting until you login again because these variables are set at thread creation - so you'll need to start a new thread to see the changes.
http://bugs.mysql.com/bug.php?id=8731 for the curious.
To set variables in Query Browser use
set @@global.auto_increment_increment = <number>
and then run
set @@auto_increment_increment = <number>
will not run probably
The description for lower_case_table_names is a bit unclear with regards to the value 0 (but does explain 1 and 2).
A value of 0 means that table & database names are stored as-is, and name comparisons are case sensitive.
There's more information about lower_case_table_names on this page:
http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html
Documentation says "The maximum allowable setting for sort_buffer_size is 4GB." and there is reference to a chapter explaining temporary on-disk files.
However, the fact that on 32-bit GNU/Linux x86, "sort_buffer_size" must be a few MiB only to avoid exceeding maximum process space, as explained in http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html makes one infer that that sort_buffer_size is actually some kind of in-memory buffer.
Additionally, the formula should probably be extended:
total =
innodb_buffer_pool_size +
key_buffer_size +
innodb_additional_mem_pool_size +
innodb_log_buffer_size +
max_connections *
(sort_buffer_size +
read_buffer_size +
binlog_cache_size +
maximum_thread_stack_size);
Noting that "key_buffer_size" is a MyISAM parameter
there is abug in MySQL server that treat open_files_limit and open-files-limit differently also the limit for open-files-limit mentioned on this page is not entirely true
http://www.geeksww.com/tutorials/database_management_systems/mysql/configuration/mysql_open_files_limit_openfileslimit_vs_openfileslimit_on_linux.php
It appears that the "read_buffer_size" setting is used by the MEMORY table engine as the allocation increment size (minus a few bytes). This means that a MEMORY table with *one row* will take up, essentially, "read_buffer_size" bytes. For each on the table, add on another "read_buffer_size" bytes to the table. The table will not change in size again until all of that allocation is used by new rows; then it will grow in increments again.
This is not documented anywhere as far as I can tell, and I only found it after banging my head against a wall looking through the MySQL source code.
To display "buffer" variables
mysql> SHOW VARIABLES LIKE '%buffer%';
To display the current value of a variable (example given below for innodb_buffer_pool_size).
mysql> select @@global.innodb_buffer_pool_size;
Get this value in megabytes;
mysql> select (@@global.innodb_buffer_pool_size/1048576);
Add your own comment.