J'ai essayé d'utiliser mais cela m'a donné la commande avant , je le divisons en 2 requêtes pour vous assurer qu'il peut renvoyer le bon ordre en utilisant la clause plutôt que Cependant, je ne peux pas Utilisez Si j'utilise 2019-06-14 dans la commande décroissante d'abord, égale ou ultérieure que 2019-06-14 en ordre croissant après cela. Comme limite start_limit, items_per_page lorsque je dois énumérer les résultats dans de nombreuses pages car ils ont leur propre nombre de lignes. Union à Combinez les résultats, la commande sera à nouveau incorrecte. Par conséquent, si je peux utiliser une première requête et que cela peut renvoyer le bon ordre, ce sera génial!
3 Réponses :
Vous pouvez utiliser cette requête:
SELECT *
FROM activity
ORDER BY activity_date >= '2019-06-14' DESC,
CASE WHEN activity_date >= '2019-06-14' THEN activity_date END ASC,
CASE WHEN activity_date < '2019-06-14' THEN activity_date END DESC
En réalité, il n'y a rien de mal à votre technique, c'est purement que votre premier cas lorsqu'il ne produisait rien lorsque la date est inférieure au 14e, de sorte qu'elle génère NULL, et NULL se classe plus bas qu'une valeur pour tous. Trier vers le début Lorsque la date est inférieure au 14ème:
P>
merci à Nick pour le dbfiddle qui a permis que le tir em> p> Pour trier ces lignes liées sur Null MySQL examinera ensuite la deuxième clause de l'ordreby et vous vous retrouvez. Avec toutes vos dates de pré-14ème avant que la poche 14ème p> Le moyen le plus simple de régler cela serait de mettre une date élevée en tant que autre pour le premier cas lorsque: P> SELECT *
FROM `activity`
ORDER BY
CASE
WHEN activityrating = 'gold' THEN -1
WHEN `activity_date` >= '2019-06-14' THEN 0
ELSE 1
END,
...
Travaillé comme un charme! Merci beaucoup!
Voici une méthode beaucoup plus concise d'écrire la clause par : Le premier niveau de tri place des enregistrements sur ou après A plus Solution générale qui fonctionnerait sur n'importe quelle base de données (enregistrer 2019-06 -14 Premièrement, suivi des enregistrements précédents de seconde. Ensuite, dans chacun de ces deux groupes, nous trions ascendant pour les enregistrements ultérieurs et décrivant les enregistrements précédents. 
datrodiff , qui est spécifique à MySQL):
C'est bon, mais les futurs visiteurs prennent note que ce n'est pas totalement portable pour les autres fournisseurs qui ne permettent pas aux booléens d'être traités comme des valeurs autonomes. SQLServer et Oracle n'accepteraient pas cela, bien que Postgres
@CAIUSJARD Les expressions booléennes peuvent facilement être converties en expressions , et il laisserait toujours une solution de tri de deux niveaux, sur n'importe quelle base de données.
Vrai, mais la réponse nécessite davantage de travail pour l'adapter à d'autres fournisseurs et utilise des fonctions propriétaires - je remarquais simplement cela, ce n'était pas conçu comme une critique de ce qui est une technique intelligente. Il peut également être intéressant de noter qu'il est potentiellement légèrement plus difficile de comprendre / moins de documenter, et a bénéficié de votre explication de soutien
Je suis en désaccord et la réponse acceptée, qui a trois niveaux de tri, est en fait un peu difficile à comprendre.
La réponse acceptée a un tri de deux niveau, est plus proche de SQL standard et peut être comprise en le lisant. Il ne s'appuie pas sur un développeur sachant ou se souvenant de savoir si le vrai trie d'avance sur des cartes fausses / vraies à 0, de fausses cartes à 1 (ou est-ce l'inverse? Ou fait une fausse carte à -1?) Et cela ne nécessite qu'un Date simple (probablement probablement numérique) GT / LT Comparaison plutôt qu'un daturant potentiellement plus coûteux. Je souhaite la bienvenue à votre édition
Pouvez-vous inclure l'exemple de sortie comme vous voulez le voir?
Exemple de sortie ajoutée.
J'ai tenté une réponse ci-dessous si vous êtes intéressé.