| [ < ] | [ > ] | [ << ] | [ 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] | [ ? ] |