MySQLテーブル/データベースを別のディスクに
多くのテーブル/データベースを備えた単一のデータベースサーバーが存在する可能性があることは承知しており、それらのテーブル/データベースのいくつかを別々のディスクに分離できます。 5つのテーブル/データベースと5つのドライブがあるとします。したがって、別のドライブの各テーブル/データベースをアタッチします。したがって、IOおよびその他すべてが増加します。
そのテクニックは何と呼ばれていますか？
データベースを分離しようとすると、異なるドライブを異なるデータベースの異なるフォルダにマウントするだけだと思いますが、テーブルを別々のドライブに分割したい場合（各テーブルが異なるディスクにある場合）
MyISAMの観点では、 .MYDが1つのディスクに存在し、.MYIファイルは別のファイルに存在します 。これにより、任意のMyISAMテーブルのデータおよびインデックスページにアクセスするディスクの待ち時間を短縮できます。ただし、カバリングインデックスを慎重に使用するだけで、この効果の少なくとも90％を達成できます。
InnoDBに関しては、まったく別の話です。どうして？
Ibdata1内のテーブルメタデータとInnoDBデータおよびインデックスページ間の相互作用を分離することは不可能です。 以前の投稿でこれを指摘しました。さらに、私はPerconaが.ibdファイルを個別のディスク にプッシュしないことを推奨していると述べました。
StanleyJohns は、MyISAMにとって論理的に最も意味のあるMySQLパーティショニングを推奨しました。 atxdba は、OSでのMyISAMのデータの使用とインデックスの分離をサポートする方法について説明しています。 InnoDBにはその機能がありますが、InnoDBのパーティショニングを考えすぎないでください。メンテナンスを行うとなると、それ以上に面倒です。
あなたが探しているテクニックは、パーティショニングと呼ばれていると思います。 MySQLパーティショニングはこちら の詳細を読むことができます。
このプラクティスの具体的な用語はわかりませんが、 create table syntax を使用して、さまざまなデータやインデックスディレクトリを指定できます。
これはMyISAMテーブルでのみ機能し、OSはシンボリックリンクをサポートする必要があります。
ただし、私の慣例では、通常、データベースをセグメント化して独自のLVに分割します。これらは通常、機能アプリケーションごとのセグメントです。すべてのテーブルが実際に存在する単一の論理ボリュームがあると、各DBの管理ディスク領域を追跡しやすくなります。
ただし、これらのLVは通常、IOのバランスをとるためにRAID 10構成になっています。