Je ne peux pas dire non

Je faisais des heures supplémentaires aujourd'hui, et la vendeuse est venue nous voir pour vérifier les données et a dit que les données étaient fausses. J'ai vu que le SQL de la fille était écrit comme ceci :

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;);复制代码

Copier après la connexion

Je l'ai analysé et j'ai trouvé qu'il n'y avait pas de problème, j'ai donc vérifié la valeur de code du champ prs_dmtd_cde et j'ai trouvé qu'il y avait non seulement des P majuscules mais aussi p minuscule. Mais la fille n'a vérifié que le p minuscule, mais la quantité de données était beaucoup plus importante.

J'ai donc changé le SQL de la fille :

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;,&#39;P&#39;,&#39;N&#39;);复制代码

Copier après la connexion

Les résultats se sont avérés être les mêmes. C'est ça. . .

Bien sûr, on ne peut pas dire non devant une fille, alors je lui ai demandé de revenir en arrière et de jeter un œil.

J'ai rapidement vérifié en ligne et découvert qu'il s'agissait d'un problème avec le format d'encodage et les règles de tri de MySQL.

Sachez pourquoi

Notre base de données MySQL utilise essentiellement le format d'encodage utf8, et il existe différentes règles de tri pour le format d'encodage utf8. Les plus couramment utilisés sont les suivants :

utf8_bin : stocke chaque caractère de la chaîne sous forme de données hexadécimales, sensible à la casse.

utf8_general_ci : insensible à la casse, ci est l'abréviation de insensible à la casse, c'est-à-dire insensible à la casse.

Vérifiez à nouveau les paramètres du jeu de caractères par défaut :

Re-compréhension de la requête Where de MySQL

Il se trouve que la règle de tri par défaut du format d'encodage utf8 est : utf8_general_ci - c'est-à-dire la casse -insensible.

Solution

Si la cause du problème est trouvée, nous pouvons alors prescrire le bon remède.

La solution est naturellement de modifier directement l'attribut collate du champ en utf8_bin.

ALTER TABLE prvt_pub_stmt_vn CHANGE prs_dmtd_cde prs_dmtd_cde VARCHAR(255) 
CHARACTER SET utf8 COLLATE utf8_bin;复制代码

Copier après la connexion

Il existe une autre solution, qui n'est pas de changer la structure originale de la table, mais de changer le SQL. Ajoutez le mot-clé binaire avant le champ de requête.

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and binary prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;);复制代码

Copier après la connexion

La requête par défaut MySQL n'est pas sensible à la casse. Vous pouvez ajouter du binaire à l'instruction SQL pour la rendre sensible à la casse.

binaire n'est pas une fonction, mais un opérateur de conversion de type. Il est utilisé pour forcer la chaîne derrière elle à être une chaîne binaire. On peut comprendre que la comparaison de chaînes est sensible à la casse.

Enfin

Le problème a été résolu. Bien sûr, j'ai dit à la fille à quel point le problème était profond et comment j'avais analysé le principe et je l'avais finalement résolu.

Bien sûr, je suis très heureux quand je vois le regard adorateur de la fille.

La chose la plus importante est de garder à l'esprit ce problème. À l'avenir, lorsque vous rencontrerez des analyses de rentabilisation dans lesquelles les champs sont sensibles à la casse, vous devrez faire attention au choix du jeu de caractères et aux règles de tri lors de la création de tableaux pour éviter. quelque chose comme ça se passe aujourd'hui.