Récupérer les 20 enregistrements les plus récents

Bonjour à tous je cherche à récuperer dans une BDD les 20 enregistrements les plus récents et je me demande si la requête suivante va faire ce que j'attend ou juste me retourner les 20 premiers enregistrement trouvés dans la BDD et me les retourner classés par ordre de date ??

Code:

---

1 2	$query_rsAffich="SELECT date, titre_small, titre_small_gb, text_small, text_small_gb FROM news ORDER BY date DESC LIMIT 20";

---

Je pense que cela va me retourner les 20 premiers enregistrement trouvés dans la BDD et me les retourner classés par ordre de date mais je n'en suis pas sûr...

Si c'est le cas, quelqu'un peut-il m'indiquer la bonne requête pour arriver à mes fins ?

Merci d'avance pour vos réponses :D

Tu aurais pu le tester toi même mais le LIMIT s'applique bien après le ORDER BY.

(enfin pour être précis, mysql trie jusqu'à avoir trouvé le nombre d'élements demandés)

Merci de ta réponse Sabotage,

En fait le site est en cours de création et la BDD ne contient pas encore suffisamment d'enregistrements pour faire le test, c'est pourquoi je me suis permis de poser la question ;)

Merci encore pour ta réponse et bonne journée à tous :D

Citation:

---

Envoyé par Alexdezark

la BDD ne contient pas encore suffisamment d'enregistrements pour faire le test

---

remplire moins de 20 (puisque visiblement il y en a quelques uns) enregistrement en mettant test1, test2 etc...et les supprimer apres est si difficile ?
ca t'aurais eviter de perdre du temps a poster :?

Citation:

---

Envoyé par sabotage

(enfin pour être précis, mysql trie jusqu'à avoir trouvé le nombre d'élements demandés)

---

Pas tout à fait non.

Le LIMIT est comme un masque qui s'applique en dernier, lorsque la requête à était exécutée.

J'ai une table de communes avec environs 37000 lignes.
Avec un :

Code:

---

SELECT * FROM communes ORDER BY nom LIMIT 10

---

La requête retourne bien 10 lignes.
Mais lorsqu'on regarde le plan d'exécution, MySQL est bien allé chercher toutes les lignes de la tables, et donc seulement après a "masqué" toutes les lignes sauf les 10 premières.

Citation:

---

Envoyé par Oishiiii

MySQL est bien allé chercher toutes les lignes de la tables, et donc seulement après a "masqué" toutes les lignes sauf les 10 premières.

---

8O ca veut dire que faire une limite de 10 sur 10 000 occurences n'optimise en rien la requete ?
plutot que de "recuperer" que 10 occurence, il en "masque" 9990 ?

Citation:

---

ca t'aurais eviter de perdre du temps a poster

---

En ce qui me concerne un Post sur ce forum n'est jamais une perte de temps...

Si cela fait perdre du temps aux autres, là en effet il faut me le dire pour éviter de le reproduire ;)

Mais cela permet d'avoir des remarques et l'expérience des autres.

Dans ce cas j'ai la réponse de Oishiiii qui m'interesse beaucoup :

Cela signifie que ce n'est pas un gain de temps d'execution de faire ce type de requête.

ce qui m'amène à demander : savez-vous s'il existe une façon de ne chercher que les 20 enregistrements les plus récents (champ date de type DATE) ou ceux dont le champ ID (auto-incrémenté) est le plus grand ?

Merci d'avance pour vos réponses

Moi, je vous dis ça, mais je ne suis pas expert MySQL, si d'ailleurs quelqu'un connaissant le sujet pouvait apporter des précision, ce serait intéressant, mais j'ai peur que l'on ne soit pas sur le bon forum.

Je constate simplement qu'en fait, MySQL va chercher toute les lignes qui serait retourner par la requête sans la clause LIMIT.
Une fois le travail terminer, il applique un genre de "masque" pour n'afficher que les lignes correspondant à la clause LIMIT.

Même sur une colonne indexée, la requête ne semble pas être optimisée.

Code:

---

SELECT * FROM communes ORDER BY nom LIMIT 10;

---

Code:

---

1 2 3

id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE communes index NULL nom 768 NULL 37385

