MySQL 5.1 リファレンスマニュアル :: 13 ストレージエンジンとテーブルタイプ :: 13.5 InnoDB ストレージ エンジン :: 13.5.16 InnoDB テーブル上の制約
« 13.5.15.2 OS エラー コード

13.5.17 InnoDB トラブルシューティング »
Section Navigation      [Toggle]
  • 13.5 InnoDB ストレージ エンジン
  • 13.5.1 InnoDB 概要
  • 13.5.2 InnoDB 連絡先情報
  • 13.5.3 InnoDB 設定
  • 13.5.4 InnoDB 起動オプションとシステム変数
  • 13.5.5 InnoDB テーブルスペースを作成する
  • 13.5.6 InnoDB テーブルの作成と利用
  • 13.5.7 InnoDB データとログ ファイルの追加と削除
  • 13.5.8 InnoDB データベースのバックアップと復旧
  • 13.5.9 InnoDB データベースを別のマシンに移動する
  • 13.5.10 InnoDB トランザクション モデルとロック
  • 13.5.11 InnoDB パフォーマンス チューニング ヒント
  • 13.5.12 マルチバージョンの実装
  • 13.5.13 InnoDB テーブルとインデックス構造
  • 13.5.14 InnoDB ファイル領域の管理とディスク I/O
  • 13.5.15 InnoDB エラー処理
  • 13.5.16 InnoDB テーブル上の制約
  • 13.5.17 InnoDB トラブルシューティング

