Dies kann sehr stark von der Speicher-Engine abhängen.
Für MyISAM wäre dies eine großartige Idee, da Sie Daten so zusammenhängend machen können, wie Sie möchten. Dies würde Abfragen mit Massenvorgängen und Scans mit großer Reichweite zugute kommen. Das Toolset zum Komprimieren und Reparieren von MyISAM zur Verbesserung des Tabellenformats kann den Zugriff ebenfalls etwas verbessern. IMHO gleichzeitige INSERTs könnten in einer solchen Festplattenumgebung gedeihen.
InnoDB ist eine ganz andere Geschichte.
Wenn Sie innodb_file_per_table deaktiviert haben, können Daten über ibdata1 verteilt und somit auf mehrere Datenträger verteilt werden. Sie könnten OPTIMIZE TABLE für eine InnoDB-Tabelle ausführen und die Daten- und Indexseiten zusammenhängend machen, dies könnte jedoch zwei Probleme verursachen:
- Lässt die ibdata1 wachsen
- Verschlechtern Sie die Leistung im Laufe der Zeit
Vergessen Sie nicht die vier Datentypen in ibdata1:
- Tabelle MetaData
- Tabellendatenseiten
- Indexdatenseiten
- MVCC- Daten
MVCC-Daten werden ständig geschrieben, um die Datenintegrität zu schützen. Es gibt auch eine ständige Interaktion mit ib_logfile0 und ib_logfile1 (Redo-Logs). Alle 10 Sekunden werden ständig Daten aus dem InnoDB-Pufferpool zurück in den gelöscht. Insgesamt kann man mit Sicherheit sagen, dass die Verteilung von Daten auf mehrere Festplatten und die E / A-Leistung eine geringfügige bis bescheidene Leistungsverbesserung zeigen können, bis innerhalb von ibdata1 eine ausreichende Fragmentierung vorliegt.
Wenn nun innodb_file_per_table aktiviert ist, können die Dinge etwas chaotischer sein. Hier ist warum:
Sobald Sie ibdata1 bereinigt und alle InnoDB-Tabellen von ibdata1 getrennt haben , haben Sie ein kleineres ibdata1. Jeder Zugriff auf eine InnoDB-Tabelle erfordert jedoch die ständige Navigation über ibdata1 über Tabellenmetadaten. Sie können die Tabellenmetadaten (ibdata1) buchstäblich nicht semantisch von der Tabelle (.ibd) trennen. Wo immer ibdata1 lebt, müssen Festplatten-E / A immer ibdata1 durchlaufen.
Gesamteffekt: Die Tabellenfragmentierung ist auf .ibd-Dateien beschränkt und kann mit OPTIMIZE TABLE reduziert und neu organisiert werden. Es wird jedoch keine zusätzliche Verbesserung der E / A-Leistung erzielt.
Was ist mit dem Speichern aller .ibd-Dateien auf einem anderen Satz von Datenträgern außer ibdata1 und der Verwendung von Symlinks? Laut Percona schafft das mehr Chaos .
FAZIT
Wenn es darum geht, mehrere Laufwerke über ein einziges Laufwerk zu verwenden, bevorzuge ich MyISAM gegenüber InnoDB.
