Utiliser la clé primaire sensible aux accents dans MySQL

Collations . Vous avez deux choix, pas trois :

utf8_bin traite tout cela comme différent :demandé et demande et Demandé .

utf8_..._ci (typiquement utf8_general_ci ou utf8_unicode_ci ) traite tout cela comme le même :demandé et demande et Demandé .

Si vous ne voulez que la sensibilité à la casse (demandé =demande , mais aucun ne correspond à Demandé ), vous n'avez pas de chance.

Si vous souhaitez uniquement la sensibilité aux accents (demandé =Demandé , mais aucun ne correspond à demande ), vous n'avez pas de chance.

Déclaration . La meilleure façon de faire ce que vous choisissez :

CREATE TABLE (
    name VARCHAR(...)  CHARACTER SET utf8  COLLATE utf8_...  NOT NULL,
    ...
    PRIMARY KEY(name)
)

Ne modifiez pas le classement à la volée . Cela n'utilisera pas l'index (c'est-à-dire qu'il sera lent) si le classement est différent dans name :

WHERE name = ... COLLATE ...

BINAIRE . Les types de données BINARY , VARBINARY et BLOB ressemblent beaucoup à CHAR , VARCHAR , et TEXT avec COLLATE ..._bin . La seule différence est peut-être que le texte sera vérifié pour un stockage utf8 valide dans un VARCHAR ... COLLATE ..._bin , mais il ne sera pas vérifié lors du stockage dans VARBINARY... . Comparaisons (WHERE , ORDER BY , etc.) seront les mêmes ; c'est-à-dire, comparez simplement les morceaux, ne faites pas de pliage de cas ou de décapage d'accent, etc.