変換は必要ありません。比較演算の両方の引数が文字列の場合は、文字列として比較されます。両方の引数が整数の場合は、整数として比較されます。進値が数字と比較されない場合は、バイナリ文字列として処理されます。カラムで他方が定数の場合は、比較が実行される前に定数がタイムスタンプに変換されます。より適合させるために実行されます。引数には実行されません。念のため、比較を行う際は、常に完全な日付時間、日付、または時間文字列を使用してください。使用して、明示的に値を目的のデータ型に変換します。単一行のサブクエリーは、定数とみなされません。つの整数として実行されます。整数は時間値には変換されません。進値の場合、比較はその他の引数に依存します。進値として比較され、その他の引数が浮動小数点値の場合、引数は浮動小数点値として比較されます。数として比較されます。双方を浮動小数点数に変換してから比較することになります。前記PHPスクリプトの実行結果は以下の通りです。1801537632024345918015376320243461を検索したのに、18015376320243459が返るという不思議な結果となっています。SQL文単体の実行では下記となります。数として比較されます」という仕様に起因します。浮動小数点数(倍精度)の仮数部の桁数は52ビット(暗黙のビットを足して53ビット、10進16桁弱)しかなく、18015376320243461という10進17桁の整数を正確に表現できないことが原因です。bindValueでバインドする値をint型にキャストすると、生成されるSQL文と実行結果は下記となります。sec)今度は浮動小数点数を経由しないため、正確な結果が返ります。先のスライドでint型へのキャストをいれていた理由は、このためです。よい方法はないか?64ビット版のPHPを使った場合でも、int型の最大値は9223372036854775807なので、これを超えると冒頭の指摘のように不具合がおきます。この場合はどうしたらよいでしょうか?そもそも数値型を使わずに文字列型を使う方法もありますが、その場合は数値計算が出来ません。DECIMAL型は65桁までの十進数が使えるのにもったいないですね。面倒ですが、以下のように型変換を明示すれば、暗黙の型変換およびそれに伴う浮動小数点数への変換を防ぐことが出来ます。DECIMAL(20))実行結果は以下の通りです。sec)まとめPDOのサンプルスクリプトで、バインド時に整数型の値をintにキャストしていた理由を説明しました。intへのキャストは桁あふれの危険性はあるものの、浮動小数点数への暗黙の型変換よりはマシという意味で、一種のバッドノウハウだと思います。MySQLの暗黙の型変換は本当にやっかいで、詳しくは下記の参考文献をお読み下さい。本当に望ましい書き方は、PHPスクリプトではなくSQL文側にキャストを書くことでしょうが、もっと良い方法があれば、ご教授下さい。実は、先のid型にインデックスをつけた場合は、先ほどとは挙動が変わります。sec)インデックスの有無で挙動が変わるのは、MySQLのバグではないかと思いますが、この「バグ」を修正するのは中々やっかいだなと思います。【HASHコンサルティング広告】HASHコンサルティング株式会社は、ウェブアプリケーションのセキュリティに関心のあるセキュリティエンジニアを募集しています。興味のある方は、twitterやfacebookのメッセージ、あるいは問い合わせページからお問い合わせください。11:16蛇足に関して、5.7.12で観測できず5.6.30で観測できたので、一応バグレポート報告しました。13:05ありがとうございました。