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

即使您使用 lower_case_table_names=2（它使 MySQL 能够记住用于数据库和表名的字母大小写），MySQL 也不会记住用于函数 DATABASE() 或各种日志中（在不区分大小写的系统上）的数据库名称的字母大小写。

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

REPLACE（以及带有 REPLACE 选项的 LOAD DATA）不会触发 ON DELETE CASCADE。

如果不在 DISTINCT 列表中使用所有且仅使用这些列，则带有 ORDER BY 的 DISTINCT 在 GROUP_CONCAT() 中不起作用。

将一个大整数值（介于 2⁶³ 和 2⁶⁴−1 之间）插入到 decimal 或字符串列时，它会作为负值插入，因为该数字是在有符号整数上下文中计算的。

使用基于语句的二进制日志记录，源服务器会将执行的查询写入二进制日志。这是一种非常快速、紧凑和高效的日志记录方法，在大多数情况下都能完美运行。但是，如果查询的设计方式使得数据修改是不确定的（即使在复制之外，这通常也不是一种推荐的做法），则源和副本上的数据可能会变得不同。

例如：

当且仅当前面的查询没有保证确定性顺序的 ORDER BY 子句时.

例如，对于没有 ORDER BY 的 INSERT ... SELECT，SELECT 可能会以不同的顺序返回行（这会导致行具有不同的排名，因此在 AUTO_INCREMENT 列中获得不同的数字），具体取决于源和副本上的优化器做出的选择。

仅在以下情况下，查询在源和副本上的优化方式才不同：

此问题也可能会影响使用 mysqlbinlog|mysql 进行的数据库还原。

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

如果您没有使用启动选项指定文件名，则日志文件名将基于服务器主机名。如果将主机名更改为其他名称，要保留相同的日志文件名，则必须显式使用选项，例如 --log-bin=旧主机名-bin。请参阅 第 7.1.7 节“服务器命令选项”。或者，重命名旧文件以反映主机名的更改。如果这些是二进制日志，则必须编辑二进制日志索引文件，并修复其中的二进制日志文件名。（副本上的中继日志也是如此。）

mysqlbinlog 不会删除 LOAD DATA 语句后留下的临时文件。请参阅 第 6.6.9 节“mysqlbinlog — 处理二进制日志文件的实用程序”。

RENAME 对 TEMPORARY 表或 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 精度执行。如果无符号 long long 值解析为大于 63 位（9223372036854775807），则应尽量避免将它们用于位字段以外的任何内容。

一个表中最多可以有 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 类型的表时，不会检查基础表是否是兼容类型。

如果您使用 ALTER TABLE 向 MERGE 表中使用的表添加 UNIQUE 索引，然后在 MERGE 表上添加普通索引，则如果表中存在旧的非 UNIQUE 键，则这些表的键顺序会有所不同。这是因为 ALTER TABLE 会将 UNIQUE 索引放在普通索引之前，以便能够尽早检测到重复键。