---

Code:

---

SELECT * FROM communes ORDER BY id LIMIT 20000, 10

---

Code:

---

1 2	id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE communes index NULL PRIMARY 4 NULL 35653

---

Par contre logiquement :

Code:

---

SELECT * FROM communes WHERE id BETWEEN 20000 AND 20010

---

Code:

---

1 2	id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE communes range PRIMARY PRIMARY 4 NULL 11 Using where

---

Donc, j'en déduis que si l'on veux de meilleurs performances sur un gros tris, il faudrait ajouter une colonne à la table dédié au trie (mise à jour sur INSERT/DELETE/UPDATE), sur laquelle effectuer par exemple un BETWEEN utilisant l'index pour aller chercher les lignes voulues, ce que ne fait pas MySQL avec un "ORDER BY + LIMIT", non ?

En fait mysql lit l'intégralité de la base, et trie jusqu'a trouver les 20 demandés ; s'il ne lisait pas tout il ne pourrait evidemment pas trier.
Mais il ne trie pas l'intégralité pour n'en afficher ensuite que 20.

Citation:

---

Envoyé par sabotage

Mais il ne trie pas l'intégralité pour n'en afficher ensuite que 20.

---

C'est pourtant ce que me montre les plans d'exécutions, comment l'expliques-tu ?

A quoi fais-tu réference ?

Citation:

---

Envoyé par sabotage

A quoi fais-tu réference ?

---

A mon message plus haut (12h03).

Je pense que c'est un peu plus complexe que ça.
http://dev.mysql.com/doc/refman/5.0/...imization.html

Tout dépend en fait de beaucoup de paramètres.

Des experts mysql auraient sans doute la réponse, mais cela requiert je pense de très bonne connaissance du moteur interne de mysql.

Citation:

---

A mon message plus haut (12h03).

---

Il ne dit pas autre chose que ce que je dis : il faut considérer toutes les lignes pour pouvoir les classer.
De meme pour faire un MAX() il faudrait bien lire la totalité des lignes.

Oui, c'est donc en contradiction avec ce que vous avez écris plus haut :

Citation:

---

mysql trie jusqu'à avoir trouvé le nombre d'élements demandés

---

Citation:

---

Mais il ne trie pas l'intégralité pour n'en afficher ensuite que 20.

---

Bref.

Juste une petite question au passage :

Citation:

---

De meme pour faire un MAX() il faudrait bien lire la totalité des lignes.

---

Je n'y avait pas pensé mais un MAX() sur le champ auto-incrémenté de ma table avec un LIMIT 20 me sortirait bien les 20 dernières entrées de ma table ?

excusez moi si je m'immisce :oops:

non, erreur de ma part : MAX() récupère "La" valeur maximale d'une colonne...

Pas les 20 valeurs MAX :oops:

Citation:

---

Oui, c'est donc en contradiction avec ce que vous avez écris plus haut :

---

Ba non je dis toujours la meme chose, mysql ne trie que 20 lignes.
Tout ce qu'on peut dire des autres lignes c'est qu'elles sont inférieures (ou supérieures selon le sens de trie) aux 20 lignes classées mais elles n'auront pas été ordonnées entre elles.
D'un point de vue performance, la requete avec LIMIT n'est pas la requete simple dont on ne donnerait au final qu'une partie du résultat.

C'est en tout cas ce qui est dit dans la documentation.

Ah, d'accord.
Mais comment expliquer que d'après le plan d'execution de cette requête (cf. plus haut) :

Code:

---

SELECT * FROM communes ORDER BY nom LIMIT 10;

---

MySQL est bien allé chercher toutes les lignes de la table.

S'il arrive, je ne sait comment à trier ses 10 lignes, pourquoi continuer et aller chercher les autres?

Pour determiner quelles sont les 10 premieres lignes par nom, il doit lire le nom dans toutes les lignes ; enfin moi je ne vois pas comment il pourrait faire autrement sur un champ non indexé.

De toute facon le "rows" de EXPLAIN n'est pas le nombre de lignes réellement étudiées mais une estimation de ce qu'il faudrait.
Une requete simple avec un LIMIT et sans tri montre les limites de ce résultat.