昼出かけたついでにごはんでもと思って
最終的に入ったのがマック。
メニューを見てうわー出たー。メガマックの次は
メガてりやきかーと思いつつそれを注文。
予想どおりの味でした。ただでさえ食べづらい
テリヤキがさらに食べづらくなっている。
でも食べごたえあったのでOK。
次は
メガフィレかな。。んーくどそう。
メガタツタこれもきつい。
秋にメガ月見かな。
素敵な？情報がいつもあなたに届くようになります。（itmnewsの記事が届きます。）お役に立つかどうかわかりませんが頑張りますっ。登録してみてください。
ブラウザからユーザー情報を登録できる、CMS形式のサイトにて、ユーザーが１００件近く情報をまとめて登録すると、すぐに情報が反映されずに２時間後くらいにやっと反映されるという不具合の報告がありました。
私も試しにまとめて登録するような動きをトライしたが
どうも現象がみられず。
んーこの遅延はなんだと考え推測で判断するしか
なくなってしまいました。
推測１．MySQL側のロックによる遅延
MyISAMテーブルへの登録なので、ロックレベルは
テーブルロック。まとめてがんがん登録しているときは
ロックがかかり参照するユーザーは遅延する。
この結果、すぐに情報が反映されないのだろう。
だけど、実際遅延によって古い情報を参照することに
なるというのがどうもしっくりこない。ここはタイムアウトになるのではないかとも思われる。ここらへんの挙動は
まだ調査していない。
推測２．クエリーキャッシュ
MySQLにも同様のSQLが頻繁に使われる場合、キャッシュを使用できるが、テーブルが追加、更新、削除などの変化があった場合、キャッシュはクリアされると
http://dev.mysql.com/doc/refman/4.1/ja/query-cache.htmlなっている。
んークリアされるのであれば問題ないなーと思いつつもとりあえず、SQL発行時にキャッシュを使用するか
しないかをコントロールできるので、それで検証できる。
下記はキャッシュを使用しない場合
SELECT SQL_NO_CACHE * FROM TABLE;
素敵な？情報がいつもあなたに届くようになります。（itmnewsの記事が届きます。）お役に立つかどうかわかりませんが頑張りますっ。登録してみてください。
MySQLのテーブルタイプを
InnoDBに変更してみる
ALTER TABLE tables TYPE = INNODB;
phpMyadminの「操作」でも同様のことができます。
「操作」の画面はいろんなことができるんですね。
データが反映されない問題に関しても
テーブルのオーバーヘッドが原因と思われるので
「最適化」をかけてみてもよさそうですね。
phpMyAdminの「操作」でできます。
素敵な？情報がいつもあなたに届くようになります。（itmnewsの記事が届きます。）お役に立つかどうかわかりませんが頑張りますっ。登録してみてください。