Astuce MySQL : nombre de lignes retournées sans clause LIMIT

Une petite astuce que je viens de découvrir concernant MySQL. Imaginez que vous avez une requete de type SELECT qui est sensé vous retourner des centaines de lignes. Pour afficher ca correctement à l’utilisateur, vous souhaitez limiter le nombre de résultats retournés à 50 par exemple. Vous allez donc faire quelque chose comme __SELECT * FROM matable WHERE (…) LIMIT 0,50__ Pour les pages suivantes, la requete sera la même avec un __LIMIT 50,50__ puis __LIMIT 100,50__ etc. Le soucis, c’est pour savoir le nombre de pages possible justement. EN clair, combien MySQL aurait retourné de lignes sans la clause LIMIT. Jusqu’à maintenant, il fallait faire deux fois la requete (ou instaurer un break quand on bouclait sur les résultats). Quelle perte de temps (et de bande passante entre votre serveur web et votre serveur SQL, si vous ne voulez afficher que 10 lignes alors que le résultat en retourne un million) ! Il existe une astuce dans MySQL pour éviter de devoir refaire deux fois la requete (et donc économiser de précieuses secondes quand vous utilisez des jointures, et/ou cherchez dans une table immense).

Comment faire : Faites votre première requete en incluant l’option  » SQL_CALC_FOUND_ROWS » : mysql> SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name -> WHERE id > 100 LIMIT 10; Vous avez donc vos résultats pour votre première page. Pour récupérer le nombre de ligne total, executez ensuite : mysql> SELECT FOUND_ROWS(); Et voilà le travail 😉 Cette deuxieme requete sera pratiquement instantanée, puisque MySQL aura gardé la valeur de côté rien que pour vous 😉 Source : [|http://dev.mysql.com/doc/refman/4.1/en/information-functions.html#id3147821|en]  »Note: ceci ne marche qu’à partir de MySQL 4.1 »

2 réflexions sur « Astuce MySQL : nombre de lignes retournées sans clause LIMIT »

  1. Bon article, mais il faut faire attention parce que l’option SQL_CALC_FOUND_ROWS est une astuce à double tranchant. En premier lieu il peut y avoir des bugs si plusieurs requêtes sont effectuées et que FOUND_ROWS() est utilisé après la mauvaise requête. De plus, la requête qui sera la plus à exécuter est justement la requête utilisant SQL_CALC_FOUND_ROWS.

  2. L’article en question date un peu, et effectivement un complément d’information s’impose:
    – Le temps de génération de la requête avec SQL_CALC_FOUND_ROWS sera beaucoup plus long que sans l’option
    – Il faut suivre l’ordre des requêtes

    Aujourd’hui, pour mes clients, je décommanderais d’utiliser cette méthode.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.