INNODBのデータファイルは,後から追加することが可能。その場合には,innodb_data_file_pathの最後に
追加すれば可能です。また,最後が自動拡張(autoextend)の場合には,自動拡張(autoextend)指定と
なっているデータファイルの容量を初期値+8MB倍数で近い値に指定すれば容量固定のデータファイルと
して運用でき,その後に新たなデータファイルを追加できる。
運用開始後に削除やサイズの変更はできない。その場合には,InnoDBの再構築が必要となる。

innodb_grep

innodb_log_files_in_group=2の設定を変更して、innodb_log_files_in_group = 3に設定変更してみました。

————————————————————————————
[root@colinux DB01]# grep -v ^# /etc/my.cnf | grep innodb
innodb_data_home_dir = /usr/local/mysql/data/
innodb_data_file_path = ibdata1:10M;ibdata2:30M:autoextend:max:60M
innodb_file_per_table
innodb_log_group_home_dir = /usr/local/mysql/data/
innodb_log_file_size = 8M
innodb_buffer_pool_size = 16M
innodb_log_buffer_size = 32M
innodb_log_files_in_group = 3
[root@colinux DB01]# l
————————————————————————————

innodb_grep_option

ログのオプション追加後

[root@colinux DB01]# ls -l /usr/local/mysql/data/ib*
-rw-rw—- 1 mysql mysql 8388608 2009-07-20 23:31 /usr/local/mysql/data/ib_logfile0
-rw-rw—- 1 mysql mysql 8388608 2009-03-18 00:55 /usr/local/mysql/data/ib_logfile1
-rw-rw—- 1 mysql mysql 0 2009-07-20 23:31 /usr/local/mysql/data/ib_logfile2
-rwxrwxrwx 1 root mysql 10485760 2009-07-20 23:31 /usr/local/mysql/data/ibdata1
-rw-rw—- 1 mysql mysql 31457280 2009-07-20 23:31 /usr/local/mysql/data/ibdata2
[root@colinux DB01]#

logtuika

既にトランザクションログが存在していて,innodb_log_file_sizeの設定値の方が大きい場合,
サイズアンマッチでInnoDBが起動しないので注意が必要だ。
トランザクションログは,サイズを大きくすることによって,ローテーション(チェックポイント)の発生回数
を減らすことが可能だ。トランザクションログのデフォルトは,10MBが2個であるから,
大量のデータ更新を行う場合などは拡大することを薦める。

以前社内で運用していたオラクルのREDO LOGは、1024Mを3つ程作成して利用していました。
ここら辺はパフォーマンスやデータ保護の観点で考えれば良いかと思います。

MySQL は .frm ファイル内のテーブルのデータ ディレクトリ情報をデータベース ディレクトリに格納します。
これは全ての MySQL ストレージ エンジンに言える事です。しかし全ての InnoDB テーブルも
テーブルスペースの内側にある InnoDB 内部データ ディレクトリ内にそれ自体のエントリ
を持っています。MySQL がテーブルやデータベースをドロップする時、それは .frm ファイルと InnoDB データ
ディレクトリ内の対応するエントリの両方を削除する必要があります。
これが、単に .frm ファイルを移動するだけで InnoDB テーブルをデータベース間で移動する事が
できない理由です。

InnoDBのクラスタードインデックスの値としては、プライマリキーが使用されるため、プライマリキーの
値順にレコードが並んだ構成のテーブルとなります。プライマリキーが定義されていないテーブルの場合は、
InnoDBが自動的に6バイトのローIDと呼ぶフィールドをレコードに追加し、このローID を用いて
クラスタードインデックスを構成します。

全ての InnoDB テーブルは、行のデータが格納されている clustered index と呼ばれる特別な
インデックスを持っています。もし PRIMARY KEY をテーブル上で定義したら、主キーのインデックスは
集合インデックスになります。

InnoDB では、非集合インデックス(セカンダリ インデックスとも呼ばれる)内のレコードは、
行に対して主キー値も含んでいます
InnoDB は、この主キー値を集合インデックスから行を検索するのに利用します。
もし主キーが長いと、セカンダリ インデックスがより多くの領域を利用する事に注意しなければならない。

————————————————————
InnoDBのトランザクション機能
————————————————————
※ 読み込み一貫性機能を持つ
※ ロック単位はレコード単位で、ロックのエスカレーションがない
※トランザクションの分離レベルは4つ持つ
━ リードアンコミッティド
━ リードコミッティド
━ リピータブルリード
━ シリアライザブル

InnoDBの読み込み一貫性機能の仕組みは、変更前データをロールバックセグメントに格納することに
よって実現しています。このロールバックセグメント(RBS)は、テーブルスペース内に格納されます。

ロックエスカレーションが発生しない理由は、少ないリソースを個々のロックを実現しているため。
※ 実際には5.0.13以前では、ロックエスカレーションが起こるようです。

InnoDB は、短い方の文字列の残りの長さが領域で詰められたかのように扱われるように、
長さの異なる CHAR と VARCHAR 文字列を比較します

InnoDB テーブルの物理的なレコード構造は、テーブルが作成された時に指定された行フォーマットによって
決まります。MySQL 5.1 ではデフォルトで InnoDB が

    COMPACT フォーマット

を利用しますが、
MySQL の古いバージョンとの

    互換性を保持する為にはREDUNDANT

フォーマットが有効です。

    参考サイト

13.5.13. InnoDB テーブルとインデックス構造

13.5.13.4. 物理的なレコード構造

Comments are closed.

Post Navigation