Y a-t-il un moyen facile de commander des résultats MySQL respectivement par où pour revenir et aussi pour revenir < / p> mise à jour: Pour être plus précis, je veux éviter de altérer les données entre parenthèses dans ID in (...) Clause?
Exemple: où les articles.Ind in (4, 2, 5, 9, 3 ) , puisque ces identifiants sont dynamiques et commandés automatiquement.
4 Réponses :
Je ne pense pas que vous puissiez faire cela. Il n'y a pas de commande "explicite" en cours; La déclaration "dans" vous indique simplement quoi de récupération et n'a aucune information sur la commande.
Étant donné que les exemples que vous avez donnés n'ont aucun ordre évident, votre meilleur pari est de gérer cela en code une fois le résultat renvoyé.
MySQL ne tricote que avec la commande par. C'est pourquoi il n'est pas terriblement rare que les tables de base de données ont quelque chose comme une colonne d'ordonnance.
articles +----+------------+-------+ | id | ordinality | (...) | +----+------------+-------+ | 2 | 2 | '' | | 3 | 5 | '' | | 4 | 1 | '' | | 5 | 3 | '' | | 9 | 4 | '' | +----+------------+-------+ SELECT * FROM articles WHERE articles.id IN (4, 2, 5, 9, 3) ORDER BY articles.ordinality
Ouais, type de: mais ceci est non standard SQL et sent un peu.
+1 pour la solution pragmatique. Et pour la partie "odeur un peu". ;)
Cela fonctionne pour moi: Ordre par champ (produit.Id, 4,9,8,5,3,11,24,16)
Cela fonctionne à la fois et est en fait plus rapide que la réponse acceptée, sur ma machine de toute façon. J'ai testé avec 1000 enregistrements et wind_in_set a pris 0,03 seconde et champ a pris 0,02 seconde. Je suppose que cette différence deviendrait plus marquée avec des ensembles plus importants. J'ai également testé avec une clause "limite 2" et Find_in_set a effectivement pris plus de temps, 0,04 sec, tandis que champ a toujours pris 0,02 seconde. Personnellement, je pense que 0.02sec est toujours assez lent. L'OP devrait faire attention à ne pas réussir dans de grands ensembles de données ou il faudra une performance touchée!