用於 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 之間）插入十進位或字串欄位時，它會作為負值插入，因為該數字會在帶正負號的整數內容中進行評估。

使用以陳述式為基礎的二進位記錄時，來源伺服器會將執行的查詢寫入二進位記錄檔。這是一種非常快速、精簡且有效率的記錄方法，在大多數情況下都運作良好。然而，如果查詢的設計方式使得資料修改是不確定性的（通常即使在複寫之外也不建議這樣做），則來源和複本上的資料可能會變得不同。

例如

僅當且僅當上述查詢沒有保證確定性順序的 ORDER BY 子句時.

例如，對於沒有 ORDER BY 的 INSERT ... SELECT，SELECT 可能會以不同的順序傳回資料列（這會導致資料列具有不同的排名，因此在 AUTO_INCREMENT 欄位中取得不同的數字），具體取決於來源和複本上的最佳化工具所做的選擇。

只有在下列情況下，查詢才會在來源和複本上進行不同的最佳化

此問題也可能會影響使用 mysqlbinlog|mysql 還原資料庫。

避免此問題最簡單的方式是在上述不確定性查詢中新增 ORDER BY 子句，以確保資料列始終以相同的順序儲存或修改。使用以資料列為基礎或混合的記錄格式也可避免此問題。

如果您未使用啟動選項指定檔案名稱，記錄檔名稱會以伺服器主機名稱為基礎。如果您將主機名稱變更為其他名稱，要保留相同的記錄檔名稱，您必須明確使用選項，例如 --log-bin=old_host_name-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 精確度執行。如果非位元欄位的值解析後大於 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 索引放在一般索引之前，以便盡早偵測到重複的索引鍵。