[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following problems are known and fixing them is a high priority:
FOREIGN KEY
constraint doesn't work in replication as the
constraint may have another name.
UNION ALL
and UNION DISTINCT
in the same query.
If you use ALL
for one UNION
, it is used for all
of them.
DROP TABLE
command before the table is
used in the transaction itself. We plan to fix this in 5.0 by
having the DROP TABLE
wait until the table is not used in any
transaction.
FLUSH TABLES WITH READ LOCK
does not block CREATE TABLE
or
COMMIT
, which make cause a problem with the binary log position when
doing a full backup of tables and the binary log.
ANALYZE TABLE
on a BDB
table may in some cases make the table
unusable until one has restarted mysqld
. If this happens, you will
see errors of the following form in the MySQL error file:
001207 22:07:56 bdb: log_flush: LSN past current end-of-log |
FROM
part of a SELECT
statement, but silently
ignores them. The reason for not giving an error is that many clients
that automatically generate queries add parentheses in the FROM
part even where they are not needed.
RIGHT JOINS
or combining LEFT
and
RIGHT
join in the same query may not give a correct answer as
MySQL only generates NULL
rows for the table preceding a LEFT
or
before a RIGHT
join. This will be fixed in 5.0 at the same time
we add support for parentheses in the FROM
part.
ALTER TABLE
on a BDB
table on which you are
running multiple-statement transactions until all those transactions complete.
(The transaction will probably be ignored.)
ANALYZE TABLE
, OPTIMIZE TABLE
, and REPAIR TABLE
may
cause problems on tables for which you are using INSERT DELAYED
.
LOCK TABLE ...
and FLUSH TABLES ...
doesn't
guarantee that there isn't a half-finished transaction in progress on the
table.
BDB
tables are a bit slow to open. If you have many BDB
tables in a
database, it will take a long time to use the mysql
client on the
database if you are not using the -A
option or if you are using
rehash
. This is especially notable when you have a large table
cache.
CREATE ... SELECT
or
INSERT ... SELECT
statements that
insert zero or NULL
values into an AUTO_INCREMENT
column.
DELETE
if you are
deleting rows from a table which has foreign keys with ON DELETE
CASCADE
properties.
REPLACE ... SELECT
,
INSERT IGNORE ... SELECT
if you have
duplicate key values in the inserted data.
ORDER BY
clause guaranteeing a deterministic order.
Indeed, for example for INSERT ... SELECT
with no ORDER
BY
, the SELECT
may return rows in a different order
(which will result in a row having different ranks, hence getting a
different number in the auto_increment
column),
depending on the choices made by the optimizers on the master and
slave. A query will be optimized differently on the master and slave only if:
OPTIMIZE TABLE
was run on the master tables and not on
the slave tables (to fix this, since MySQL 4.1.1, OPTIMIZE
, ANALYZE
and REPAIR
are written to the binary log).
InnoDB
on the master,
but MyISAM
on the slave if the slave has less available disk
space.)
key_buffer_size
, etc.) are different on
the master and slave.
This problem may also affect database restoration using mysqlbinlog|mysql
.
The easiest way to avoid this problem in all cases is add an
ORDER BY
clause to
such non-deterministic queries to ensure that the rows are always
stored or modified in the same order.
In future MySQL versions, we will automatically add an ORDER BY
clause when needed.
The following problems are known and will be fixed in due time:
--log-bin=old_host_name-bin
if you change your host name to
something else. Another option is to just rename the old files to
reflect your hostname change. See section 5.2.1 mysqld
Command-line Options.
mysqlbinlog
will not delete temporary files left after a
LOAD DATA INFILE
command. See section mysqlbinlog
.
RENAME
doesn't work with TEMPORARY
tables or tables used in a
MERGE
table.
RPAD()
function in a query that has to be
resolved by using a temporary table, all resulting strings will
have rightmost spaces removed. This is an example of such a query:
SELECT RPAD(t1.column1, 50, ' ') AS f2, RPAD(t2.column2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record; |
The final result of this bug is that you will not be able to get spaces on the right side of the resulting values. The problem also occurs for any other string function that adds spaces to the right.
The reason for this is due to the fact that HEAP
tables, which are used
first for temporary tables, are not capable of handling VARCHAR
columns.
This behavior exists in all versions of MySQL. It will be fixed in one of the 4.1 series releases.
CHAR(255)
) in table names, column names, or enumerations.
This is scheduled to be fixed in version 5.1 when we have new table
definition format files.
SET CHARACTER SET
, you can't use translated
characters in database, table, and column names.
_
or %
with ESCAPE
in LIKE
... ESCAPE
.
DECIMAL
column with a number stored in different
formats (+01.00, 1.00, 01.00), GROUP BY
may regard each value
as a different value.
DELETE FROM merge_table
used without a WHERE
clause
will clear only the mapping for the table, not delete everything in the
mapped tables.
BLOB
values can't "reliably" be used in GROUP BY
or
ORDER BY
or DISTINCT
. Only the first max_sort_length
bytes are used when comparing BLOB
values in these cases.
The default value of max_sort_length
value is 1024. It can be changed
at server startup time. A workaround for most cases is to use a substring.
For example:
SELECT DISTINCT LEFT(blob,2048) FROM tbl_name
.
BIGINT
or DOUBLE
(both are
normally 64 bits long). It depends on the function which precision one
gets. The general rule is that bit functions are done with BIGINT
precision, IF
, and ELT()
with BIGINT
or DOUBLE
precision and the rest with DOUBLE
precision. You should try to
avoid using unsigned long long values if they resolve to be bigger than
63 bits (9223372036854775807) for anything other than bit fields.
MySQL Server 4.0 has better BIGINT
handling than 3.23.
BLOB
and TEXT
columns, automatically
have all trailing spaces removed when retrieved. For CHAR
types this
is okay. The bug is
that in MySQL Server, VARCHAR
columns are treated the same way.
ENUM
and SET
columns in one table.
MIN()
, MAX()
, and other aggregate functions, MySQL
currently compares ENUM
and SET
columns by their string
value rather than by the string's relative position in the set.
mysqld_safe
redirects all messages from mysqld
to the
mysqld
log. One problem with this is that if you execute
mysqladmin refresh
to close and reopen the log,
stdout
and stderr
are still redirected to the old log.
If you use --log
extensively, you should edit mysqld_safe
to
log to `'hostname'.err' instead of `'hostname'.log' so you can
easily reclaim the space for the old log by deleting the old one and
executing mysqladmin refresh
.
UPDATE
statement, columns are updated from left to right. If
you refer to an updated column, you will get the updated value instead of the
original value. For example:
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1; |
This will increment KEY
by 2
, not 1
.
mysql> SELECT * FROM temporary_table, temporary_table AS t2; |
DISTINCT
differently if you are using
'hidden' columns in a join or not. In a join, hidden columns are
counted as part of the result (even if they are not shown) while in
normal queries hidden columns don't participate in the DISTINCT
comparison. We will probably change this in the future to never compare
the hidden columns when executing DISTINCT
.
An example of this is:
SELECT DISTINCT mp3id FROM band_downloads WHERE userid = 9 ORDER BY id DESC; |
and
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; |
In the second case you may in MySQL Server 3.23.x get two identical rows in
the result set (because the values in the hidden id
column may differ).
Note that this happens only for queries where you don't have the
ORDER BY
columns in the result, something that you are not allowed
to do in SQL-92.
If you set a column to an incorrect value, MySQL Server will, instead of
doing a rollback, store the best possible value
in the column:
NULL
into a column that doesn't allow
NULL
values, MySQL Server stores 0 or "
(the empty
string) in it instead. (This behavior can, however, be changed with the
-DDONT_USE_DEFAULT_FIELDS
compile option.)
DATE
and
DATETIME
columns (like '2000-02-31'
or '2000-02-00'
).
The idea is that it's not the job of the SQL server to validate dates. If
MySQL can store a date value and retrieve exactly the same value, MySQL
stores it as given. If the date is totally wrong (outside the server's
ability to store it), the special date value '0000-00-00'
is stored
in the column instead.
ENUM
column to an unsupported value, it is set to
the error value empty string
, with numeric value 0.
SET
column to an unsupported value, the value is ignored.
PROCEDURE
on a query that returns an empty set,
in some cases the PROCEDURE
will not transform the columns.
MERGE
doesn't check if the underlying
tables are of compatible types.
NaN
, -Inf
, and Inf
values in DOUBLE
columns. Using these will cause problems when trying to export
and import data. We should as an intermediate solution change NaN
to
NULL
(if possible) and -Inf
and Inf
to the
minimum respective maximum possible double
value.
ALTER TABLE
to first add a UNIQUE
index to a
table used in a MERGE
table and then use ALTER TABLE
to
add a normal index on the MERGE
table, the key order will be
different for the tables if there was an old key that was not unique in the
table. This is because ALTER TABLE
puts UNIQUE
indexes before
normal indexes to be able to detect duplicate keys as early as possible.
The following are known bugs in earlier versions of MySQL:
DROP TABLE
on a table that is
one among many tables that is locked with LOCK TABLES
.
LOCK table
with WRITE
.
FLUSH TABLES
.
UPDATE
that updated a key with
a WHERE
on the same key may have failed because the key was used to
search for records and the same row may have been found multiple times:
UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100; |
A workaround is to use:
mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100; |
This will work because MySQL Server will not use an index on expressions in
the WHERE
clause.
For platform-specific bugs, see the sections about compiling and porting. See section 2.3 MySQL Installation Using a Source Distribution. See section D. Porting to Other Systems.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |