MySQLの書き順による、カラムの処理順序

MySQL系で以下の update文を実行して驚いた！

table xxxxx

pkey	col1	col2
1	aaaaa	ccccc

上記のようなテーブルにデータがある場合に以下のSQLを実行すると

update xxxxx set
col2 = col1
,col1 = 'bbbbb'
where
pkey = 1
;

以下のように更新される

pkey	col1	col2
1	bbbbb	aaaaa

ところが、SQL文を以下のように書き換えると

update xxxxx set
col1 = 'bbbbb'
,col2 = col1
where
pkey = 1
;

結果がこうなる。

pkey	col1	col2
1	bbbbb	bbbbb

えええええええ、そうなの？？？？

pkey	col1	col2
1	bbbbb	aaaaa

じゃないの？？？

PostgreSQLだと、同一クエリー内で書き順は関係なく

並列に処理されましたが、MySQLの場合はそうではないんですね。

書いた順番のカラムごとに処理をしていくから、

下位の処理は上位の処理の影響をもろに受ける。

処理は並列ではなく直列でした。

知らなかった。。。。

今まで書いてたSQL文に一抹の不安を覚えた。

さくらインターネットで、MySQLを使うときに気をつけたいこと

スタンダードプランだとInnoDBストレージがが使えない。

これにはちょっと驚いたけど、FAQに書いてありました。

http://faq.sakura.ad.jp/faq/1032/app/servlet/qadoc?000526

MyISAMだとテーブルロックなので、更新と参照のバランスよっては

問題になる可能性がありますね。

あらかじめ設計時に気をつけたいポイントです。

MySQL パフォーマンス

my.cnf

skip-name-resolve

接続元のＩＰアドレスから逆引きの名前解決をＯＦＦにする。

アプリケーションからＭｙＳＱＬに接続する際に

接続プールをしていない場合は、結構な効果があるとおもう。

レプリケーションのスレーブオプション

特定のテーブルのみレプリケーションしたい場合の設定は、

my.cnf に記述してmysqlを再起動する

[mysqld]

replicate-do-table=dbname.tablename1
replicate-do-table=dbname.tablename2
replicate-do-table=dbname.tablename3

複数指定する場合は、そのテーブル数だけ記述すればよい。

再起動後、show slave status; で、上記の設定が表示されていればOK

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 931
Relay_Log_File: slave1-relay-bin.000056
Relay_Log_Pos: 950
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table: dbname.tablename1,dbname.tablename2,dbname.tablename3
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 931
Relay_Log_Space: 1365
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.01 sec)

Senna クエリー

全文検索 FullText MySQL + Senna ＝ Tritton　を利用したときのメモ

http://qwik.jp/tritonn/

SQLのレシピが少ないので、自分で試したものを記述する。

条件を複数指定する場合は、*X*Y*Z とくっつけて記述すればよいことは

どこにも書いてなかった（見つけれませんでした。）が

試してみたらOKだったのでメモっておく。

キーワード「ほげほげ」を

検索カラム a の中から 完全一致 で見つける場合

select
*
from
table_name
where
match(a,b,c) against('*W1*E-1 ほげほげ' IN BOOLEAN MODE)

//  *W1  検索カラム a
//  *E-1 完全一致

Senna のクエリーの詳細は、http://qwik.jp/senna/query.html

レプリケーション時のエラースキップ

MySQLのレプリケーションで、稼動中のマスターDBからスレーブDBに

データをコピーし、レプリケーションを開始したところ

ところどころで、error 1060 プライマリーキーの重複などのエラーがでました。

最初は、

SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE SQL_THREAD;

として、処理を再開していましたが、大量に出てきてこりゃ手に負えないわということで

my.cnf に以下を追記し再起動

[mysqld]
slave-skip-errors=1060

一応、今のところ問題なくレプリケーションしてます。

そもそも、稼動中のMySQLのレプリケーションのやり方を詳しく説明しているのを見つけることができず

とりあえずで、以下の手順でスレーブを作りました。

（１）マスターをコピーして、スレーブに移動

（２）マスターのバイナリーログをながめてレプリケーション開始のポジションを決める。

（３）スレーブの設定に slave-skip-errors をセットして問題ないエラーを回避する

マスターをシャットダウン（テーブルロック）できたら、こんなことにはならなかったと思うのですが

まぁ、止めたくなかったのでコピーを稼動中にするはめに。

更新処理がどんどん進めば、スレーブのデータのずれも

上書きされて、まぁ問題ないかと。

スレーブは基本参照用に使うつもりなので

致命的なデータのずれさえなければ、そんなに整合性にはこだわらなくても

いいのかとおもいます。マスターとの同期に時間的なずれがそもそもあるしね。