アーカイブ

‘mysql’ カテゴリーのアーカイブ

Q4Mインストールしてみた

2009 年 12 月 18 日 コメントはありません

ウノウラボ Unoh Labs: Q4Mを触ってみる
ずっと気になってるのでとりあえずインストールだけしておけば使うだろうってことで。

MySQLはremiリポジトリのものを利用してます。
CentOS5.3でPHP5.2を使う
バージョンは5.1.41の最新でした。
mysqlbugコマンドで–with-fast-mutexesオプションの有無を確認しましたが、有効になっていませんでした。


# wget http://q4m.31tools.com/dist/mysql-5.1.41-linux-x86_64-glibc23-without-fast-mutexes-q4m-0.8.9.tar.gz
# tar zxf mysql-5.1.41-linux-x86_64-glibc23-without-fast-mutexes-q4m-0.8.9.tar.gz
# cd q4m-0.8.9-linux-x86_64/
# cp libqueue_engine.so /usr/lib64/mysql/plugin
# mysql_upgrade
# install -m 755 support-files/q4m-forward /usr/bin
# cat support-files/install.sql | mysql -uroot

# DBI='dbi:mysql:database=test;host=localhost;port=3307'
./run_tests.pl
t/01-base-rnd_pos.........................ok
t/01-base.................................ok
t/02-queue-cond...........................ok
t/02-queue-owned-delete...................ok
t/02-queue................................ok
t/03-queue-error-wait.....................ok
t/03-queue-error..........................ok
t/04-blob-cond............................ok
t/04-blob.................................ok
t/05-multireader..........................

Multireader benchmark result:
    Number of messages: 6400
    Number of readers:  32
    Elapsed:            1.184 seconds
    Throughput:         5406.566 mess./sec.

t/05-multireader..........................ok
t/05-multirw..............................ok 1/4

Multi-reader-writer benchmark result:
    Number of messages: 6400
    Number of readers:  32
    Elapsed:            1.718 seconds
    Throughput:         3726.283 mess./sec.

t/05-multirw..............................ok
t/05-multiwait............................ok 1/4

Multi-reader-writer benchmark result under semi-starvation:
    Number of messages: 6400
    Number of readers:  32
    Elapsed:            2.235 seconds
    Throughput:         2863.895 mess./sec.

t/05-multiwait............................ok
t/06-multi................................ok
t/07-trans................................ok
t/08-forward..............................ok
t/09-pqueue-single-table-wake-listener....ok
t/09-pqueue-single-table..................ok
t/10-largedata............................skipped
        all skipped: set BIG_TESTS=1 to run theese tests
All tests successful, 1 test skipped.
Files=18, Tests=68921, 222 wallclock secs (125.61 cusr + 12.97 csys = 138.58 CPU)
カテゴリー: mysql タグ: ,

PHPとMySQLの個人的まとめ

2006 年 3 月 17 日 コメントはありません

MySQLではまったこと
MySQLの文字化け
今さら何いってんのコイツとかそこ言わない。

文字コードを確認するSQL文「SHOW VARIABLES LIKE ‘char%’;」

MySQL4.1以降はサーバとは別にクライアントの文字コードが設定されている。
クライアント、サーバ間で違う文字コードがセットされていると、一度ucs2変換を通る。
よって、クライアント、サーバ間で違う文字コードを指定することとなり文字化けが起こる可能性がある。

PHPはmy.cnfで[mysql]、[client]を設定しようがクライアントの文字コードはビルド時に指定されたキャラクタセット(通常latin1)。

my.cnfの設定


[mysql]
default-character-set = utf8
[mysqld]
default-character-set = utf8

mysqlクライアントからチェックすると問題なさげだが…


mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |

PHPで接続すると実際は…


| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | utf8                       |
| character_set_results    | latin1                     |
| character_set_server     | utf8                       |

latin1は1byte文字しか利用できない為に文字化けが起こる。
「character_set_server」をデフォルトのlatin1で利用していた場合は、クライアント、サーバ間で変換が行われないためPHPで利用する分には文字化けは起こらない。
だがDBには破壊された文字が保存されるので、これはすべきではない。

PHPのクライアント文字コードセットを変更するにはビルドし直すか、「SET NAMES 文字コードセット」をクエリする。
「SET NAMES 文字コードセット」は「character_set_client」「character_set_connection」「character_set_results」の文字コードをセットする。


mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | utf8                       |
| character_set_results    | latin1                     |
| character_set_server     | utf8                       |
mysql> SET NAMES ujis;
mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | ujis                       |
| character_set_connection | ujis                       |
| character_set_database   | utf8                       |
| character_set_results    | ujis                       |
| character_set_server     | utf8                       |

MySQLの4.1.15以降、5.0.13以降で「skip-character-set-client-handshake」というオプションが追加された。
クライアントからリクエストがあった場合、クライアントの文字コードをサーバの文字コードと同じものをセットする。


[mysql]
default-character-set = binary
[mysqld]
default-character-set = utf8
skip-character-set-client-handshake

mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |

ただし、「skip-character-set-client-handshake」は「character_set_server」の値を参照するので注意。


