Quelqu'un peut-il me dire si un serveur MySQL SELECT La requête est sensible à la casse ou insensible à la casse par défaut ? Et si ce n'est pas le cas, quelle requête devrais-je envoyer pour pouvoir faire quelque chose comme :
SELECT * FROM `table` WHERE `Value` = "iaresavage"Alors qu'en réalité, la valeur réelle de Value est IAreSavage .
Ils sont insensible à la casse à moins que vous ne fassiez un comparaison binaire .
Je suis en grande partie d'accord avec le commentaire de Tim, je ne pense pas que faire un "lower()" sur vos valeurs partout soit la meilleure façon de le gérer, cela ressemble à une solution de contournement. Mais j'admets que parfois, cela a du sens et est plus facile. (Nous avons déplacé des données historiques dans une table mysql, ce qui a cassé la logique existante parce que les valeurs de certaines colonnes étaient insensibles à la casse. Nous avions besoin de connaître la différence entre "GE1234" et "ge1234", ils devaient être uniques et rester enregistrés de cette façon. Nous avons défini notre colonne dans l'instruction create table de la façon suivante : varchar(20) CHARACTER SET utf8 COLLATE utf8_bin
Je ne sais pas pourquoi tant de gens ont voté pour ça. Il est clairement indiqué ici dev.mysql.com/doc/refman/5.0/fr/case-sensitivity.html que "...cela signifie que pour les caractères alphabétiques, les comparaisons seront sensibles à la casse". Ainsi, si je cherche "DickSavagewood", il ne trouvera PAS "dicksavagewood". Si je fais la même chose avec LOWER(), il trouvera 'dicksavagewood'. Je réponds donc à la question : dans votre cas particulier, le SELECT est effectivement sensible à la casse.
@user1961753 : Relisez : "Pour les chaînes binaires (varbinary, blob)... sera sensible à la casse".
Vous pouvez mettre en minuscules la valeur et le paramètre passé :
SELECT * FROM `table` WHERE LOWER(`Value`) = LOWER("IAreSavage")Une autre (meilleure) façon de procéder serait d'utiliser la fonction COLLATE opérateur comme dit dans la documentation
Il est dit, sur la page de documentation mentionnée ci-dessus, que "les comparaisons de chaînes non binaires sont insensibles à la casse par défaut".
C'est terrifiant de voir le nombre de personnes qui ont voté pour cette réponse. Comme @Marc l'explique ci-dessus, les comparaisons son insensible à la casse. Vous devez comprendre les collations et les index et les configurer correctement - en utilisant des transformations de chaînes de caractères telles que LOWER() ou un COLLATE peut contourner complètement un index, et au fil du temps, à mesure que votre table s'agrandit, cela peut avoir des répercussions considérables sur les performances. Il s'agit probablement de noms d'utilisateurs que vous recherchez ? Utilisez une collation insensible à la casse et ajoutez un index unique à la colonne. Utilisez EXPLAIN pour confirmer que l'index est utilisé.
Quand est-il judicieux d'utiliser BINARY sur un seul côté du = (SELECT * FROM myTable WHERE BINARY 'something' = 'Something') ?
@Jimmy Que voulez-vous dire exactement ? Le code fonctionne. Lorsqu'un côté de la comparaison est converti en binaire, la comparaison est faite en binaire.
@Jori Oh, je suppose que j'ai mal lu - je pensais que l'un des deux exemples avait BINARY des deux côtés de l'égalité.
La comparaison des chaînes dans la phrase WHERE n'est pas sensible à la casse. Vous pouvez essayer de comparer en utilisant
WHERE `colname` = 'keyword'o
WHERE `colname` = 'KeyWord'et vous obtiendrez le même résultat . C'est le comportement par défaut de MySQL.
Si vous voulez que la comparaison soit sensible à la casse vous pourriez ajouter COLLATE juste comme ça :
WHERE `colname` COLLATE latin1_general_cs = 'KeyWord'Ce SQL donnerait un résultat différent de celui de celui-ci : WHERE colname COLLATE latin1_general_cs = 'keyword' (mot-clé)
latin1_general_cs est une collation courante ou par défaut dans la plupart des bases de données.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
53 votes
En fin de compte, cela dépend de la collation déposée - si c'est '_ci' (insensible à la casse) ou '_cs' (sensible à la casse).
18 votes
C'est une question mal formulée ;). La moitié des réponses vous montrent comment faire une comparaison insensible à la casse, l'autre moitié vise la sensibilité à la casse. Et une seule réponse vous dit que la valeur par défaut est en fait insensible à la casse :) Il est intéressant de noter que la sensibilité à la casse fonctionne même lorsque vous effectuez une comparaison de type
'value' in ('val1', 'val2', 'val3')6 votes
@SaltyNuts mec, lire cette question 7 ans plus tard et réaliser à quel point j'étais un noob est embarrassant ! J'aurais pu simplement lire la documentation et la réponse est dans la première phrase sur les instructions SELECT...
1 votes
Pour ajouter à ce que @JovanPerovic a dit, utf8_bin le rend également sensible à la casse. Je ne sais pas si cela existait déjà à l'époque.