November 2007 Archive

MySQLのFulltext Searchは、単語の部分一致検索もできるか？

例えば、"fashion"の、"shio"とか。→ダメなのでは？

MySQL+Sennaでは、どうか。

N-Gramと、辞書利用とで、挙動が変わるか。→N-Gramでは、ひっかかるかも。辞書利用では、ダメなのでは？

where内の指定の順序はオプティマイザに影響を与えるか？
where a > x and b < y;
など。

HASH:

create table hash_table_1(a int primary key, b timestamp) engine=innodb partition by hash(a) partitions 2;

• 完全に均等に配置する
• MOD関数を利用
• INT型、またはINT型を返すファンクションを指定する

LINEAR HASHで利用されるアルゴリズムは、MODでは無くて、"the next power of 2."とな。

KEY:

• 全然均等では無い
• MD5関数/PASSWORD関数もどきを利用
• 指定するカラムのデータ型は何でもOK

→

データを均等に分けたいとき、INT型のカラム、またはINT型を返すファンクションを指定できるときは、HASHでパーティショニングする。

それ以外の時にはKEYでパーティショニングする、という使い分けになる。

ほとんどこちらから引用
http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/

History list length

History list length is number of unpurged transactions in undo space. It is increased as transactions which have done updates are commited and decreased as purge runs.

InnoDBのバージョニングにおいて、過去のバージョンを管理するヒストリーの長さ
InnoDB Buffer Poolにはあるが、未だibdata fileには無いUndo Logの数

lock structs in row lock hash table

Total number of lock structs in row lock hash table is number of row lock structures allocated by all transactions. Note not same as number of locked rows - there are normally many rows for each lock structure.

ロックストラクチャの数
ロックの数ではない

inserts
merged rec
インサートバッファ内に挿入されたデータの数
インサートバッファ内で既に（セカンダリインデックスなどに）反映されているデータの数

hash searches/s
non-hash searches/s
Adaptive Hash Indexが使われた数
Adaptive Hash Indexが使われていない数

log i/o's/second
1秒あたりLog Bufferからib_logfilesへの書き込みが行われた回数

Free buffers
Modified db pages
InnoDB Buffer Poolでまだ利用されていないページ数
InnoDB Buffer Poolでib_dataファイルに反映していないデータの数

Pages read
Pages created
Pages written
InnoDB Buffer Poolの活動状況（ページ単位）

inserts
updates
deletes
reads
実際にどれくらいのデータ/行数が1秒あたりINSERT/UPDATE/DELETE/SELECTされたか。

ほとんどここに解説がある。
http://dev.mysql.com/doc/refman/5.1/ja/server-status-variables.html
http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.html

Handler_read_rnd
MySQL でテーブルの全件スキャンや適切にキーを使えない結合を持ったクエリがある可能性
"データ ファイルで次レコードの読み取り要求を受けた回数。

Handler_read_rnd_next
テーブルに適切なインデックス化できない、またはインデックスを利用できないクエリを発行していることを意味する。
つまりフルテーブルスキャンが発生している。"
ただし、2ずつカウントアップする上に、SHOW GLOBAL STATUS;で2つカウントアップ、SHOW TABLES;で表示されるテーブルの数*1, フルテーブルスキャンなSELECTで行数*2、とあまり見る人のことを考えていない実装になっている。

Qcache_lowmem_prune
Query Cacheの設定値が十分でないためにQuery Cacheから追い出されたクエリの数

Created_tmp_disk_tables
ステートメント実行中に、ディスク上に作成された暗黙的テンポラリテーブルの数。
JOIN, GROUP BY, ORDER BYなどで作成される一時テーブル（MEMORYエンジン）

メモリ上のエリア（tmp_table_size）以上に必要となった場合にディスク上に一時テーブルが作成される。
この値が大きい場合は、tmp_table_sizeを大きくする。

Key_reads
ディスクからのキーブロックの物理的読み込み回数。（MyISAM）
この値が大きい場合は、key_buffer_sizeを大きくする。

Select_full_join
インデックスを使用しない結合の数

Select_range_check
キーなしの結合の数

Sort_merge_passes
ソート アルゴリズムで必要としたマージ パスの回数。
一時テーブルをソートした回数。
この値が大きいときは、sort_buffer_sizeを大きくする必要がある。

ちなみにQuestionsはMySQL Serverに発行されたクエリの総数。
COM_*は発行されたコマンドというか、エンジンレベルで稼動したもの。
Query Cacheが有効に機能している場合は、COM_の総数は、ぜんぜんQuestionsには届かない。

Questions=Qcache_hits+Σ(COM_*)

purge

Purge done for trx's n:o is number of transaction to which purge is done. Innodb can only purge old versions if they there are no running transactions potentially needing them.

明らかこれ以上必要とならないundo情報を、、、ってことは、抹消するってことか。

merge

These are responsible appropriately for insert buffer merges

Insert Bufferの内容をセカンダリインデックスに反映させる。

sync

flush

すぐに思いつく、オンラインバックアップの方法とおおまかな特徴です。
他にも方法があるかも知れません。

ご参考まで。

InnoDBの場合；

１．レプリケーション

別途HWリソースが必要（別サーバ、または同一サーバに構成可能）
リストアはデータファイルのコピーで完了→はやい

２．mysqldumpをsingle-transactionオプションつきで実行

整合性あるバックアップを取得可能
INSERT文を生成させるので、リストアに時間がかかる

３．商用ソフト

http://www.innodb.com/hot-backup/
http://www.zmanda.com/press-release-zrm-mysql.html
http://www.bakbone.co.jp/products/netvault.html
http://www.networld.co.jp/ca/arc_lineup.htm

どれも有償

４．FLUSH TABLES WITH READ LOCKコマンドとLVMなどのスナップショット機能の利用

起動時にInnoDBのオートリカバリが動作する可能性がある→時間がかかるかも

MyISAMの場合；

レプリケーション、myisamhotcopyスクリプトなど

oreilly.co.jp -- Online Catalog: 詳解 MySQL