12:23申し訳ございません。記載にミスがあり文字型もデータに含まれていました。間違った情報でお時間を取らせてしまいすいませんでした。記載内容を修正し、重複を発見したと考える手順を追記いたしました。記載にミスがあり文字型もデータに含まれていました。間違った情報でお時間を取らせてしまいすいませんでした。記載内容を修正し、重複を発見したと考える手順を追記いたしました。件sort評価が高い順sort新着順sort古い順link02番目のSQLだけでも重複行が存在するというのは変に思えますね。因みに重複行があるとはco1_1~col_9の何れを比較しても一致する行が2行以上あるということですよね?ソートするとまったく同じ行があったみたいな。co1_9もし重複行が出たとしたらそのカラムに問題があるのかも知れません。データ型が文字なら見た目同じでもデータは異なったというケースが想定できますが、数値ではそれも無いでしょうし。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。12:23申し訳ございません。記載にミスがあり文字型もデータに含まれていました。間違った情報でお時間を取らせてしまいすいませんでした。記載にミスがあり文字型もデータに含まれていました。間違った情報でお時間を取らせてしまいすいませんでした。13:31その通りです。絞り込み条件(見た目が重複っぽいもの)を加えると見つかるとい現象が起きています。最初書き間違いを疑ったので、2.4の行を実行→2,4のsqlをコピーwhere句を消し、それを実行というやり方をしてみたのですが、結果が変わらず。絞り込み条件を除いてまったく同じはずなので、見えない文字やutf8_unicode_ciによる影響もないような気がするんですが・・・その通りです。絞り込み条件(見た目が重複っぽいもの)を加えると見つかるとい現象が起きています。最初書き間違いを疑ったので、2.4の行を実行→2,4のsqlをコピーwhere句を消し、それを実行というやり方をしてみたのですが、結果が変わらず。コメント内容に誤りがあり一部修正しました。2.2でHITが無く、2.4にHITがあるのかは私にはわかりません。IN(1,2)これで3行以上HITしたりしないでしょうか?後はtable_2のIDはユニークだとして、ID1とID2のco1_1~col_10は実際には一致していますか?すみません。コメント内容に誤りがあり一部修正しました。2.2でHITが無く、2.4にHITがあるのかは私にはわかりません。(記載漏れ度々すいません。ID2に該当するものはそれぞれ一つずつしか現れませんでした。以下、投稿内容を修正しました。一致しているかの判断をどうすればいいかわからなかったので、とりあえず投稿に加筆したSQLを流してみて一致しているという判断を下しました。何かベストな確認方法があればお教えください。(記載漏れ度々すいません。ID2に該当するものはそれぞれ一つずつしか現れませんでした。以下、投稿内容を修正しました。一致しているかの判断をどうすればいいかわからなかったので、とりあえず投稿に加筆したSQLを流してみて一致しているという判断を下しました。何かベストな確認方法があればお教えください。19:05原因や理由はさっぱりわからないのですが、データが重複と判定されるか異なると判定されるかの違いは、データがサブクエリを経由したかどうかに掛かっているようですね。(MySQLではIN句は実際にはサブクエリが動作しているようですので。試みても抽出はゼロになるのではないかと予測します。実際のデータが一致しているか異なっているのかはバイナリ値を比較してみればわかると思います。データが違った(もしくは一致していた)が判明したとして、なんでSQL上で本件のような現象が起きているのかは私にはわかりません。中途半端でスミマセン。原因や理由はさっぱりわからないのですが、データが重複と判定されるか異なると判定されるかの違いは、データがサブクエリを経由したかどうかに掛かっているようですね。(MySQLではIN句は実際にはサブクエリが動作しているようですので。試みても抽出はゼロになるのではないかと予測します。実際のデータが一致しているか異なっているのかはバイナリ値を比較してみればわかると思います。データが違った(もしくは一致していた)が判明したとして、なんでSQL上で本件のような現象が起きているのかは私にはわかりません。中途半端でスミマセン。15:15丁寧な回答をしていただきありがとうございます。ご指摘いただいたようにbinary値の比較をしてみると、col_6で違いが出てきました。ありがとうございます。where句の有無に関する部分については、もうちょっと調べてみて何かわかったら追記しておきます。丁寧な回答をしていただきありがとうございます。ご指摘いただいたようにbinary値の比較をしてみると、col_6で違いが出てきました。ありがとうございます。where句の有無に関する部分については、もうちょっと調べてみて何かわかったら追記しておきます。編集>>binary値の比較をしてみると、col_6で違いが出てきました。特定(?)のバイナリ値で差異をもつデータは特定の条件下で同じと判定されているということですね。内部的に型変換が動いているのかも知れませんね。(もしかするとDBに一定の条件で起動する関数を登録してたりはしませんか?それが勝手に型変換やTAB/空白排除をしてる可能性もあるかも知れません。)>>where句の有無に関する部分についてはあ、前のコメントに書いたのはwhere句ではなくて、幾つかの結果を見たらサブクエリを経由した場合にbinary値の異なる値を重複と判定しているように見えましたので、inをwhereに置換してサブクエリを排除したらどうなるのかなと思ったものです。>>binary値の比較をしてみると、col_6で違いが出てきました。特定(?)のバイナリ値で差異をもつデータは特定の条件下で同じと判定されているということですね。内部的に型変換が動いているのかも知れませんね。(もしかするとDBに一定の条件で起動する関数を登録してたりはしませんか?それが勝手に型変換やTAB/空白排除をしてる可能性もあるかも知れません。あ、前のコメントに書いたのはwhere句ではなくて、幾つかの結果を見たらサブクエリを経由した場合にbinary値の異なる値を重複と判定しているように見えましたので、inをwhereに置換してサブクエリを排除したらどうなるのかなと思ったものです。グループ関数とセットで使うのがマナーです。SQLはきちんと覚えた方が良いです。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。12:27なるほど、そんなマナーがあるとは知りませんでした。ご指摘ありがとうございます。ご指摘いただいたSQLを流してみてもやはり結果は変わりませんでした。行った場合で、内部の処理ロジック/パフォーマンスが変わったりするのでしょうか。そんなマナーがあるとは知りませんでした。ご指摘ありがとうございます。ご指摘いただいたSQLを流してみてもやはり結果は変わりませんでした。行った場合で、内部の処理ロジック/パフォーマンスが変わったりするのでしょうか。00:07Mikan様、Orlofsky様、横から失礼します。行った場合で、内部の処理ロジック/パフォーマンスが変わったりするのでしょうか。変わる場合も、変わらない場合もあります。両者で実行計画が同じ場合も、異なる場合もあるからです。操作対象のテーブルのレコード数や格納されているデータ、インデックスの有無など、様々な状況によって劇的にパフォーマンスに差が出る場合があります。そのため、画一的に「こちらを使うべき」と考える必要はなく、ケースバイケースで最適な方法を選択するのが良いです。実行計画については以下を参照https://dev.mysql.com/doc/refman/5.6/ja/explain.htmlhttp://nippondanji.blogspot.jp/2009/03/mysqlexplain.htmlMikan様、Orlofsky様、横から失礼します。行った場合で、内部の処理ロジック/パフォーマンスが変わったりするのでしょうか。変わる場合も、変わらない場合もあります。両者で実行計画が同じ場合も、異なる場合もあるからです。劇的にパフォーマンスに差が出る場合があります。考える必要はなく、ケースバイケースで最適な方法を選択するのが良いです。BY"それぞれの実行計画(*)を取得してみると分かりますが、両者で実行計画が同じ場合も、異なる場合もあるからです。内部では各々の計算手法で最適と思われる実行計画を選んでいるので一緒になる場合もあれば、違う場合もあるという感じなのですね。>そのため、画一的に「こちらを使うべき」と考える必要はなく、ケースバイケースで最適な方法を選択するのが良いです。銀の弾丸みたいなものはどこにもないんですね〜。教えていただいた実行計画の取り方やパフォーマンスチューニングなどの方法を調べながら、そのあたりの知見を増やしていこうと思います。丁寧な解説ありがとうございました。BY"それぞれの実行計画(*)を取得してみると分かりますが、両者で実行計画が同じ場合も、異なる場合もあるからです。内部では各々の計算手法で最適と思われる実行計画を選んでいるので一緒になる場合もあれば、違う場合もあるという感じなのですね。>そのため、画一的に「こちらを使うべき」と考える必要はなく、ケースバイケースで最適な方法を選択するのが良いです。銀の弾丸みたいなものはどこにもないんですね〜。教えていただいた実行計画の取り方やパフォーマンスチューニングなどの方法を調べながら、そのあたりの知見を増やしていこうと思います。丁寧な解説ありがとうございました。07:11KiyoshiMotoki様、フォローありがとうございます。SQLはきちんと統計情報を取得した上で実行計画を確認するのがいちおうの目安。処理時間を実測してベストなSQLをチョイスって手間はかかります。Mikan様はSQLをきちんと学んでください。KiyoshiMotoki様、フォローありがとうございます。SQLはきちんと統計情報を取得した上で実行計画を確認するのがいちおうの目安。処理時間を実測してベストなSQLをチョイスって手間はかかります。Mikan様はSQLをきちんと学んでください。キャンセル完了するlink0情報の追記、ありがとうございます。追記いただいた情報をもとに調査してみましたが、私も原因が分かりませんorzそのため、以下に記載する内容は具体的な回答ではない事を前置きさせていただきます。byしたtable_1のデータを登録する。稼働中のサービスがアクセスしていたりしませんね?で、ここから本題です。疑わしいレコードを特定できているようなので、次は「疑わしいレコードのどのカラムに差分が発生しているか」を特定しましょう。原因の箇所を絞り込めば、それだけ調査は前進できると思いますので。b.col_[n]部分を1行ずつ、以下のように変更しながら繰り返し実施してみて下さい。b.col_[n]以下のような要領です。データが返却されなくなるはずです。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。14:58回答が遅くなってしまいすいません。前提条件の部分なのですが、再度冷静に確認/実行しましたが、カラム数やtable_2の状態は質問内容通りとなっていました。ここからが本題の方ですが、ご指摘いただいた方法でbinary比較をしていったところ、col_6にbinaryをつけた段階で表示結果が変わりましたので、col_6の値がbinaryレベルで違うことがわかりました。ありがとうございます。byの際の比較ではbinaryレベルで行い、=を用いた比較ではbinaryレベルではない比較(何で比較しているのかはよく分からない)しているように思うのですが、これらの認識であっているでしょうか。回答が遅くなってしまいすいません。前提条件の部分なのですが、再度冷静に確認/実行しましたが、カラム数やtable_2の状態は質問内容通りとなっていました。ここからが本題の方ですが、ご指摘いただいた方法でbinary比較をしていったところ、col_6にbinaryをつけた段階で表示結果が変わりましたので、col_6の値がbinaryレベルで違うことがわかりました。ありがとうございます。byの際の比較ではbinaryレベルで行い、=を用いた比較ではbinaryレベルではない比較(何で比較しているのかはよく分からない)しているように思うのですが、これらの認識であっているでしょうか。編集Mikan様、ご報告ありがとうございます。col_6の値がbinaryレベルで違うことがわかりました。・どの文字がどのように異なっているのか・table_1とtable_2との間で、値が異なっていないか(INSERT時にデータが壊れていないか)など、さらに踏み込んだ調査が可能になりますね。byの際の比較ではbinaryレベルで行い、=を用いた比較ではbinaryレベルではない比較(何で比較しているのかはよく分からない)しているように思うのですが、これらの認識であっているでしょうか。(対象のカラムに指定されている"COLLATE"属性)で比較しているはずです。BY句にBINARY句をつけた場合とつけない場合とで結果が変わる事からも、この認識で間違いないように思います。sec)Mikan様、ご報告ありがとうございます。col_6の値がbinaryレベルで違うことがわかりました。踏み込んだ調査が可能になりますね。byの際の比較ではbinaryレベルで行い、=を用いた比較ではbinaryレベルではない比較(何で比較しているのかはよく分からない)しているように思うのですが、これらの認識であっているでしょうか。(対象のカラムに指定されている"COLLATE"属性)で比較しているはずです。この認識で間違いないように思います。07:13Mikanさんは最初からhttp://qiita.com/sawarame/items/aa99408ce24930ad7defテーブルのCREATE文を提示すると解決が早かったかも?できればダブっているデータを含んでいるINSERT文も。できればダブっているデータを含んでいるINSERT文も。条件に合致したデータをうまくとりたい解決済サブクエリでおおもとのクエリのエイリアスを使った時のエラーを説明して下さい。BY(複数カラム)を実行しても重複が残るのですが、理由がわかりません。頂いたご意見への回答は行っておりません。