mysql> CREATE DATABASE sample CHARACTER SET ujis;
mysql> USE sample;
mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | ujis                       |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |

mysqldumpについて。
mysqldumpはデフォルトでutf8の文字コードがセットされている。


[mysql]
default-character-set = sjis
[mysqld]
default-character-set = utf8
[mysqldump]
default-character-set = binary

文字セットに「binary」をセットすると「character_set_database」を無変換で出力してくれる。


C:\>mysql -u root sample;
mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | sjis                       |
| character_set_connection | sjis                       |
| character_set_database   | ujis                       |
| character_set_results    | sjis                       |
| character_set_server     | utf8                       |
mysql> \q
C:\>mysqldump -u root sample > dump.sql

上記の場合は出力ファイルの文字コードはEUC-JP。


[mysql]
default-character-set = sjis
[mysqld]
default-character-set = utf8
skip-character-set-client-handshake
[mysqldump]
default-character-set = binary

「skip-character-set-client-handshake」をセットすると…


C:\>mysql -u root sample;
mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | ujis                       |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
mysql> \q
C:\>mysqldump -u root sample > dump.sql

mysqldumpもクライアントなので変換され、dump.sqlはUTF-8の文字コードとなる。

カテゴリー: mysql タグ:

MySQLではまったこと

2006 年 3 月 7 日 コメントはありません

MySQL4.0はサーバがキャラクタセットをもっており、クライアントはサーバのキャラクタセットで動作していた。
4.1、5.0はクライアントとサーバで別々にキャラクタセットを持っており、変換が行われる。
クライアントとサーバで相互変換できないキャラクタセットの場合、データが壊れる(文字化け)が起こる。

ここまでは別に問題なかった。

PHPはデフォルトでキャラクタセットlatin1を利用するようになっている。
なので配布されているバイナリのほとんどはキャラクタセットlatin1。

ここまでも問題なし。

my.cnf(Windowsバイナリだとmy.ini)の設定項目でキャラクタセットに関係あるもの。

mysql> SHOW VARIABLES LIKE 'char%';
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |

[mysqld] — mysqlサーバの設定。
「character-set-server」「default-character-set」とキャラクタセットを2つ設定しているのをみるが、両方書いてもどちらか一方でも動作はかわらず。
「default-character-set」でサーバのキャラクタセットがすべて初期化されるけど、その対象が「character-set-server」という話ぽい。
5.0.13rc以降なら「skip-character-set-client-handshake」を設定することにより、4.0以前と同様の文字変換を行わない設定にできる。
[mysql] — mysqlクライアントの設定。
コマンドラインmysqlの設定。
「default-character-set」で設定したキャラクタセットが「character_set_client」「character_set_connection」「character_set_results」に反映される。
PHPで利用する場合はここに何設定しようが反映されない。
[mysqldump] — mysqldumpの設定。
何も設定しない場合、デフォルトでutf8と設定されている。
無変換で出力したい場合はキャラクタセットbinaryを指定する。

ここで、罠に引っかかる。
my.cnfに「init-connect=SET NAMES 文字コード」を設定すればサーバに接続したクライアントのキャラクタセットを初期化できる…という情報がたくさんあったんだけど、PHPからMySQLへ接続し「SHOW VARIABLES LIKE ‘char%’;」をクエリして結果みてみたら、「SET NAMES 文字コード」反映されてねぇぇぇぇ!
盲目に信じてた自分がバカだったんですが。
ちなみPHP5.1.2とPHP5.0.4。
[追記] init-connectはSUPER権限のユーザだと反映されないらしい?
「SET NAMES キャラクタセット」をクエリすると「character_set_client」「character_set_connection」「character_set_results」の値を変更できる。

あと、もうひとつはまったこと。
「SHOW VARIABLES LIKE ‘char%’;」クエリした結果の「character_set_server」。
DBを作成する場合のデフォルトのキャラクタセットの意味しかないとずっと思ってたんだけど、設定変えたら全体の動作変わった。
CREATE DATABESEでDB作る時にキャラクタセット指定しないと「character_set_database」が「character_set_server」の値になるんだけど、これが参照になってるので既存のDBのキャラクタセットすべて書き変わる。
稼働中のシステムの変更する場合は、まったく同じ環境つくってから設定変えていくって形とらないと。
同じ環境を作成するの厳しかったので、別環境を1から構築して、そこでいろいろ設定して試してたんですが、元のmy.cnfの設定をチェックしてなかったよフフフ。

PHPとMySQL4.1(〜5.0.12)のセットで利用する場、phpスクリプトに手を加えたくない場合はlibmysqlをコンパイルし直すかなさげ。
my.cnfはPHP5を利用するならphp_mysqliでなら読めるように設定できるらしい。
すべてlatin1で統一してある場合は、一見問題なく動作してるようにみえるが、マルチバイト文字がシングルバイト文字(実際は文字とは言えない何か)×Nと処理されるため、varchar(60)が文字数ではなくバイト数と同じような処理をしてしまう。
phpMyAdmin使えないし。

カテゴリー: mysql タグ: