Comment trier les types varchar dans MySQL
mise à niveau asc
ordre décroissant desc
Dans MySQL, l'ordre par défaut ne peut trier que les nombres et les types de date, mais pour Le tri des types de caractères varchar semble inutile. Je vais maintenant vous présenter comment résoudre le problème de tri des types varchar.
J'ai découvert un problème intéressant aujourd'hui lors du tri de la table des numéros de téléphone nationaux. Je voulais que le champ isdcode soit trié de petit à grand, alors je l'ai écrit comme ceci
SELECT * FROM gb_country_isdcode ORDER BY isdcode asc
Copier après la connexion
Le résultat. est le suivant. J'ai trouvé que ce n'était pas le résultat que je voulais. Le tri asc était correct, j'ai donc cherché et cherché et recherché et j'ai finalement trouvé la raison
isdcode est pour le type varcher ; n'est évidemment pas possible d'utiliser asc directement pour le tri. Il doit être converti en type int et ensuite il peut être trié normalement tant que isdcode 0 suffit
Donc c'est écrit comme ça
<🎜. >
SELECT * FROM gb_country_isdcode ORDER BY (isdcode+0) asc
Copier après la connexion
Il semble que les données que vous souhaitez soient relativement volumineuses. . Mais pourquoi 0 est-il bien ? Il s'avère qu'après 0, le type INT est converti et trié. De cette façon, vous pouvez trier par taille.
Et s'il ne s'agit pas d'un numéro de téléphone mais d'un caractère chinois ? Il suffit d'effectuer une simple conversion pour trier les caractères chinois ?
Utilisez order by dans MySQL pour associer les champs qui stockent des informations chinoises. Les résultats par défaut ne sont pas triés dans l'ordre du pinyin chinois. Si vous souhaitez trier par le pinyin des caractères chinois, vous devez définir le caractère. ensemble de la base de données en UTF8, puis forcez la conversion des informations de champ en GBK lors du tri, afin que les résultats soient triés dans l'ordre piny. Par exemple :
SELECT * FROM table_name ORDER BY CONVERT(column_name USING gbk);
Copier après la connexion
Je l'ai essayé dans MySQL et le résultat a été très satisfaisant.
La conclusion est la suivante : lors de l'interrogation, encodez simplement les données interrogées en utilisant le jeu de caractères gb2312 via la fonction de conversion, puis utilisez le tri chinois après la conversion. Mais si vous modifiez réellement le jeu de caractères des champs de la table en gb2312, cela entraînera de nombreux problèmes d'encodage, tels que le transfert de valeurs sur la page et leur accès depuis la base de données, ce qui est très gênant. Tant que vous spécifiez le jeu de caractères lors de la requête, cela ne change pas vraiment le champ physique en gb2312, c'est très simple.
Ce qui précède est le contenu. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !