Introduction : pourquoi le choix de la collation dans MySQL n'est pas un simple caprice d'esthète
\nQuiconque a déjà configuré une base de données pour un projet PHP s'est posé la question : « Quelle collation (comparaison/tri) choisir ? ». Sur Stack Overflow, cette question cumule des milliers de vues, et les réponses sèment souvent la confusion chez les débutants. À première vue, on pourrait penser qu'il n'y a pas de différence — du moment que ça fonctionne. Mais en réalité, le choix de la collation influence la vitesse de recherche, la pertinence du tri (notamment avec le français) et même l'affichage des caractères spéciaux.
\nDans ce tutoriel, nous allons déterminer quelle est la meilleure collation pour MySQL avec PHP en 2025, et pourquoi. Vous apprendrez à éviter les erreurs classiques et à configurer votre base de données pour que votre site soit rapide et vos données parfaitement affichées.
\n\nQu'est-ce qu'une collation en termes simples ?
\nUne collation (comparaison) est un ensemble de règles selon lesquelles MySQL compare et trie les chaînes de caractères. Elle est étroitement liée au jeu de caractères (charset). Si le charset (par exemple, utf8mb4) détermine comment les caractères sont stockés, la collation définit comment ils sont comparés : tenir compte de la casse, trier les lettres accentuées, considérer « A » et « a » comme identiques ou non.
Les principaux types de collation pour utf8mb4 :
- \n
- utf8mb4_general_ci — ancienne, rapide, mais avec un tri simplifié (ne gère pas toujours correctement certaines langues). \n
- utf8mb4_unicode_ci — plus précise, basée sur la norme Unicode, mais plus lente avant MySQL 8.0. \n
- utf8mb4_0900_ai_ci — la plus récente (MySQL 8.0+), à la fois la plus précise et la plus rapide. \n
Pourquoi éviter les anciennes collations ?
\nDe nombreux projets legacy utilisent encore utf8_general_ci ou même latin1_swedish_ci. Si vous démarrez un nouveau projet en PHP, fuyez-les comme la peste. Voici pourquoi :
- \n
- Problèmes avec le français : les lettres accentuées comme « é », « è », « ê » peuvent être mal triées. \n
- Jeu de caractères limité : les anciens encodages ne supportent pas les emojis ni les caractères rares. \n
- Performances : les collations modernes sont optimisées et plus rapides. \n
La meilleure collation en 2025 : utf8mb4_0900_ai_ci
\nSi votre MySQL est en version 8.0 ou supérieure (ce qui est le cas pour la plupart des utilisateurs), le meilleur choix est utf8mb4_0900_ai_ci. Décryptage :
\n- \n
- utf8mb4 — encodage supportant 4 octets par caractère (emojis, caractères rares). \n
- 0900 — basé sur la norme Unicode 9.0 (la version la plus récente). \n
- ai — accent insensitive (insensible aux accents : « café » et « cafe » sont considérés identiques). \n
- ci — case insensitive (insensible à la casse : « Hello » et « hello » sont identiques). \n
Cette collation offre une précision et une vitesse maximales. Si vous avez besoin de distinguer la casse ou les accents, utilisez utf8mb4_0900_as_cs, mais pour 99 % des projets web, ai_ci est l'idéal.
Et si j'ai MySQL 5.7 ou une version antérieure ?
\nDans ce cas, votre choix se porte sur utf8mb4_unicode_520_ci (ou simplement utf8mb4_unicode_ci). Elle n'est pas aussi rapide que la 0900, mais bien plus précise que general_ci. Si vous avez une version ancienne, mettez-la à jour dès que possible, mais en attendant, utilisez utf8mb4_unicode_ci.
Tutoriel pas à pas : configuration de la collation dans un projet PHP
\nConfigurons correctement votre base de données. Je vais utiliser PDO, la méthode moderne et sécurisée pour travailler avec MySQL en PHP.
\n\nÉtape 1. Créer une base de données avec la bonne collation
\nExécutez cette requête SQL (via phpMyAdmin ou la console) :
\nCREATE DATABASE my_database\n CHARACTER SET utf8mb4\n COLLATE utf8mb4_0900_ai_ci;\n\nÉtape 2. Configurer la connexion en PHP (PDO)
\nLors de la connexion à la base, assurez-vous de spécifier le charset dans le DSN :