Known Issues in MySQL
2975
C.5.7.2.
TEMPORARY
Table Problems
The following list indicates limitations on the use of
TEMPORARY
tables:
• A
TEMPORARY
table can only be of type
MEMORY
,
MyISAM
,
MERGE
, or
InnoDB
.
Temporary tables are not supported for MySQL Cluster.
• You cannot refer to a
TEMPORARY
table more than once in the same query. For example, the
following does not work:
mysql>
SELECT * FROM temp_table, temp_table AS t2;
ERROR 1137: Can't reopen table: 'temp_table'
This error also occurs if you refer to a temporary table multiple times in a stored function under
different aliases, even if the references occur in different statements within the function.
• The
SHOW TABLES
statement does not list
TEMPORARY
tables.
• You cannot use
RENAME
to rename a
TEMPORARY
table. However, you can use
ALTER TABLE
instead:
mysql>
ALTER TABLE orig_name RENAME new_name;
• There are known issues in using temporary tables with replication. See
Section 16.4.1, “Replication
Features and Issues”
, for more information.
C.5.8. Known Issues in MySQL
This section lists known issues in recent versions of MySQL.
For information about platform-specific issues, see the installation and porting instructions in
Section 2.20, “Operating System-Specific Notes”
, and
MySQL Internals: Porting to Other Systems
.
The following problems are known:
• Subquery optimization for
IN
is not as effective as for
=
.
• Even if you use
lower_case_table_names=2
(which enables MySQL to remember the case used
for databases and table names), MySQL does not remember the case used for database names for
the function
DATABASE()
[960]
or within the various logs (on case-insensitive systems).
• Dropping a
FOREIGN KEY
constraint does not work in replication because the constraint may have
another name on the slave.
•
REPLACE
(and
LOAD DATA
with the
REPLACE
option) does not trigger
ON DELETE CASCADE
.
•
DISTINCT
with
ORDER BY
does not work inside
GROUP_CONCAT()
[970]
if you do not use all and
only those columns that are in the
DISTINCT
list.
• If one user has a long-running transaction and another user drops a table that is updated in the
transaction, there is small chance that the binary log may contain the
DROP TABLE
statement before
the table is used in the transaction itself.
• When inserting a big integer value (between 2
63
and 2
64
–1) into a decimal or string column, it is
inserted as a negative value because the number is evaluated in a signed integer context.
•
FLUSH TABLES WITH READ LOCK
does not block
COMMIT
if the server is running without binary
logging, which may cause a problem (of consistency between tables) when doing a full backup.
•
ANALYZE TABLE
on a
BDB
table may in some cases make the table unusable until you restart
mysqld
. If this happens, look for errors of the following form in the MySQL error file:
Summary of Contents for 5.0
Page 1: ...MySQL 5 0 Reference Manual ...
Page 18: ...xviii ...
Page 60: ...40 ...
Page 396: ...376 ...
Page 578: ...558 ...
Page 636: ...616 ...
Page 844: ...824 ...
Page 1234: ...1214 ...
Page 1427: ...MySQL Proxy Scripting 1407 ...
Page 1734: ...1714 ...
Page 1752: ...1732 ...
Page 1783: ...Configuring Connector ODBC 1763 ...
Page 1793: ...Connector ODBC Examples 1773 ...
Page 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Page 2850: ...2830 ...
Page 2854: ...2834 ...
Page 2928: ...2908 ...
Page 3000: ...2980 ...
Page 3122: ...3102 ...
Page 3126: ...3106 ...
Page 3174: ...3154 ...
Page 3232: ...3212 ...