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

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

インデックスキーの接頭辞は最大 767 バイトです。項8.1.13. 「CREATE INDEX 構文」 を参照してください。

可変長カラム (VARBINARY、VARCHAR、BLOB、および TEXT) を除く行の最大長は、データベースページの半分よりも少し短くなります。これは、最大行長は約 8000 バイトであるということです。LONGBLOB と LONGTEXT カラムは 4G バイト以下である必要があり、BLOB と TEXT カラムを含んだ合計行長は 4G バイト以下でなければいけません。

長さが半ページ未満の行では、そのすべてがローカルのページ内に格納されます。項9.11.2. 「ファイル領域管理」で説明したように、半ページを超える行では、その行が半ページ以内に収まるように、可変長カラムが外部オフページストレージの対象として選択されます。

InnoDB は内部的に 65535 を超えるサイズの行をサポートしますが、VARBINARY または VARCHAR カラムを含む行のサイズを、次のように 65535 を超える値にすることはできません。

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 では、ファイルは 2G バイト以下でなければいけません。これは InnoDB 自体の制限ではありませんが、もし大きいテーブル領域を要求すると、1 つではなく複数の小さいデータファイルを利用してそれを設定するか、または大きいデータファイルをファイルしなければいけません。

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

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

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

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

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

MySQL はインデックスカーディナリティー概算を結合最適化でしか利用しません。いくつかの結合が正しい方法で最適化されなければ、ANALYZE TABLE を利用してみると良いでしょう。ANALYZE TABLE が特定のテーブルに十分な値を発行しなかった場合、特定のインデックスの利用を強制するためにクエリーと FORCE INDEX を共に利用するか、または MySQL がテーブル走査よりもインデックス検索を好むことを保証するために max_seeks_for_key システム変数を設定することができます。Server System Variables、Optimizer-Related Issues を参照してください。

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

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

MySQL サーバーを再起動すると、InnoDB は、AUTO_INCREMENT カラム用に生成されたが一度も格納されなかった古い値 (つまり、ロールバックされた古いトランザクション内で生成された値) を再利用する可能性があります。

AUTO_INCREMENT カラムが値を使い果たしたとき、InnoDB は BIGINT を -9223372036854775808 に、そして BIGINT UNSIGNED を 1 に切り上げます。しかし、BIGINT 値は 64 ビットあるので、もし 1 秒に 100 万行挿入しようとすると、BIGINT がその上限に達するまで 30 万年ほどかかります。その他のすべての整数型カラムを利用すると、重複キーエラーが発生します。これはもっとも一般的な MySQL 性能であり、特定のストレージエンジンに関することではないので、MyISAM の機能の仕方と似ています。

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

状況によっては、InnoDB テーブルの TRUNCATE tbl_name は DELETE FROM tbl_name にマップされます。項8.2.10. 「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 テーブルロックはすぐに解放されるので、LOCKTABLES を autocommit = 1 モードの InnoDB テーブル上で呼び出す意味はありません。

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

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

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

現時点では、カスケード外部キーアクションがトリガーを有効にしません。

内部 InnoDB カラム (DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR、DB_MIX_ID など) の名前と一致するカラム名を持つテーブルを作成することはできません。MySQL5.1.10 以前のバージョンではこれはクラッシュの原因となり、5.1.10 からはサーバーがエラー 1005 を報告し、エラーメッセージ内でエラー –1 を参照します。この制限は、大文字の名前を使用する場合にしか適用されません。

InnoDB では、データを変更して取り消しレコードを作成した並列トランザクションの数は、1023 個までに制限されます。回避方法としては、トランザクションをできるだけ小規模かつ高速に保つ、トランザクションの終了付近まで変更を遅らせる、クライアントとサーバー間の遅延待ち時間を低減するためにストアドルーチンを使用する、などが挙げられます。アプリケーションは、クライアント側で時間のかかる処理を行う前にトランザクションをコミットすべきです。