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. >

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

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

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é

BINARY

BINARY

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

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

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

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.

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!