MySQLのトランザクション中の意図しない挙動について教えて頂きたいです

Question

MySQLのトランザクション中の挙動について理解できていない所があり、投稿致しました。
下記に、「実行環境」、「使用テーブル」、「実行結果」、「私が期待していた結果」、「PHPプログラム」を示します。

PHPプログラム実行後、「tanaka」さんが二つ登録されています（下記「実行結果」ご参照）
これは下記の「私が期待していた結果」に反していて不思議に感じています。また何故このような結果になるのか分からずに悩んでいます。

よろしければ、こういった結果になる理由や、「私が期待していた結果」にするための方法について教えて頂ければ嬉しいです。

---

実行環境
MySQLバージョン：5.5.38
PHPバージョン：5.5.29
レンタルサーバ：kagoya

使用テーブル（testテーブル）
※engine：InnoDB、isolation：REPEATABLE-READ、id:auto_increment

id	name
1	sato
2	suzuki

実行結果（testテーブル）

id	name
1	sato
3	tanaka
4	tanaka

私が期待していた結果（testテーブル）

id	name
1	sato
3	tanaka

PHPプログラム

<?php
session_start();
require_once('config.php');
require_once('functions.php');

// DB接続
$dbh = connectDb();

// トランザクション開始
$dbh->beginTransaction();

echo 'begin transaction：' . '<br>';

try {
    
    $sql = "delete from test 
        where id = :id";
    $stmt = $dbh->prepare($sql);
    $ret = $stmt->execute(array(
        ":id" => 2
    ));

    $sql = "select * from test";
    $stmt = $dbh->query($sql);
    $test = $stmt->fetchAll(PDO::FETCH_ASSOC);
    echo 'after delete：';
    var_dump($test);
    
    
    $sql = "insert into test (name) values (:name)";
    $stmt = $dbh->prepare($sql);
    $ret = $stmt->execute(array(
        ":name" => 'tanaka'
    ));

    // commit
    $dbh->commit();

    unset($dbh);

} catch (PDOException $e) {
    $dbh->rollBack();
    die($e->getMessage());
}

?>

※不思議なことにローカル環境（Windows、MySQL5.6.24、PHP5.6.8）では「私が期待していた結果」になっています。ローカル環境とKagoyaサーバ環境で挙動が違っていて更に悩んでいます。

Comments

[m.ts10806]

トランザクションなんですよね。
実際のコードを提示してください。これだけでは何とも言えません。

[nakashi]

失礼致しました。
具体的なコードを追記しました。
このような簡単なプログラムで動作を確かめているのですが、思いもよらぬ挙動で悩んでいて質問致しました。

[Orlofsky]

バグが見つかっても新しいパッチは用意してくれないであろう、サポート期限が切れたバージョンに執着する理由はないと思うのですが。
https://qiita.com/shogomuranushi/items/10df42a3c7037d588efc#mysql-%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E7%89%88

[nakashi]

ありがとうございます。おっしゃる通りと思います。MySQL、PHPのバージョンアップを進言してみます。
ということは、MySQL側の？バグの可能性があるということなのでしょうか？

[退会済みユーザー]

「思い通りの動作」とか期待する動作と、そうではない異常な動作の違いを、丁寧に説明してほしい。

[shun-K]

もう一回同じURLにアクセスすると
　1 sato
　3 tanaka
　4 tanaka
　5 tanaka
　6 tanaka
になりますでしょうか？
なんとなくですが、トランザクションの問題ではなく、何らかの理由でこのURLが2回アクセスされてるような気がします。

[nakashi]

はい、ありがとうございます。
私の中の「期待する動作」と「異常な動作」は次の通りです。
Kagoya環境ではdelte直後のselect抽出のvar_dump時点で、挙動が変になっているように思います。

【期待する動作】※現状のローカル環境での挙動

(1)delete直後のselect抽出のvar_dump

begin transaction：
after delete：
array (size=1)
0 =>
array (size=2)
'id' => string '1' (length=1)
'name' => string 'sato' (length=4)

(2)実行後の「test」テーブルの中身
1 sato
3 tanaka

【異常な動作】※現状のkagoyaサーバでの挙動

(1)delete直後のselect抽出結のvar_dump（文字化けしていますがそのまま貼り付けています）

