Warnung: Konvertieren Sie niemals MySQL-Systemtabellen in der mysql-Datenbank aus dem MyISAM- in das InnoDB-Format! Diese Operation wird nicht unterstützt. Wenn Sie dies tun, kann MySQL erst dann wieder gestartet werden, wenn Sie die alten Systemtabellen aus einem Backup wiederhergestellt oder mit dem Skript mysql_install_db neu generiert haben.

Eine Tabelle darf nicht mehr als 1000 Spalten haben.

Die interne maximale Schlüssellänge beträgt 3500 Bytes, aber MySQL selbst schränkt dies auf 1024 Bytes ein.

Die maximale Zeilenlänge beträgt (außer bei VARCHAR-, BLOB- und TEXT-Spalten) etwas weniger als die Hälfte einer Datenbankseite, also rund 8000 Bytes. LONGBLOB- und LONGTEXT-Spalten müssen kleiner als 4GB und die maximale Länge einer Zeile (auch bei BLOB- und TEXT-Spalten) muss kleiner als 4GB sein. InnoDB speichert die ersten 768 Bytes einer VARCHAR-, BLOB- oder TEXT-Spalte in der Zeile und den Rest in separaten Seiten.

Obwohl InnoDB intern auch Zeilen von mehr als 65535 unterstützt, können Sie keine Zeile definieren, die VARCHAR-Spalten mit einer kombinierten Größe von mehr als 65535 enthält:

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

Auf manchen älteren Betriebssystemen müssen Dateien kleiner als 2GB sein. Das ist zwar keine InnoDB-spezifische Beschränkung, aber wenn Sie einen großen Tablespace benötigen, müssen Sie diesen so konfigurieren, dass er mehrere kleine statt einer großen Datendatei enthält.

Die kombinierte Größe aller InnoDB-Logdateien muss unter 4GB liegen.

Die Mindestgröße eines Tablespace beträgt 10MB und seine Höchstgröße vier Milliarden Datenbankseiten (64TB). Dies ist auch die Maximalgröße für eine Tabelle.

InnoDB-Tabellen unterstützen keine FULLTEXT-Indizes.

ANALYZE TABLE ermittelt die Indexkardinalität (anhand der Cardinality-Spalte der Ausgabe von SHOW INDEX), indem er acht Zufallssprünge in jeden der Indexbäume unternimmt und die Schätzungen der Indexkardinalität entsprechend aktualisiert. Da dies nur Schätzungen sind, können unterschiedliche Ausführungen von ANALYZE TABLE unterschiedliche Zahlen ergeben. Dadurch läuft ANALYZE TABLE auf InnoDB-Tabellen zwar schnell, aber nicht zu 100% präzise, da es nicht alle Zeilen berücksichtigt.

MySQL verwendet die Indexkardinalitäts-Schätzungen nur in der Optimierung von Joins. Ist ein Join nicht richtig optimiert, können Sie es mit ANALYZE TABLE versuchen. In den seltenen Fällen, da ANALYZE TABLE für Ihre Tabellen keine ausreichend guten Werte produziert, können Sie Ihre Anfragen mit FORCE INDEX ausführen und ihnen damit einen bestimmten Index aufzwingen, oder die Systemvariable max_seeks_for_key setzen, damit MySQL eher im Index nachschaut, als Tabellen zu scannen. Siehe Abschnitt 5.2.2, „Server-Systemvariablen“ und Abschnitt A.6, „Probleme im Zusammenhang mit dem Optimierer“.

SHOW TABLE STATUS zeigt keine präzisen Statistikdaten über InnoDB-Tabellen an, wenn man von der physikalischen Größe absieht, die für sie reserviert ist. Die Zeilenzahl ist nur eine grobe Schätzung, die für die SQL-Optimierung genutzt wird.

InnoDB pflegt keinen internen Zähler für die Anzahl der Zeilen in einer Tabelle. (In der Praxis wäre das wegen der Multiversionierung auch etwas kompliziert.) Um eine SELECT COUNT(*) FROM t-Anweisung zu verarbeiten, muss InnoDB einen Index der Tabelle scannen. Das braucht Zeit, wenn der Index nicht komplett im Bufferpool liegt. Um schneller eine Zahl zu erhalten, müssen Sie selbst eine Zählertabelle erstellen und dafür sorgen, dass Ihre Anwendung sie bei Einfügungen und Löschungen aktualisiert. Wenn sich Ihre Tabelle nicht oft ändert, ist der MySQL-Anfragecache eine gute Lösung. SHOW TABLE STATUS kann ebenfalls eingesetzt werden, wenn Ihnen ein Näherungswert genügt. Siehe Abschnitt 14.2.11, „Tipps zur Leistungssteigerung“.

