mysql:16345

yoku0825です。

> 同時期にリリースされたChanges in MySQL 5.6.29 (2016-02-05)でも、

> ..

> 5.7.12でもBug Fixとなっていない為、


リリースノートは原則、「このバグをFIXしたよ」が記載されており、
「発見したよ」や「混入したよ」ではないため、
5.6.29以降または5.7.11以降ではこのバグは発生しないはずです。


というわけで、バージョンアップすれば大丈夫…な…はず…です…。
（再発したら別のバグということで。。）


yoku0825,


2016年5月25日 15:42 たくや <yata.s15ste@xxxxxxxxxx>:
> yokuさま

>

> 返信ありがとうございます。たくやです。

>

> 内容拝見させていただきました。

>

> まさにこれな気がします。

> 英文内容が事象とドンピシャな感じですね。

> 同時期にリリースされたChanges in MySQL 5.6.29 (2016-02-05)でも、

> 同様のバグ内容がリリースされておりました。

>

> ということは、

> この時期にリリースされた改修の中で生じたバグなのかも知れませんね。

> （それ以前のチェンジログでは発生してませんでした）

>

> MySQL自体の不具合と判ればやりようはあります。

> 5.7.12でもBug Fixとなっていない為、

> 念のため一つ一つ変数の型を合わせていく地道な作業ですが（泣）

>

> ・・・まあ、サーバ終了は「少なくともはよ直してくれ」とは思います。

>

>

> というわけで、

> 今回の投稿内容についてはクローズしたいと思います。

>

> ありがとうございました。

>

> -----Original Message-----

> From: yoku ts. [mailto:yoku0825@xxxxxxxxxx]

> Sent: Wednesday, May 25, 2016 2:15 PM

> To: ml@xxxxxxxxxx

> Subject: [mysql 16343] Re: [mysql 16342] RE: [mysql 16341] Re: [mysql 16340] ストアド内SelectInto句の挙動について（MySQL5.7）

>

> こんにちは、yoku0825です。

>

>

> 5.7.11のチェンジログにこんなものを見つけました。

>

