IN のサブクエリーの最適化は、= ほど効果はありません。

lower_case_table_names=2 (データベース名およびテーブル名に大文字/小文字のどちらが使用されたかを MySQL が認識するようになります) を使用していても、MySQL が関数 DATABASE() のデータベース名、またはさまざまなログ内 (大文字/小文字が区別されないシステムの) で使用された表記を識別できません。

FOREIGN KEY 制約の削除はレプリケーションでは機能しません。これは、制約がレプリカ上に別の名前を持つ可能性があるためです。

REPLACE (および REPLACE オプションを指定した LOAD DATA) で ON DELETE CASCADE がトリガーされません。

DISTINCT リストに指定されたすべてのカラムのみを使用しない場合、GROUP_CONCAT() 内で ORDER BY を指定した DISTINCT が動作しません。

数値は符号付き整数コンテキストで評価されるため、小数カラムまたは文字列カラムに大きい整数値 (2⁶³ から 2⁶⁴−1) を挿入すると、負の値として挿入されます。

ステートメントベースのバイナリロギングでは、ソースサーバーは実行されたクエリーをバイナリログに書き込みます。 これは、ほとんどの場合に理想的に動作する非常に高速かつコンパクトで効率的なロギング方法です。 ただし、データ変更が非決定的に行われるようにクエリーが設計されている場合は、ソースとレプリカのデータが異なる可能性があります (通常、レプリケーションの外部であっても推奨されません)。

例:

これは、前述したクエリーに決定性順序を保証する ORDER BY 句がない場合にのみ発生することがあります。

たとえば、ORDER BY を使用しない INSERT ... SELECT の場合、SELECT は、ソースおよびレプリカでのオプティマイザによる選択に応じて、異なる順序で行を返すことがあります (これにより、行のランクが異なるため、AUTO_INCREMENT カラムで異なる番号が取得されます)。

クエリーは、次の場合にのみ、ソースとレプリカで異なる方法で最適化されます:

この問題は、mysqlbinlog|mysql を使用したデータベースのリストアに影響することもあります。

この問題を回避するもっとも簡単な方法は、行が常に同じ順序で格納または変更されるように、ORDER BY 句を前述の非決定性クエリーに追加することです。 行ベースのロギング形式または混合したロギング形式を使用することでも、この問題が回避されます。

スタートアップオプションにファイル名を指定しない場合、ログファイル名はサーバーのホスト名に基づいています。 ホスト名を別の名前に変更した場合に同じログファイル名のままにするには、--log-bin=old_host_name-bin などのオプションを明示的に使用する必要があります。 セクション5.1.7「サーバーコマンドオプション」を参照してください。 または、ホスト名の変更が反映されるように、古いファイルを名前変更します。 バイナリログの場合は、バイナリログのインデックスファイルを編集して、そこにあるバイナリログファイル名も修正する必要があります。 (レプリカ上のリレーログにも同じことが当てはまります。)

mysqlbinlog では、LOAD DATA ステートメントの後に残っている一時ファイルは削除されません。 セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照してください。

RENAME が TEMPORARY テーブル、または MERGE テーブルで使用されているテーブルで動作しません。

SET CHARACTER SET を使用したときに、データベース、テーブル、およびカラムの名前に変換された文字を使用できません。

MySQL 8.0.17 より前は、LIKE ... ESCAPE で ESCAPE とともに_または % を使用することはできません。

サーバーは、データ値を比較するときに最初の 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) を超える値に解決される場合は、使用しないようにしてください。

1 つのテーブルには、最大 255 個の ENUM カラムおよび SET カラムを作成できます。

現在、MIN()、MAX()、およびその他の集約関数では、MySQL はセット内の文字列の相対位置ではなく文字列値で ENUM カラムおよび SET カラムを比較します。

UPDATE ステートメントでは、カラムは左から右に更新されます。 更新されたカラムを参照している場合は、元の値ではなく更新された値が取得されます。 たとえば、次のステートメントでは KEY に 1 ではなく 2 がインクリメントされます。

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;

2 番目のケースでは、結果セットに同一の行が 2 つ表示される場合があります (非表示の id カラムの値が異なる可能性があるため)。

これは、結果に ORDER BY のカラムがないクエリーでのみ発生します。

空のセットを返すクエリーに関する PROCEDURE を実行すると、PROCEDURE でカラムが変換されないことがあります。

MERGE タイプのテーブルの作成で、基礎テーブルが互換性のあるタイプであるかどうかがチェックされません。

ALTER TABLE を使用して、MERGE テーブルで使用されるテーブルに UNIQUE インデックスを追加し、次に MERGE テーブルに通常のインデックスを追加したときに、テーブルに古い UNIQUE ではないキーがあった場合、それらのテーブルのキー順序は異なります。 これは、重複キーをできるだけ早く検出できるように、ALTER TABLE が通常のインデックスより UNIQUE インデックスを優先するためです。