Auf Windows speichert InnoDB Datenbank- und Tabellennamen intern immer in Kleinbuchstaben. Um Datenbanken im Binärformat von Unix auf Windows oder umgekehrt zu übertragen, sollten Sie immer explizit klein geschriebene Namen für Datenbanken und Tabellen verwenden.

Für eine AUTO_INCREMENT-Spalte müssen Sie immer einen Index für die Tabelle definieren, der nur diese AUTO_INCREMENT-Spalte enthält. In MyISAM-Tabellen kann die AUTO_INCREMENT-Spalte auch Teil eines Mehrspaltenindex sein.

Wenn Sie den MySQL-Server neu starten, kann InnoDB einen alten Wert wiederverwenden, der für eine AUTO_INCREMENT-Spalte zwar angelegt, aber nie gespeichert wurde (also einen Wert, der während einer älteren Transaktion generiert wurde, die zurückgerollt worden ist).

Wenn einer AUTO_INCREMENT-Spalte die Werte ausgehen, bricht InnoDB einen BIGINT auf -9223372036854775808 und BIGINT UNSIGNED auf 1 um. Da jedoch BIGINT-Werte 64 Bits haben, würde es, selbst wenn Sie eine Million Zeilen pro Sekunde einfügten, immer noch fast dreihunderttausend Jahre dauern, bis BIGINT an seine Grenze stößt. Bei allen anderen Integerspalten würde ein Fehler wegen Schlüsselduplikat die Folge sein. MyISAM funktioniert ähnlich, da dies im Wesentlichen dem normalen MySQL-Verhalten und nicht dem einer bestimmten Speicher-Engine entspricht.

DELETE FROM tbl_name generiert die Tabelle nicht neu, sondern löscht eine nach der anderen alle Zeilen.

Unter bestimmten Gegebenheiten wird TRUNCATE tbl_name für eine InnoDB-Tabelle wie DELETE FROM tbl_name behandelt und setzt nicht den AUTO_INCREMENT-Zähler zurück. Siehe Abschnitt 13.2.9, „TRUNCATE“.

In MySQL 5.1, erwirbt die MySQL-Operation LOCK TABLES zwei Sperren auf jeder Tabelle, wenn innodb_table_locks=1 (die Standardeinstellung). Zusätzlich zu einer Tabellensperre auf der MySQL-Ebene, errichtet es auch eine InnoDB-Tabellensperre. Ältere MySQL-Versionen errichteten keine InnoDB-Tabellensperren. Dieses alte Verhalten kann mit innodb_table_locks=0 eingestellt werden. Wenn keine InnoDB-Tabellensperre erworben wird, läuft LOCK TABLES auch dann, wenn einige Datensätze der Tabellen von anderen Transaktionen gesperrt sind.

Alle InnoDB-Sperren, die eine Transaktion hält, werden freigegeben, wenn die Transaktion committet oder abgebrochen wird. Also hat es wenig Sinn LOCK TABLES auf InnoDB-Tabellen im AUTOCOMMIT=1-Modus aufzurufen, da die InnoDB-Tabellensperren sofort freigegeben würden.

Manchmal wäre es nützlich, im Laufe einer Transaktion noch weitere Tabellen zu sperren. Doch leider führt LOCK TABLES in MySQL ein implizites COMMIT und UNLOCK TABLES aus. Es ist eine InnoDB-Variante von LOCK TABLES geplant, die auch inmitten einer Transaktion ausgeführt werden kann.

Die LOAD TABLE FROM MASTER-Anweisung zum Einrichten eines Slaveservers für die Replikation funktioniert noch nicht mit InnoDB-Tabellen. Als Workaround können Sie die Tabelle auf dem Master in MyISAM konvertieren, dann laden und hinterher die Mastertabelle wieder auf InnoDB umstellen. Dies geht jedoch nicht mit Tabellen, die InnoDB-spezifische Features wie etwa Fremdschlüssel verwenden.

Die Standardgröße für Datenbankseiten in InnoDB beträgt 16KB. Indem Sie den Code rekompilieren, können Sie Werte zwischen 8KB und 64KB einstellen. Sie müssen dazu die Werte von UNIV_PAGE_SIZE und UNIV_PAGE_SIZE_SHIFT in der Quelldatei univ.i ändern.

Trigger werden zurzeit noch nicht durch kaskadierende Fremdschlüsselaktionen aktiviert.