子查询优化对IN不如对=有效。

即使您使用了lower_case_table_names=2(启用MySQL记忆数据库和表名的大小写)，MySQL仍然不会记忆函数DATABASE()或日志中的数据库名称的大小写（在不区分大小写的系统上）。

删除FOREIGN KEY约束在复制中不起作用，因为约束可能在副本上有另一个名称。

REPLACE(和LOAD DATA带有REPLACE选项)不会触发ON DELETE CASCADE。

DISTINCT 和 ORDER BY 在GROUP_CONCAT()中不起作用，如果您不使用所有并且只使用在DISTINCT列表中的列。

将大整数值（介于2⁶³和2⁶⁴−1之间）插入到decimal或string列中，它将被插入为负值，因为该数字在有符号整数上下文中被评估。

使用语句式二进制日志时，源服务器将执行的查询写入到二进制日志中。这是一个非常快速、紧凑和高效的日志方法，在大多数情况下都能工作。但是，如果查询设计得这样，使数据修改 nondeterministic（通常不推荐的实践，即使在 replication 之外），那么源服务器和副本之间的数据可能会不同。

例如：

如果前面的查询没有确定顺序的ORDER BY子句.

例如，对于无ORDER BY的INSERT ... SELECT语句，可能在不同的顺序返回行（结果是行具有不同的排名，因此在AUTO_INCREMENT列中获取不同的数字），取决于源服务器和副本优化器的选择。

查询在源服务器和副本上被优化 differently 只有在以下情况下：

这个问题也可能影响使用mysqlbinlog|mysql进行数据库恢复的过程。

避免这个问题最简单的方法是将前述非确定性查询添加ORDER BY子句，以确保行始终以相同的顺序存储或修改。使用行基于或混合日志格式也可以避免这个问题。

日志文件名基于服务器主机名称，如果您没有使用启动选项指定文件名，则需要显式使用选项，如--log-bin=old_主机名称-bin。请参阅第7.1.7节，“服务器命令选项”。Alternatively, rename the old files to reflect your host name change. If these are binary logs, you must edit the binary log index file and fix the binary log file names there as well. (The same is true for the relay logs on a replica.)

mysqlbinlog不删除LOAD DATA语句后留下的临时文件。请参阅第6.6.9节，“mysqlbinlog — Utility for Processing Binary Log Files”。

RENAME不支持临时表或在MERGE表中使用的表。

使用SET CHARACTER SET时，您不能在数据库、表和列名称中使用翻译字符。

服务器在比较数据值时，只使用前max_sort_length个字节。这意味着，如果值只在max_sort_length个字节后不同，则不能可靠地在GROUP BY、ORDER BY或DISTINCT中使用这些值。要解决这个问题，可以增加变量的值。默认的max_sort_length值为1024，可以在服务器启动时或运行时更改。

数值计算使用BIGINT或DOUBLE(通常都是64位长)。函数的精度取决于函数。总的规则是，位操作函数使用BIGINT精度，IF()和ELT()使用BIGINT或DOUBLE精度，其他函数使用DOUBLE精度。您应该尽量避免使用unsigned long long值，如果它们 resolve到大于63位（9223372036854775807）的bit fields以外的任何情况。

您可以在一个表中拥有最多255个ENUM和SET列。

在MIN()、MAX()等聚合函数中，MySQL当前将ENUM和SET列比较为字符串值，而不是根据字符串在集合中的相对位置。

在UPDATE语句中，列从左到右更新。如果您引用了更新的列，您将获得更新后的值，而不是原始值。例如，以下语句将KEY增加2，而不是1：

mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;

您可以在同一个查询中引用多个临时表，但不能对给定的临时表进行多次引用。例如，以下语句不工作：

mysql> SELECT * FROM temp_table, temp_table AS t2;
ERROR 1137: Can't reopen table: 'temp_table'

优化器可能会将DISTINCT处理方式不同，当您在连接中使用隐藏列时，而不是不使用时。在连接中，隐藏列被计入结果（即使它们不显示），而在正常查询中，隐藏列不参与DISTINCT比较。

以下是一个示例：

SELECT DISTINCT mp3id FROM band_downloads
       WHERE userid = 9 ORDER BY id DESC;

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;

在第二种情况下，您可能会在结果集中获得两个相同的行（因为隐藏的id列中的值可能不同）。

请注意，这只发生在没有ORDER BY列的查询中。

如果在查询中执行一个PROCEDURE，并且该查询返回空集，在某些情况下，PROCEDURE不会转换列。

创建类型为MERGE的表不检查 underlying 表是否兼容类型。

如果使用ALTER TABLE将用于MERGE表的表添加唯一索引，然后在MERGE表上添加普通索引，key顺序在有旧非唯一键的表中不同。这是因为ALTER TABLE将唯一索引置于普通索引前，以尽早检测重复键。