「ひとつのレコードとして」
「一見正常に動作しているように見えて」
「結果が正常に表示されます」
説明が具体的でないから、何をどうして何が起きたのかさっぱりわからん。

698は包茎なんだよ。許してやれよ。

>>698の作り込んだバグだよ。
一見うまくいっているように見えるのは
INSERTしたときの情報を表示しているからだ。

VMwareを入れてCentOSを入れて
その中にmMeasureを入れて、
WindowsのMySQLを監視するというのができそう

>>706
そう来たか…

っていうかムリだと思います。
出来てもやりたくありません。

中学生の君か
子犬を飼うのがいいと思うんだけどな
結果的にvmware入れるのと変わらないが

cygwinならきっとやってくれる

MySQLがオラクル社のものに・・・
ってところは意外と話題にならないんだな
日本人は寛容だねえ

何を今更・・・

近年稀にみる情弱

まだまだこれから！の話題だけどね
http://www.itmedia.co.jp/enterprise/articles/1004/12/news047.html

色々アドバイスを頂きまして有難うございます。

対策としてinsertしたデータを、MySQLから再度呼び出して確認する機能を
加えて運用していたのですが、同じ問題が出ました。
そして、ある特殊なケースにこの問題が発生することがわかり、>>704さんの
仰るようにバグでした。
MySQLのカラムでINT型を指定しているカラムに文字列をインサートしようと
した時に、レコード全体がインサートされていませんでした。

直接SQL文で、MySQLのINT型を指定してあるカラムに文字列を
インサートした場合には自動的に0が入力されるのですが、
WEB上のPHPからMySQLにインサートした場合にはレコード自体が
インサートされないようです。このことで解明に時間が掛かりました。

このあたりのMySQLの挙動の違いについて調べていますが、あまり出てきません。
参考になるものがありましたらアドバイスをお願い致します。

>>714
データの保証やサニタイズは、
アプリケーションでしっかり実装するべき。

>>715
そうですね。
MySQL mode について調べているのですが、なかなか出てこないのは、
アプリケーションでしっかりやっていれば、モードの違いは
関係ないからなのかも知れませんね。

すみません、超初心者なんですが、質問させてください。

デッドロックが発生した場合って
１．サーバーを再起動する
２．MySQLのkillコマンドでスレッドを潰していく

以外に、復旧する方法ってあるんでしょうか？

MySQLだってデッドロック検出くらいあるだろう。
デッドロックを起こしたトランザクションの一方(あるいは両方)が一定時間後に
ロールバックされる。

INT型のカラムに文字列をつっこんでおいてバグ呼ばわりか・・・

雑なPGとは付き合いたくないな

SQLiteならきっとなんとかしてくれる

テーブルの使い方が悪いのか
デッドロックが発生するとずっとロックがかかったままになって
ロールバックしてる気配がない　orz

>>721
バグ以外になんと呼べばいいんだ

>>725
はぁ？
頭大丈夫か、お前？

>>725
更にこ～ゆ～のが存在するとはね
レベル低いのぉ

>>724
MySQLはデッドロック発生時に自動でロールバックする。
(ちなみにOracleはロールバックしない)

なので、何か勘違いしていると思われます。

>>725
ここはMySQLスレ
intに文字列を突っ込もうと言うバグがあるのは>>698のプログラム
判る？

>>725
DB関連扱うなら、サニタイズとかXSSやSQLインジェクションとかプレースフォルダとかプリペアドステートメントとか
ちゃんと覚えてからやらないと、バグ作り込むことになるよ。

誰も「MySQLのバグ」なんて言ってないのに。
そんな勘違いする奴が一気に大量発生するのは不自然すぎるよ>>721

今のところ「>>704さんの仰るように」が分からん
日本語会話の駄目なのが三匹くらい?

全部同じ人じゃないの
俺にはそう見える

>>728

デッドロックじゃないかもしれないんですが
私が現在調査しているのが

ロックをかけていたセッションがロックを解除しないまま死んで
ロールバックせずにロックが掛かったままになっている・・・・・・
んじゃないかみたいな現象が起きていまして

何かコマンド叩いて、ロックの原因が分からないかだとか
何かコマンド叩いて、簡単に復旧しないかだとかです。

ネットの検索も色々とやっていますが、いまいち今回の内容に合致する
ものがHITしないです。

そりゃ解決しないわ。「デッドロックの質問」に答えた人もずっこけてるんじゃないの？
で、そのロックは本当にかかっているの？どうやって現象を確認したのか具体的に
書いた方がいいよ。

>>735

説明が下手で申し訳ないのですが・・・
Aの画面を操作する時はCのテーブルを使用します
Bの画面を操作する時もCのテーブルを使用します

別々の所からのアクセスでAとB画面から同時にCのテーブルを扱っているようなのですが
（どちらかは待ち状態になってたと思います。）
見た目上は両方操作が正常に終了している感じなのですが
トランザクションの開始はログに出ているのですが終了は出ておらず
ロックがかかりっぱなしの状態になり、以後Cのテーブルを使う操作をすると
タイムアウトになっている感じです。

>>738
永続的な接続をしてんのにロックしてるんじゃね？

>>731
INTに文字列つっこんでる時点で十分マスケだろうが

フルテキストインデックスについて質問です。

例えば (id, text) といったカラムを持つテーブルで
id >= 100 AND id < 200
の行において text に含まれる単語の出現頻度を得ることは可能でしょうか。

text は適宜分かち書きされた文書でフルテキストインデックスが貼ってる
仮定で
2ch 128
もなー 256
：
みたいな結果を得る方法があれば教えてください。

出現頻度を得たい語を指定したSQLでいいの、全域スキャンしてとにかく全部の語についての
頻度一覧を得たいのか。

>>744
頻度ランキングなどに利用したいので単語は指定しない SQL です。
なので、どちらかというと後者。

>>746
そのデータベースって超でっかい？

すごく…大きいです…

じゃあ腹ん中がパンパンになったか、タイムアウトしたかのどっちかだな

おなかの中でパンパンに大きくなっちゃうと、大変ですよね・・・
少しずつ抜くしかないかも