begin transaction��<br>after delete�啾rray(2) {
[0]=>
array(2) {
["id"]=>
string(1) "1"
["name"]=>
string(4) "sato"
}
[1]=>
array(2) {
["id"]=>
string(1) "3"
["name"]=>
string(6) "tanaka"
}
}

(2)実行後の「test」テーブルの中身
1 sato
3 tanaka
4 tanaka

[KonPota]

まずは本当に複数回アクセスされていないか、問題を切り分けてはいかがでしょうか。
実行するたびに時間をファイルに追記するなど。

[nakashi]

ありがとうございます。
もう一度同じURLにアクセスすると次のようになりました。

1 sato
3 tanaka
4 tanaka
5 tanaka

[shun-K]

2回目は正常なのですね。
単にスタートが
1 sato
2 suzuki
3 tanaka
だったということはないでしょうか？

[Orlofsky]

>ローカル環境（Windows、MySQL5.6.24、PHP5.6.8）では思い通りの動作をしており
とあるので、kagoyaサーバ でも動作確認する価値はあるのでは？

[nakashi]

ありがとうございます。複数回アクセスの可能性ないか、自分でも考えてみます。

実験の度に、truncate test; をしてデータを空にして手動で 以下レコードを挿入して実験しています。念のため、drop tableして再度確かめてみます。
[テストデータ]
1 sato
2 suzuki

[nakashi]

>kagoyaサーバ でも動作確認する価値はあるのでは？
はい、ありがとうございます。kagoyaサーバで動作確認しているのですが、思いもよらぬ挙動で悩んでいます。（意味を取り違えていましたら申し訳ありません。）

[Orlofsky]

>思いもよらぬ挙動
それで掲示板を読んでいる人は誰も理解できません。
質問に具体的な内容を追記しては？別の質問になるなら別の質問を建てては？

[nakashi]

>質問に具体的な内容を追記しては？別の質問になるなら別の質問を建てては？
失礼しました。質問内容を整理して書き直しました。（この掲示板に不慣れなのですみません。）

[m.ts10806]

基本は質問に追記してください。
既に試してるかもしれませんが一度テーブル作り直して(データdeleteではなくDROP TABLEからCREATE TABLE)試してみてください。

Answer 1

皆さま、色々とアドバイスをありがとうございます。
その後なのですが、無事に「期待していた結果」が出るようになりました。

時間に追われ慌てておりましたので、下記のような対応を連続でしてしまい、申し訳ありませんが原因の切り分けは十分に出来ておりません。
しかしながら、皆さまがおっしゃる通り、アクセスが2回発生していた可能性が非常に高いと思います。
アドバイスを参考に、KagoyaサーバでApacheアクセスログを取得するように設定しましたので、暫くはログを注意深く見ていこうと思います。

急な相談にも関わらず、多くの方にご意見を頂きましてありがとうございました。
助かりました。御礼申し上げます。

---

行った対応

[クライアント側]

• PC再起動
• ウイルス対策ソフトのバージョンアップ
• Chrome拡張機能の停止
• Windows更新プログラム適用

[サーバ側]

• 新DB作成（新DBで実験）
• PHP再起動＆php.ini微修正(memory_limit等)
• Apacheアクセスログ取得設定

Answer 2

単純にどこかで２度読み込んでいるだけだと思いますが対処方法としては
deleteしたあとにrowCountして、0だったら処理を中断すればいいでしょう
(ただし削除しなくてもinsertしたいならロジックが違いますが)

Answer 3

delete文でid=2のsuzukiを削除して、
auto incrementなidでtanakaをinseto into文したのを、
2度繰り返しただけじゃないの？

削除したidはリサイクルされないので。

一回しか実行してないのだとしたら、
ブラウザ拡張とかウイルス対策ソフトが先にページを読みに行っていないだろうか。
webサーバーのアクセスログに残るuser-agentがブラウザのものかどうか、
丁寧に洗ってみてほしい。

Comments

[nakashi]

ありがとうございます。delete後、insertは1度しか行っていないです。
それで「tanaka」さんが2人になる理由が検討付かず、悩んでいます。

[退会済みユーザー]

何らかの方法手段で、そのページを2度読んでるはず。