mysql innodbデータファイルは、ディスクスライス（固定サイズ）に直接ファイルですか？

Question

IBDATA1はディスクスライスのようなものです。 Solaris（UNIX）UFSファイルシステム（ZFSの前の一般的なもの）では、ディスクC0T0D0をスライスに分離し、10GBドライブが3つのセクション、4GB、1GB、5GBにカットされます。これらは固定サイズのファイルシステムになります。たとえば、OSの4GB。スワップ用の1GB、ソフトウェアとデータ用の5GB。

スワップはファイルシステム上のファイルに保存できますが、パフォーマンスのために、通常はディスクの独自のセクションに保存されます。

IBDATA1は、パフォーマンスを向上させるために独自のスライスにリンクできますか？もちろん、どの固定サイズが理想的であるかを決定する前に慎重に考える必要があり、使用方法を確認する方法も知る必要があります。

シンボリックリンクはから配置できます .../mysql/data/ibdata1 に /dev/rdsk/c0t0d0s3. 。 MySQLはファイルと見なされますが、ファイルシステムレイヤーを通過する必要がないため、パフォーマンスが向上し、ディスクの指定されたセクションに直接書き込みます。

• 誰かがこれを試しましたか？
• 誰かがこれが悪い考えだと思いますか？ （このアイデアは、INNODBのみのデータベースのみのサーバー向けです。多目的サーバーではありません。）
• それは機能しますか（InnoDBはファイルの長さを確認する必要がありますか？そうでない場合は、機能するはずです。）
• 使用法をチェックできますか？

Answer 1

まず、IBDATA1に存在するエントリタイプは何ですか？ 4つのエントリタイプ：

• テーブルメタデータ
• テーブルデータページ
• インデックスデータページ
• MVCC データ

INNODBテーブルがDDL、DML、またはトランザクションで使用されているときはいつでも、これらの4つのタイプのエントリはすべて読み取られるか書かれています。その間、場合 innodb_file_per_table これらのすべてのエントリタイプはIBDATA1に住んでいます。有効になっている場合、テーブルメタデータとMVCCデータのみがIBDATA1に存在し、テーブルデータページとインデックスデータページはデータベースサブフォルダーに.IBDファイルとして存在します。

それを考慮して、IBDATA1が別のボリュームに配置され、シンラムリンクされた場合はどうなりますか？

手始めに、MySQLはストレージエンジンに関係なくテーブルをどのように表していますか？ .frmファイルとして。 .frmファイルはどこにありますか？ Datadirで。それのどこが悪いんだい ？

これが例です：

/var/lib/mysqlのデフォルトのDatadirを使用して、mydb.mytableと呼ばれるInnodbテーブルを使用しましょう。

innodb_file_per_tableが無効になっている場合、すべてがIBDATA1（シンリンクして別のデータボリュームに送信することを提案しています）に座ります。テーブルmydb.mytableの場合、これはあなたが持っているものです：

• /var/lib/mysql/mydb/mytable.frm
• テーブルに関する他のすべてがIBDATA1に住んでいます

これを想像してみてください：テーブルにアクセスしてください。MySQLは最初に/var/lib/mysql/mydb/mytable.frmにヒットし、mydb.mytableのIBDATA1のデータとインデックスページをヒットします。これは、mydb.mytableのすべてのアクセスで常に発生します。このカスケードは何らかの形で物事を少し遅くし、IBDATA1を他のデータボリュームに移動することで期待していたパフォーマンスを得ることができないかもしれません。実際、カスケード効果は、INNODBテーブルの数に2つを掛けた要因になります。

innodb_file_per_tableを有効にすることを想像してください。これで、少し異なるセットアップがあります。

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd
• MVCCデータとテーブルメタデータはIBDATA1に存在します

このカスケードは、テーブルアクセスのカスケードが2つではなく3つのファイル間で発生するため、少し悪いでしょう。

いくつかの考えが考えているもう1つのシナリオは次のとおりです。IBDATA1を別のボリュームに移動する代わりに、INNODB_FILE_PER_TABLEを有効にし、.ibdファイルを1つ以上の異なるデータボリュームに移動するのはどうですか？カスケード効果は、INNODBテーブルの数に3を掛けた要因になります。 Perconaは、これを行わないという非常に良い理由を表明しました。.