わーーーーーできました！！！！みなさんありがとうございました！！！！！！！！！！

よかったね

MySQLのロックについて教えてください

環境:5.0.87 (tritonnですが、tritonnに起因する問題ではないです)

2つのInnoDBストレージのテーブルからMyISAMテーブルへINSERTするクエリを発行すると
元のInnoDBテーブルにロックが発生するときがあります。

クエリはこんな感じ
-----
INSERT INTO myisam_table ( field1 , field2)
SELECT i1.A, FN(i2.B)
FROM innodb_table1 i1
INNER JOIN innodb2_table i2 ON i1.id=i2.id
-----
FNはテキストを変更するストアドファンクションです
myisam_tableはインデックス等の設定はありません(のでtritonnの問題ではないです)
innodb_table1,innodb_table2は1対1でパーティションを分けただけです(id列はキー列)

上記のSQLを実行中に、innodb_table1へのINSERTがロック解除待ちになるときがあります。
ダーティーリードOK、ファントムリード大歓迎という一貫性無関係なクエリなので、分離レベルを
READ UNCOMMITTEDにしてもinnodb_table1へのINSERTクエリがロック解除待ちになりました。

FNがちょっと時間のかかる処理なので、10万レコードを処理すると2時間ぐらいかかります。
それでロックが発生していることが分かったのですが、READ UNCOMMITTEDにしているのに
ロックが発生していることがどうしても理解できなく、対策も思いつきません
#そもそも書き込み先はMyISAMなのに何でロックが？という疑問も…

一貫性保持のロックはまだ分かるのですがですが、READ UNCOMMITTEDで一貫性を放棄したのに
それでもロックが発生する理由が分かりません…

>>305
トランザクション分離レベルに関わらず、「更新」は「更新」をブロックする。
そのINSERT … SELECT文は一見「参照」に見えるけど
内部的には「更新」扱いされるんじゃないかなあ。

補足だけどMySQL 5.5を検証環境に入れて、処理中に
information_schema.INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS
あたりを見ると分かるはず。

>306-308
有難う。
指摘された箇所読み直して、ようやく理解した。(ような気がする)

myisam_tableへのINSERTは一貫性関係ないからREAD UNCOMMITTEDと考えてたけど、
innodb_table1/2にはREAD COMMITTED以外だとロックがかかるのね…
質問したinnodb_table1 へのINSERTのロック待ちが起きているクエリのトランザクションの
レベルはデフォルトのRPEATABLE READ。ロック待ちになっても仕方ないですね

「それ以外の場合、InnoDB は S から取得した行に共有ネクストキーロックを設定します」の
「それ=READ CMMITTED」以外というのはREAD UNCOMMITTEDも含むんだろうなぁ

>>313
分けないとだめ
みんな自社用フレームワーク作ったりしてるんだと思う

>>314
レスありがとうございます
という事は、レプリケーションした場合、参照系と更新系を混ぜたトランザクションなんてことは
無理で、トランザクション時のみ更新系DB（マスター）だけを対象に接続することになるんですか？

>>315
YES。
自分でシステムの要件を決められるWeb企業だからできる設計であって、
顧客が要件を決める受託システム開発で採用するのは難しいと思うよ。

>>316
ありがとうございます、勉強になりました

レプリケーションのDBを構築するならば、
MySQL Cluster で構築した方が可用性にも性能にも優れていると思うんだけど、
この認識って合ってますかね？

MySQL Clusterよりもレプリケーションの方が優れている点があれば、教えてください。

>>318
まずこれを読むべき
http://zak.asablo.jp/blog/2009/12/08/4746257
http://zak.asablo.jp/blog/2011/11/24/6212759

AさんとBさんが、全く同じレコードを同時に更新したばあい
どちらかのデータが消えてしまうことになるとおもうのですが、
これを防ぐのにどういう方法が考えられますか？

>>320
「ロストアップデート」でぐぐるといいよ

MySQLDumpで出力する時にwhere なりなんなりで条件で絞ることって出来ましたっけ？

ようやくネクストキーロックを理解しました
言葉では知ってたんだけど、実際に影響を受けたことがなくて、実感がなかった。

ところで、自分以外のスレッドの実行中クエリの分離レベルって、分かるのでしょうか。
SHOW PROCESSLISTで実行中のクエリは確認できるけど、そのクエリがどの分離レベルなのか、ってことです。

自分：SELECT @@tx_isolation;
グローバル設定：SELECT @@global.tx_isolation;
で調べることはできるけど、これでは他のスレッドは分からないです。
#変更していなければGLOBALという予測は出来ますが…
SHOW INNODB STATUSでも分離レベルは表示されないですよね？

>>324
MySQL 5.1＋InnoDB Plugin、またはMySQL 5.5以上が必要。

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G
*************************** 1. row ***************************
trx_id: 3BCB01
trx_state: RUNNING
trx_started: 2012-04-03 00:22:46
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 1
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: READ COMMITTED
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
1 row in set (0.00 sec)

テーブルの中にフィールドがずらーっと登録されてますが
あれのデフォルト表示の順番って変えれるものなんですか？

>>328
テーブル定義を変えればできるけど、一般的にはあまりやらない。
そもそも「SELECT *」をするなというのが定石。

mysql> SELECT * FROM t;
+------+--------+---------+
| i_id | i_name | i_price |
+------+--------+---------+
| 1 | sample | 100 |
+------+--------+---------+

mysql> ALTER TABLE t MODIFY i_name VARCHAR(100) AFTER i_price;
mysql> SELECT * FROM t;
+------+---------+--------+
| i_id | i_price | i_name |
+------+---------+--------+
| 1 | 100 | sample |
+------+---------+--------+

できます

おおおお！本当ですか！
MySQLに乗り換えてみます！
ちなみにそれは何とググったら出てきます？ちょっと色々と調べてみたいんで

全てのテーブル同士で共有するkeyってなんだろう

>325
ありがとうございます。5.0系だと手段はないんですね…
5.0のサポートが終わったのは分かっているのですが、
日本語全文検索の関係でtoritonnから離れられなくて…

後継？のぐるんがってどうなんでしょうか？
予算でがっつり削られたので、検証すら困難になってしまいました…
去年(ベータ版のころ)の検証時は性能不足で却下だったのですが、
リリースの度、機能と安定度は増したので期待しているのですが…

生徒の出席テーブルを作りたいのですが
生徒IDと日付をテーブルにして、一日１回レコードに追加したいです。
すでに存在していたら追加したくないのですが

create table hoge(
seito int(11),
hiduke datetime
);

みたいなテーブルで
INSERT IGNORE hoge (seito, hiduke) VALUES($seitoid, DATE_FORMAT(CURDATE(),'%Y-%m-%d'));
としたいのですが
seito とhidukeの両方が一致した場合はINSERTしないようにするには、どのようなテーブルにしたらよいでしょうか

>>341
とりあえずはそれでいい
応用はあとで痛い目見てからでいい

>>343
元からあるテーブルをDROPして、それからインポートすれば
うまく出来ると思います

>>344
いや、ですからドロップ済みにして、まっさらな状態でインポートしたら
いけるんですが、それだとリモートにたまったデータが
全部消えてしまうでしょ？

フィールドを増やすなどテーブルをいじる時は、まずリモートからいじって
それからローカルに移す（ローカルならまだ全部消しても問題ない）
しかないですかね。