#関連する学習に関する推奨事項: mysql チュートリアル
cannotsayno
今日残業していたら、営業の女の子がデータを確認しに来て、データが間違っていると言いました。女の子の SQL が次のように書かれているのを確認しました。
select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and prs_dmtd_cde in ('p','n');复制代码
ログイン後にコピー
分析したところ問題がなかったので、prs_dmtd_cde フィールドのコード値を確認したところ、大文字の P だけでなく、しかし、女の子は小文字の p だけをチェックしましたが、データ量ははるかに多かったです。
そこで、女の子の SQL を変更しました:
select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and prs_dmtd_cde in ('p','n','P','N');复制代码
ログイン後にコピー
結果は同じでした。それでおしまい。 。 。
もちろん女の子の前で断ることはできないので、女の子に戻って見てもらうように頼みました。
すぐにオンラインで調べたところ、MySQL のエンコード形式とソート ルールに問題があることがわかりました。
理由を知る
MySQL データベースは基本的に utf8 エンコード形式を使用しており、utf8 エンコード形式にはさまざまなソート ルールがあります。一般的に使用されるものは次のとおりです。
utf8_bin: 文字列内の各文字を 16 進データとして格納します。大文字と小文字は区別されます。
utf8_general_ci: 大文字と小文字を区別しない、ci は case insensitive の略語、つまり大文字と小文字を区別しません。
デフォルトの文字セット設定を再度確認してください:
utf8 エンコード形式のデフォルトの並べ替えルールは utf8_general_ci です。つまり、そうではありません。大文字と小文字を区別。
解決策
問題の原因が分かれば、適切な薬を処方できます。
解決策は当然、フィールドの照合属性を utf8_bin に直接変更することです。
ALTER TABLE prvt_pub_stmt_vn CHANGE prs_dmtd_cde prs_dmtd_cde VARCHAR(255)
CHARACTER SET utf8 COLLATE utf8_bin;复制代码
ログイン後にコピー
もう 1 つの解決策は、元のテーブル構造を変更する代わりに SQL を変更することです。クエリフィールドの前にバイナリキーワードを追加します。
select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and binary prs_dmtd_cde in ('p','n');复制代码
ログイン後にコピー
Mysql のデフォルト クエリでは大文字と小文字が区別されません。SQL ステートメントにバイナリを追加して、大文字と小文字を区別するようにすることができます。
binary は関数ではなく型変換演算子です。これに続く文字列を強制的にバイナリ文字列にするために使用されます。文字列の比較では大文字と小文字が区別されることがわかります。
ついに
問題は解決しました もちろん、私はその少女に、問題がどれほど深刻であるか、そして原理をどのように分析して最終的に解決したかを話しました。
もちろん、女の子が投げかける愛らしい視線を見るのはとてもうれしいです。
最も重要なことは、この問題を覚えておくことです。将来、フィールドで大文字と小文字が区別されるビジネス ケースに遭遇した場合は、テーブルを作成する際に文字セットとソート ルールの選択に注意して回避する必要があります。これは今日の出来事です。
プログラミング学習について詳しく知りたい方は、php training のコラムに注目してください!
以上がMySQLのwhereクエリを再理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。