Les champs stockés dans MySQL ne sont pas sensibles à la casse, le saviez-vous ?

00 Bref avis

J'ai déjà écrit un article sur la sensibilité à la casse des tables MySQL. En fait, le contenu stocké dans les champs dans MySQL n'est pas sensible à la casse. Cet article le résumera brièvement.

Vous souhaitez revoir :

Les règles de cas MySQL pour les noms de bases de données, les noms de tables, les noms de colonnes et les alias sous Linux sont les suivantes :

1. Il est strictement sensible à la casse ;

2. Les alias de table sont strictement sensibles à la casse ;

3. >

4. Le contenu du champ n'est pas sensible à la casse par défaut.

01 Un exemple

Exemple simple :

CREATE TABLE `tb_user` (
	`id` BIGINT (20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户id',
	`username` VARCHAR (50) NOT NULL COMMENT '用户名',
	PRIMARY KEY (`id`)
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '用户表';


INSERT INTO `u2s`.`tb_user` (`id`, `username`) VALUES ('1', 'user');
INSERT INTO `u2s`.`tb_user` (`id`, `username`) VALUES ('2', 'User');
INSERT INTO `u2s`.`tb_user` (`id`, `username`) VALUES ('3', 'USER');

Utilisez l'instruction de requête pour interroger les utilisateurs dont le nom d'utilisateur est entièrement en minuscules

Le résultat est que les trois. les enregistrements sont trouvés. Tous vérifiés.

mysql> SELECT username from tb_user where username = 'user';
+----------+
| username |
+----------+
| user     |
| User     |
| USER     |
+----------+
3 rows in set

userEn utilisant cet exemple pour illustrer brièvement, le contenu du champ n'est pas sensible à la casse par défaut.

Solution 02

** Parce que le contenu du champ n'est pas sensible à la casse par défaut, c'est-à-dire qu'il n'est pas sensible à la casse. **La solution consiste donc à ajouter des règles de vérification pour le contenu des champs.

Utilisez le mot-clé

de MySQL pour rendre la recherche sensible à la casse.

BINARY

Ajoutez le mot-clé

BINARY

mysql> select * from tb_user where BINARY username ='user';
+----+----------+
| id | username |
+----+----------+
|  1 | user     |
+----+----------+
1 row in set

à la requête SQL. Cette méthode est relativement simple. Vous n'avez pas besoin de modifier la structure de la table. pour distinguer les champs qui doivent être interrogés avant d'ajouter des mots-clés. Cette méthode présente également des inconvénients. Chaque fois que vous écrivez une requête, vous devez faire attention à l'ajout de mots-clés, et de nombreux codes peuvent devoir être modifiés.

Limiter lors de la création de la table

CREATE TABLE `tb_user1` (
	`id` BIGINT (20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户id',
	`username` VARCHAR (50) BINARY NOT NULL COMMENT '用户名',
	PRIMARY KEY (`id`)
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '用户表';


mysql> show create table tb_user1;
tb_user1 | CREATE TABLE `tb_user1` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '用户id',
  `username` varchar(50) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT '用户名',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表'
1 row in set

ou utiliser

CREATE TABLE `tb_user2` (
	`id` BIGINT (20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户id',
	`username` VARCHAR (50) NOT NULL COMMENT '用户名',
	`info` VARCHAR (100) NOT NULL COMMENT '详情描述',
	PRIMARY KEY (`id`)
) ENGINE = INNODB DEFAULT CHARSET = utf8 COLLATE=utf8_bin COMMENT = '用户表';

mysql> show create table tb_user2;
tb_user2 | CREATE TABLE `tb_user2` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '用户id',
  `username` varchar(50) COLLATE utf8_bin NOT NULL COMMENT '用户名',
  `info` varchar(100) COLLATE utf8_bin NOT NULL COMMENT '详情描述',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='用户表'

L'utilisation de

rendra tous les paramètres de type varchar dans le champ sensibles à la taille Écrire. Les détails de ces deux tables de vue ajoutent essentiellement

aux champs. NGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_binCOLLATE utf8_binRésumé 03

Le cas des valeurs de champ est contrôlé par les règles de classement de mysql. Lorsqu'il s'agit de règles de relecture, il faut parler de jeux de caractères. Un jeu de caractères est un ensemble de symboles et d'encodages, et une règle de classement est un ensemble de règles permettant de comparer les caractères au sein d'un jeu de caractères. De manière générale, une règle de classement commence par le nom de son jeu de caractères associé, incluant généralement un nom de langue, et se termine par _ci (insensible à la casse), _cs (sensible à la casse) ou _bin (binaire).

Par exemple, le jeu de caractères utf8, comme indiqué dans le tableau suivant :

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

2) utf8_general_ci : utf8_genera_ci n'est pas sensible à la casse, ci est l'abréviation de insensible à la casse, c'est-à-dire insensible à la casse.

3) utf8_general_cs : utf8_general_cs est sensible à la casse, cs est l'abréviation de sensible à la casse, c'est-à-dire sensible à la casse.

Remarque : La version 5.7 de ma machine ne prend pas en charge le jeu de caractères utf8_general_cs et une erreur a été signalée lors de la création.

Grâce au contenu de l'article précédent et de cet article, tout le monde a une certaine compréhension de la sensibilité à la casse de MySQL. Dans le développement réel, il est préférable d'utiliser des lettres minuscules pour les noms de bibliothèques et de tables. du contenu de stockage sur le terrain. Et rendez la configuration de MySQL dans l'environnement de développement local cohérente avec la configuration de MySQL sur le serveur pour éviter que des problèmes étranges ne surviennent en raison d'environnements incohérents.

Avez-vous rencontré des problèmes étranges lors du développement ? Bienvenue pour laisser un message et partager.

Pour plus d'articles techniques liés à MySQL, veuillez visiter la colonne

Tutoriel MySQL pour apprendre !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!