>> Data corruption or a server exit could occur if a stored procedure had a variable declared as TEXT or BLOB and data was copied to that variable using SELECT ... INTO syntax from a TEXT or BLOB column. (Bug #22203532, Bug #22232332, Bug #21941152)

>

> http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-11.html

>

>

> var_textはTEXT型なので、これにマッチしているような気がします。

> （8桁バグ番号はOracle社管理のバグ番号なので、詳細は外部から見られないのですが）

>

> しかし "or a server exit"ってなかなかゴツいですね。。

>

>

> yoku0825,

>

> 2016年5月24日 12:43 たくや <yata.s15ste@xxxxxxxxxx>:

>> yokuさま

>>

>> 返信ありがとうございます。たくやです。

>>

>> まず、後半の

>> SET SESSION optimizer_switch= 'mrr=off';

>> について試してみましたが、var_text ->[eeee]で出力しました（改善せず）

>>

>>>元のデータで、暗黙の型変換などでvarcharがDOUBLEにキャストされて

>>>が2行返しちゃってるとかそんなことはないでしょうか…。

>> 確かに挙動を発見した際のSELECT INTO文（郵便番号TBL時）では

>> 2行返しそうなんですけど、サンプル提示した状態だと

>> cd自体が一意になってますから2行は返らないと思います。

>>

>>

>> 私も別環境RHEL6系+MySQL5.7.12-Enterprise版で

>> 試してみたんですが、この条件では発生しませんでした。

>>

>> 今のところ、yokuさまの3端末に加えて、

>> 私が確認できる2端末でも発生せずでしたので、

>> 発生した環境（自機MySQL 5.7.10）のみで確認できる内容となりました。

>>

>> 自機MySQL 5.7.10については

>> 他の環境が新規でインストールしたものに対して、

>> MySQL 5.6系からyum + mysql_upgradeしたという違いがあるぐらいです。

>>

>>

>> 記載いただいたURL内の暗黙の型変換が

>> 一番可能性が高そうだなって思ってみてましたが

>> 自分が保有する1環境のみで発生しているとなると

>> 環境依存かパラメータの可能性が濃厚ですね。

>>

>>

>> ちなみに申し上げると、

>>  |---------------------------------------------------------|

>>  |zipcode| state |              city|                 town |

>>  |---------------------------------------------------------|

>>  |0010000| 北海道|        札幌市北区|  以下に掲載がない場合|

>>  |    ・・・|    ・・・|               ・・・|                   ・・・|

>>  |9071800| 沖縄県|  八重山郡与那国町|  以下に掲載がない場合|

>>  |9071801| 沖縄県|  八重山郡与那国町|                与那国|

>>  ----------------------------------------------------------

>> 挙動発見時時はこんな感じの郵便番号テーブル（cityとtownを取得）でして、

>>

>> 条件のZipcodeに何を設定しても

>> cityは[八重山郡与那国町]

>> townに至っては［与那国掲載］（一部結合？？？）

>> という結果が返ってきてました。

>>

>> 八重山郡与那国町のデータはテーブル上最後の行と最後から2番目行ですね。

>>

>>

>> なかなか香ばしい挙動です。

>>

>> -----Original Message-----

>> From: yoku ts. [mailto:yoku0825@xxxxxxxxxx]

>> Sent: Tuesday, May 24, 2016 11:00 AM

>> To: ml@xxxxxxxxxx

>> Subject: [mysql 16341] Re: [mysql 16340] ストアド内SelectInto句の挙動について（MySQL5.7）

>>

>> こんにちは、yoku0825といいます。

>>

>> 取り急ぎ、CentOS 6.6のMySQL 5.7.10とMySQL 5.7.12、

>> Windowsの5.7.10（x64）でもいただいたテストケースだと再現しませんでした。

>>

>> 元のデータで、暗黙の型変換などでvarcharがDOUBLEにキャストされて

>>> select word,word

>>> into var_text,var_text2

>>> from dtb_test

>>> where cd = '1111';

>>

>> が2行返しちゃってるとかそんなことはないでしょうか…。

>>

>> http://soudai1025.blogspot.jp/2015/12/mysql.html

>>

>>

>> それか、5.6の初期ではMRRが同じ行を2回返しちゃうようなバグがあったので、

>> それを疑うなら

>>

>> mysql> SET SESSION optimizer_switch= 'mrr=off';

>> としてから、CALL test_proc(); してみてもらえませんか？

>>

>>

>> yoku0825,

>>

>>

>> 2016年5月23日 16:28  <yata.s15ste@xxxxxxxxxx>:

>>> 初めて投稿させていただきます。

>>> 開発者のたくやと申します。

>>>

>>>

>>> 当方が利用している環境において、

>>> 不具合か仕様通りかどうか判断しかねる事象が発生したので、

>>> 皆様の知恵をお借りしたいと思い投稿させていただきました。

>>>

>>>

>>> [概要]

>>>　 MySQL5.7系環境において、

>>>　 ストアドプロシージャ（もしくはファンクション）内で

>>>　 非キー項目によるWhere条件を設定し、

>>>　 Select Into 句を利用したときの挙動が思惑と異なる。

>>>

>>> [実行環境]

>>>   ・Linux RHEL6系

>>>   ・MySQL 5.7.10-log Community Server

>>>　 ・スキーマのデフォルト文字コードはUTF-8

>>>

>>>

>>> [再現手順]

>>>　 １）前提として、以下テーブルを作っておく。

>>>　   CREATE TABLE `dtb_test` (

>>>　     `iddtb_test` int(11) NOT NULL AUTO_INCREMENT,

>>>　     `cd` varchar(12) DEFAULT '',

>>>　     `word` varchar(45) DEFAULT NULL,

>>>　     PRIMARY KEY (`iddtb_test`)

>>>　   ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

>>>

>>>　 ２）以下データを設定する。

>>>         ①iddtb_test ②cd ③word

>>>         |--------------|

>>>         |①|  ②|    ③|

>>>         |--------------|

>>>         |1| 1111|  aaaa|

>>>         |2| 2222|  bbbb|

>>>         |3| 3333|  cccc|

>>>         |4| 4444|  dddd|

>>>         |5| 5555|  eeee|

>>>         ----------------

>>>

>>>　 ３）以下ストアドをデモとして作成する。

>>>         DELIMITER $$

>>>         CREATE PROCEDURE `test_proc`()

>>>         BEGIN

>>>

>>>         declare var_text text default '';

>>>         declare var_text2 varchar(45) default '';

>>>

>>>         select word,word

>>>         into var_text,var_text2

>>>         from dtb_test

>>>         where cd = '1111';

>>>

>>>         select var_text,var_text2;

>>>

>>>         END$$

>>>         DELIMITER ;

>>>

>>>　 ４）作成したストアドを実行する。

>>>

>>> [求める結果として]

>>>　　 最後のSelect文で出力される結果がいずれも[aaaa]となること。

>>>

>>> [結果]

>>>　　 var_text ->[eeee]（こちらが思惑と異なる）

>>>　　 var_text2->[aaaa]

>>>

>>>

>>> [補足事項]

>>>　 ・MySQL 5.6.26 Community Server (Windows7)では求める結果var_text ->[aaaa]

>>> が出力されました。

>>>　 ・該当の条件句であるcdをInt型に変更してもvar_text ->[eeee]で出力されまし

>>> た。

>>>　 ・条件句のcdに対してUnique Indexを付与すると、var_text ->[aaaa]で出力され

>>> ました。

>>>　 ・元々は郵便番号TBLのzipcodeで検索をかけるような処理のときに発生した事象の

>>> 為、

>>>　　 Unique Indexを仕様的に付与できかねます。

>>>　 ・Select Into時に Convert(word,char)をするとvar_text ->[aaaa]で出力されま

>>> した。

>>>

>>>

>>> 現象が発生してから、補足事項に提示したパターンなどを検証しました。

>>>

>>> 検証の結果、varchar型の文字列をTEXT型変数に入れる際に

>>> 条件句をスルーしてしまうような不具合があるののかなとも思っていますが、

>>> もしかしたらTEXT型とvarchar型が非互換という可能性も考えて、

>>> 質問させていただきました。

>>>

>>> どなたかご教示いただければ幸いです。

>>>

>>> 以上、よろしくお願いいたします。

>>>

>>>