このセクションでは、最新バージョンの MySQL の既知の問題を一覧表示します。
プラットフォーム固有の問題については、セクション2.1「一般的なインストールガイド」およびセクション24.4「MySQL のデバッグおよび移植」のインストールおよび移植の手順を参照してください。
次の問題は既知の問題です。
IN
のサブクエリーの最適化は、=
ほど効果はありません。lower_case_table_names=2
(データベース名およびテーブル名に大文字/小文字のどちらが使用されたかを MySQL が認識するようになります) を使用していても、MySQL が関数DATABASE()
のデータベース名、またはさまざまなログ内 (大文字/小文字が区別されないシステムの) で使用された表記を識別できません。スレーブで制約に別の名前がある可能性があるため、
FOREIGN KEY
制約のドロップがレプリケーションで動作しません。REPLACE
(およびREPLACE
オプションを指定したLOAD DATA
) でON DELETE CASCADE
がトリガーされません。DISTINCT
リストに指定されたすべてのカラムのみを使用しない場合、GROUP_CONCAT()
内でORDER BY
を指定したDISTINCT
が動作しません。大きい整数値 (263 から 264−1 まで) を 10 進数カラムまたは文字列カラムに挿入する場合、数値は符号付き整数のコンテキストで評価されるため、負の値として挿入されます。
ANALYZE TABLE
、OPTIMIZE TABLE
、およびREPAIR TABLE
が、INSERT DELAYED
を使用している非トランザクションテーブルで問題となることがあります。-
ステートメントベースのバイナリロギングでは、マスターは実行されたクエリーをバイナリログに書き込みます。これは、ほとんどの場合に理想的に動作する非常に高速かつコンパクトで効率的なロギング方法です。ただし、データの変更が非決定的であるようにクエリーが設計されている (通常、レプリケーション以外でも推奨されるやり方ではありません) 場合、マスターおよびスレーブのデータで相違が発生する可能性があります。
例:
ゼロ値または
NULL
値をAUTO_INCREMENT
カラムに挿入するCREATE TABLE ... SELECT
ステートメントまたはINSERT ... SELECT
ステートメント。ON DELETE CASCADE
プロパティーが指定された外部キーを持つテーブルから行を削除する場合のDELETE
。挿入されるデータに重複キー値がある場合の
REPLACE ... SELECT
、INSERT IGNORE ... SELECT
。
これは、前述したクエリーに決定性順序を保証する
ORDER BY
句がない場合にのみ発生することがあります。たとえば、
ORDER BY
が指定されていないINSERT ... SELECT
の場合、マスターおよびスレーブでのオプティマイザの選択によって、SELECT
が異なる順序で行を返すことがあります (それにより、行が異なるランクを持つことになり、AUTO_INCREMENT
カラムで異なる数値が取得されます)。次の場合にのみ、マスターとスレーブでクエリーの最適化が異なる結果となります。
マスターとスレーブで、テーブルが異なるストレージエンジンを使用して格納される。(マスターとスレーブで異なるストレージエンジンを使用できます。たとえば、マスターでは
InnoDB
を使用するが、スレーブの使用可能なディスク領域が少ない場合は、スレーブでMyISAM
を使用できます。)MySQL のバッファーサイズ (
key_buffer_size
など) がマスターとスレーブで異なる。マスターとスレーブで異なるバージョンの MySQL を実行していて、オプティマイザのコードがそれらのバージョンで異なる。
この問題は、mysqlbinlog|mysql を使用したデータベースのリストアに影響することもあります。
この問題を回避するもっとも簡単な方法は、行が常に同じ順序で格納または変更されるように、
ORDER BY
句を前述の非決定性クエリーに追加することです。行ベースのロギング形式または混合したロギング形式を使用することでも、この問題が回避されます。 スタートアップオプションにファイル名を指定しない場合、ログファイル名はサーバーのホスト名に基づいています。ホスト名を別の名前に変更した場合に同じログファイル名のままにするには、
--log-bin=
などのオプションを明示的に使用する必要があります。セクション5.1.3「サーバーコマンドオプション」を参照してください。または、ホスト名の変更が反映されるように、古いファイルを名前変更します。バイナリログの場合は、バイナリログのインデックスファイルを編集して、そこにあるバイナリログファイル名も修正する必要があります。(スレーブサーバーのリレーログも同様です。)old_host_name
-binLOAD DATA INFILE
ステートメントのあとに残っている一時ファイルが、mysqlbinlog によって削除されません。セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照してください。RENAME
がTEMPORARY
テーブル、またはMERGE
テーブルで使用されているテーブルで動作しません。SET CHARACTER SET
を使用したときに、データベース、テーブル、およびカラムの名前に変換された文字を使用できません。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 番目の例では、MySQL Server 3.23.x を使用すると、結果セットに 2 つの同じ行が取得されることがあります (隠しカラム
id
の値が異なる可能性があるためです)。これは、結果に
ORDER BY
のカラムがないクエリーでのみ発生します。 空のセットを返すクエリーに関する
PROCEDURE
を実行すると、PROCEDURE
でカラムが変換されないことがあります。MERGE
タイプのテーブルの作成で、基礎テーブルが互換性のあるタイプであるかどうかがチェックされません。ALTER TABLE
を使用して、MERGE
テーブルで使用されるテーブルにUNIQUE
インデックスを追加し、次にMERGE
テーブルに通常のインデックスを追加したときに、テーブルに古いUNIQUE
ではないキーがあった場合、それらのテーブルのキー順序は異なります。これは、重複キーをできるだけ早く検出できるように、ALTER TABLE
が通常のインデックスよりUNIQUE
インデックスを優先するためです。