Le 30/01/17 à 14:55, Dominique Asselineau <[email protected]> a écrit : DA> Bonjour et merci de ces précisions. DA> DA> Le contexte serait un peu plus large que le français mais ça resterait DA> parmi les langues européennes. Dans ce cas utf8mb4_general_ci DA> serait-il toujours performant ?
Que veux-tu dire par performant ? Si tu parle de la rapidité d'une application qui utiliserait une base mysql, je doute que le changement de charset / collation soit perceptible. Donc réponse courte : - si c'est une appli web, prend le charset de tes pages web et du langage que tu utilises (utf8mb4_ est plus conforme à la norme, mais utf8_ reste un choix pertinent, et c'est facile de passer de l'un à l'autre). - La collation ne sert que pour les requêtes sql comme where truc = "aeiou" qui va sélectionner aussi du "ÀêïOù" avec une collation *_ci (avec du _cs je crois que "é"="e"), donc choisi _ci ou _cs ou _bin en fonction de ce qui t'arrange pour tes résultats de requêtes. Réponse détaillée : Certaines collations sont un peu plus rapides, mais c'est en général négligeable devant le reste (la lecture des données et les jointures). Attention quand même si tu utilises plusieurs langues, utf8_general_ci est plus "laxiste" que utf8_general_ci : n = ñ ß = s utf8_unicode_ci : n ≠ ñ ß = ss Et attention aux collations spécifiques à une langue, par ex avec une collation spanish "ll" est un caractère séparé entre l et n, donc "ll" > "lz" (ça parait très logique à un espagnol où ll a une entrée séparée dans le dictionnaire). Cf https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-sets.html Avec une collation plus stricte (comme le _bin ou les _cs), les index prennent un peu plus de place (plus d'entrées distinctes), mais c'est rarement un problème. Pour le charset, celui que tu choisis doit contenir tous les caractères que tu veux pouvoir stocker, mais à priori c'est le cas de tous les charset classiques pour les langues européennes (utf8_*, latin1_*, …), et il peut influer sur la taille occupée par les données (donc espace disque et dans une moindre mesure RAM occupée), mais ça changera pas grand choses sur la vitesse d'exécution d'une requête. Si tu veux vraiment économiser qq octets de disque et de RAM, le charset le plus économique sera probablement latin1_general_ci, c'est pour ça que plein de gens continuent de l'utiliser (aussi parce qu'ils n'ont jamais migré n'en éprouvant pas le besoin) sur des systèmes pourtant en utf8. Mais utiliser du mysql latin1 sur un OS utf8 oblige à préciser le charset lors de la connexion à la base (pas mal de client vont le préciser d'office à la connexion), et depuis une appli web ça peut être pénible (suivant que le charset de la page les post sont utf8 ou pas, et il faudra décoder / encoder en entrée et sortie de la base suivant le charset de connexion, sinon tu te retrouveras avec des trucs comme é sur tes pages web ou dans la base ou les deux). C'est pour ça que c'est quand même plus simple d'avoir tout en utf8, qui est l'encodage par défaut de pas mal de langages (et par ex le seul pour échanger des données en json). Donc utf8mb4_general_c(i ou s) est probablement le meilleur choix pour la pérennité, utf8_general_c(i|s) reste efficace avec une appli web utf8 et latin1_general_c(i|s) avec une appli web iso8859 (charset des pages html en latin1), et _bin si tu veux des comparaisons strictes (ou si les μs économisées sont importantes). -- Daniel Un jour Dieu me dit « cette chemise va t'aller » et "oh my Gad, Elmaleh"