13.5.16. InnoDB テーブル上の制約

  • 警告:MySQL システムテーブルを mysql データベースの中で MyISAM から InnoDB テーブルに変換 しない でください!これはサポートされていない操作です。もしこれをしてしまうと、バックアップから古いシステム テーブルを復旧するか、mysql_install_db スクリプトを利用してそれらを再生成するまで MySQL は再起動しません。

  • テーブルが1000 以上のカラムを含む事はできません。

  • 内部的な最大キー長は3500バイトですが、MySQL 自体はそれを1024バイトに制限しています。

  • VARCHAR、BLOB そして TEXT カラム以外の最大行長は、データベース ページの半分よりも少し短いです。これは、最大行長は約8000バイトであるという事です。LONGBLOB と LONGTEXT カラムは4GB 以下である必要があり、BLOB と TEXT カラムを含んだ合計行長は4GB 以下でなければいけません。InnoDB が行内の VARCHAR、BLOB、または TEXT カラムの最初の768バイトを格納し、残りは別のページに格納されます。

  • InnoDB は内部的にサイズ65535以上の行をサポートしますが、65535以上のサイズの VARCHAR カラムを含む行を定義する事はできません:

    mysql> CREATE TABLE t (a VARCHAR(8000), b VARCHAR(10000),
        -> c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000),
        -> f VARCHAR(10000), g VARCHAR(10000)) ENGINE=InnoDB;
    ERROR 1118 (42000): Row size too large. The maximum row size for the
    used table type, not counting BLOBs, is 65535. You have to change some
    columns to TEXT or BLOBs
    
  • いくつかの古い OS では、ファイルは2GB 以下でなければいけません。これは InnoDB 自体の制限ではありませんが、もし大きいテーブルスペースを要求すると、1つではなく複数の小さいデータ ファイルを利用してそれを設定するか、または大きいデータ ファイルをファイルしなければいけません。

  • 結合した InnoDB ログ ファイルのサイズは4GB 以下でなければいけません。

  • 最小テーブルスペース サイズは10MB です。最大テーブルスペース サイズは40億データベース ページ(64TB)です。これはテーブルにとっても最大サイズです。

  • InnoDB テーブルは FULLTEXT インデックスをサポートしません。

  • InnoDB テーブルは空間タイプはサポートしますが、そのインデックスはサポートしません。

  • ANALYZE TABLE は、各インデックス ツリーにランダムにダイブし、インデックス濃度概算をそれに応じて更新する事で、インデックス濃度(SHOW INDEX アウトプットの Cardinality カラム内に表示されるように)を決定します。これらは単なる概算である為、ANALYZE TABLE を繰り返す事で別の数値が導かれる事があると覚えておいてください。これによって ANALYZE TABLE の InnoDB テーブル上での速度は速くなりますが、全ての行を考慮する訳ではないので100% 正確とは言えません。

    MySQL はインデックス濃度概算を結合最適化でしか利用しません。いくつかの結合が正しい方法で最適化されなければ、ANALYZE TABLE を利用してみると良いでしょう。ANALYZE TABLE が特定のテーブルに十分な値を発行しなかった場合、特定のインデックスの利用を強制する為にクエリと FORCE INDEX を共に利用するか、または MySQL がテーブル スキャンよりもインデックス検索を好む事を保証する為に max_seeks_for_key システム変数を設定する事ができます。項4.2.3. 「システム変数」 と 項B.1.6. 「Optimizer-Related Issues」 を参照して下さい。

  • SHOW TABLE STATUS はテーブルが確保した物理サイズ以外、InnoDB テーブルに、正確な統計を与えません。行カウントは SQL 最適化で利用される単なる概算です。

  • InnoDB はテーブル内の行の内部カウントを保持しません。(実際は、マルチ バージョンの為、少々複雑になります。)SELECT COUNT(*) FROM t ステートメントを処理する為に、InnoDB はテーブルのインデックスをスキャンする必要があり、それはもしインデックスが完全にバッファ プールの中に無いのであれば時間がかかります。 速いカウントの為には、自分で作成したカウンタ テーブルを利用し、そのカウンタが行う挿入と削除に従ってアプリケーションを更新させなければいけません。テーブルが頻繁に変更されないのであれば、MySQL クエリ キャッシュを利用するのが良い解決法です。もし行カウントの概算で充分であれば、SHOW TABLE STATUS を利用する事もできます。詳しくは 項13.5.11. 「InnoDB パフォーマンス チューニング ヒント」 を参照してください。

  • Windows 上では InnoDB はいつもデータベースとテーブル名を小文字で内部的に格納します。Unix から Windows に、または Windows から Unix にデータベースをバイナリ フォーマットで移動するには、データベースとテーブルを作成する時に必ず明示的に小文字の名前を利用する必要があります。

  • AUTO_INCREMENT カラムに対しては、テーブルにインデックスを常に定義する必要があり、そしてそのインデックスは AUTO_INCREMENT カラムだけを含んでいなければいけません。MyISAM テーブル内では、AUTO_INCREMENT カラムは複合カラム インデックスの一部であるかもしれません。

  • テーブル上であらかじめ指定された AUTO_INCREMENT カラムを初期化している間、InnoDB は AUTO_INCREMENT カラムと関係しているインデックスの最後に専用ロックを設定します。

    自動インクリメント カウンタにアクセスする時、InnoDB は、トランザクション全体の最後までではなく、現在の SQL ステートメントの最後まで続く、特別なテーブル ロック モード AUTO-INC を利用します。AUTO-INC テーブル ロックが行われている間は、別のクライアントはテーブルに挿入ができない事に注意してください。 項13.5.10.2. 「InnoDB と AUTOCOMMIT」 を参照してください。

  • MySQL サーバを再起動する時、InnoDB は AUTO_INCREMENT カラムの為に生成されたが、格納はされなかった古い値を再利用するかもしれません。(それは、ロールバックされた古いトランザクション内で生成された値です。)

  • AUTO_INCREMENT カラムが値を使い果たした時、InnoDB は BIGINT を -9223372036854775808 に、そして BIGINT UNSIGNED を 1 に切り上げます。しかし、BIGINT 値は64ビットあるので、もし1秒に100万行挿入しようとすると、BIGINT がその上限に達するまで3百万年ほどかかるという事を覚えておいてください。その他の全ての整数タイプ カラムを利用すると、複製キー エラーが発生します。これは最も一般的な MySQL 性能であり、特定のストレージ エンジンに関する事ではないので、MyISAM の機能の仕方と似ています。

  • DELETE FROM tbl_name はテーブルを再生成しませんが、その代わりに全ての行を1つ1つ削除します。

  • 状況によっては、InnoDB テーブルの TRUNCATE tbl_name は DELETE FROM tbl_name にマップされ、AUTO_INCREMENT カウンタをリセットしません。詳しくは 項12.2.9. 「TRUNCATE 構文」 を参照してください。

  • MySQL 5.1 では、もし innodb_table_locks=1 (デフォルト)であれば、MySQL LOCK TABLES 操作は各テーブルに2つのロックを取得します。 MySQL レイヤのテーブル ロックに加えて、それは InnoDB テーブル ロックも取得します。MySQL の古いバージョンは InnoDB テーブルロックを取得しませんでした。innodb_table_locks=0 を設定する事で古いバージョンを選択する事ができます。もし InnoDB テーブル ロックが取得されなければ、テーブルのいくつかのレコードが別のトランザクションによってロックされなくても LOCK TABLES が完了します。

  • トランザクションによって保持される全ての InnoDB ロックは、トランザクションがコミットされた時か異常終了した時にリリースされます。従って、取得された InnoDB テーブル ロックは直ちにリリースされるので、LOCK TABLES を AUTOCOMMIT=1 モードの InnoDB テーブル上で呼び出す意味はありません。

  • トランザクションの最中にさらにテーブルをロックするのが有効な場合があります。残念ながら、MySQL 内の LOCK TABLES は暗黙の COMMIT と UNLOCK TABLES を実行します。LOCK TABLES の InnoDB 変異形は、トランザクションの最中で実行できるように作られています。

  • 複製スレーブ サーバを設定する為の LOAD TABLE FROM MASTER ステートメントは InnoDB テーブルには機能しません。次善策は、マスタ上でテーブルを MyISAM に変更し、それをロードし、その後マスタ テーブルを再度 InnoDB に戻すという方法です。もしテーブルが、外部キーなどのような InnoDB 特有の特徴を利用していたら、これは行わないでください。

  • InnoDB 内のデフォルト データベース ページ サイズは16KB です。コードを再コンパイルする事で、8KB から64KB の範囲の値に設定する事ができます。univ.i ソース ファイル内で UNIV_PAGE_SIZE と UNIV_PAGE_SIZE_SHIFT の値を更新しなければいけません。

  • トリガは現在、転送された外部キー アクションによって有効化されません。

Copyright © 1997, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices
Top / Previous / Next / Up / Table of Contents
© 2010, Oracle Corporation and/or its affiliates