MySQL :: MySQL 5.6 リファレンスマニュアル

version 5.6

8.0 English
5.7 English
5.6 English

MySQL 5.6 リファレンスマニュアル / ... / MySQL の既知の問題

B.5.8 MySQL の既知の問題

このセクションでは、最新バージョンの 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 が動作しません。
大きい整数値 (2⁶³ から 2⁶⁴−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=old_host_name-bin などのオプションを明示的に使用する必要があります。セクション5.1.3「サーバーコマンドオプション」を参照してください。または、ホスト名の変更が反映されるように、古いファイルを名前変更します。バイナリログの場合は、バイナリログのインデックスファイルを編集して、そこにあるバイナリログファイル名も修正する必要があります。(スレーブサーバーのリレーログも同様です。)
LOAD 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 インデックスを優先するためです。

PREV HOME UP NEXT