Quel est le plus rapide? SELECT SQL_CALC_FOUND_ROWS FROM `table`, ou SELECT COUNT (*)

Lorsque vous limitez le nombre de lignes à renvoyer par une requête SQL, généralement utilisée dans la pagination, il existe deux méthodes pour déterminer le nombre total d'enregistrements:

Méthode 1

Incluez l' SQL_CALC_FOUND_ROWSoption dans l'original SELECT, puis obtenez le nombre total de lignes en exécutant SELECT FOUND_ROWS():

SELECT SQL_CALC_FOUND_ROWS * FROM table WHERE id > 100 LIMIT 10;
SELECT FOUND_ROWS();  

Méthode 2

Exécutez la requête normalement, puis obtenez le nombre total de lignes en exécutant SELECT COUNT(*)

SELECT * FROM table WHERE id > 100 LIMIT 10;
SELECT COUNT(*) FROM table WHERE id > 100;  

Quelle méthode est la meilleure / la plus rapide?

Ça dépend. Voir l'article du blog MySQL Performance sur ce sujet: http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

Juste un bref résumé: Peter dit que cela dépend de vos index et d'autres facteurs. De nombreux commentaires sur le post semblent indiquer que SQL_CALC_FOUND_ROWS est presque toujours plus lent - parfois jusqu'à 10 fois plus lent - que d'exécuter deux requêtes.

Lors du choix de la «meilleure» approche, une considération plus importante que la vitesse peut être la maintenabilité et l'exactitude de votre code. Si tel est le cas, SQL_CALC_FOUND_ROWS est préférable car vous n'avez besoin de gérer qu'une seule requête. L'utilisation d'une seule requête exclut complètement la possibilité d'une différence subtile entre les requêtes principale et count, ce qui peut conduire à un COUNT inexact.

MySQL a commencé à désapprouver les SQL_CALC_FOUND_ROWSfonctionnalités à partir de la version 8.0.17.

Par conséquent, il est toujours préférable d'envisager d'exécuter votre requête avec LIMIT, puis une deuxième requête avec COUNT(*)et sans LIMITpour déterminer s'il existe des lignes supplémentaires.

À partir de la documentation :

Le modificateur de requête SQL_CALC_FOUND_ROWS et la fonction FOUND_ROWS () qui l'accompagne sont obsolètes à partir de MySQL 8.0.17 et seront supprimés dans une future version de MySQL.

COUNT (*) est soumis à certaines optimisations. SQL_CALC_FOUND_ROWS entraîne la désactivation de certaines optimisations.

Utilisez plutôt ces requêtes:

SELECT * FROM tbl_name WHERE id > 100 LIMIT 10;
SELECT COUNT(*) WHERE id > 100;

En outre, il SQL_CALC_FOUND_ROWSa été observé avoir plus de problèmes en général, comme expliqué dans le MySQL WL # 12615 :

SQL_CALC_FOUND_ROWS a un certain nombre de problèmes. Tout d'abord, c'est lent. Souvent, il serait moins coûteux d'exécuter la requête avec LIMIT puis un SELECT COUNT ( ) séparé pour la même requête, car COUNT ( ) peut utiliser des optimisations qui ne peuvent pas être effectuées lors de la recherche de l'ensemble de résultats (par exemple, filesort peut être ignoré pour COUNT (*), alors qu'avec CALC_FOUND_ROWS, nous devons désactiver certaines optimisations de tri de fichiers pour garantir le bon résultat)

Plus important encore, sa sémantique est très floue dans un certain nombre de situations. En particulier, lorsqu'une requête a plusieurs blocs de requête (par exemple avec UNION), il n'y a tout simplement aucun moyen de calculer le nombre de lignes «aurait-il été» en même temps que de produire une requête valide. Au fur et à mesure que l'exécuteur de l'itérateur progresse vers ce type de requêtes, il est vraiment difficile d'essayer de conserver la même sémantique. De plus, s'il y a plusieurs LIMITs dans la requête (par exemple pour les tables dérivées), il n'est pas nécessairement clair à laquelle d'entre elles SQL_CALC_FOUND_ROWS doit se référer. Ainsi, de telles requêtes non triviales auront nécessairement une sémantique différente dans l'exécuteur de l'itérateur par rapport à ce qu'elles avaient auparavant.

Enfin, la plupart des cas d'utilisation où SQL_CALC_FOUND_ROWS semblerait utile devraient simplement être résolus par d'autres mécanismes que LIMIT / OFFSET. Par exemple, un annuaire téléphonique doit être paginé par lettre (à la fois en termes d'UX et en termes d'utilisation d'index), et non par numéro d'enregistrement. Les discussions sont de plus en plus organisées par défilement infini par date (permettant à nouveau l'utilisation de l'index), et non par pagination par numéro de poste. Etc.

Selon l'article suivant: https://www.percona.com/blog/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

Si vous avez un INDEX sur votre clause where (si id est indexé dans votre cas), il est préférable de ne pas utiliser SQL_CALC_FOUND_ROWS et d'utiliser 2 requêtes à la place, mais si vous n'avez pas d'index sur ce que vous avez mis dans votre clause where (id dans votre cas) alors utiliser SQL_CALC_FOUND_ROWS est plus efficace.

IMHO, la raison pour laquelle 2 requêtes

SELECT * FROM count_test WHERE b = 666 ORDER BY c LIMIT 5;
SELECT count(*) FROM count_test WHERE b = 666;

sont plus rapides que d'utiliser SQL_CALC_FOUND_ROWS

SELECT SQL_CALC_FOUND_ROWS * FROM count_test WHERE b = 555 ORDER BY c LIMIT 5;

doit être considéré comme un cas particulier.

Elle dépend en fait de la sélectivité de la clause WHERE par rapport à la sélectivité de la clause implicite équivalente à ORDER + LIMIT.

Comme Arvids l'a dit en commentaire ( http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-1174394 ), le fait que l'EXPLAIN utilise, ou non, une table temporelle, devrait être une bonne base pour savoir si SCFR sera plus rapide ou non.

Mais, comme je l'ai ajouté ( http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-8166482 ), le résultat dépend vraiment, vraiment du cas. Pour un paginateur particulier, vous pourriez arriver à la conclusion que «pour les 3 premières pages, utilisez 2 requêtes; pour les pages suivantes, utilisez un SCFR »!

Suppression de certains SQL inutiles, puis COUNT(*)sera plus rapide que SQL_CALC_FOUND_ROWS. Exemple:

SELECT Person.Id, Person.Name, Job.Description, Card.Number
FROM Person
JOIN Job ON Job.Id = Person.Job_Id
LEFT JOIN Card ON Card.Person_Id = Person.Id
WHERE Job.Name = 'WEB Developer'
ORDER BY Person.Name

Alors comptez sans partie inutile:

SELECT COUNT(*)
FROM Person
JOIN Job ON Job.Id = Person.Job_Id
WHERE Job.Name = 'WEB Developer'

Il existe d'autres options pour vous de comparer:

1.) Une fonction de fenêtre renverra directement la taille réelle (testée dans MariaDB):

SELECT 
  `mytable`.*,
  COUNT(*) OVER() AS `total_count`
FROM `mytable`
ORDER BY `mycol`
LIMIT 10, 20

2.) En sortant de la boîte, la plupart du temps, les utilisateurs n'ont pas besoin de connaître la taille EXACTE de la table, une approximation est souvent suffisante.

SELECT `TABLE_ROWS` AS `rows_approx`
FROM `INFORMATION_SCHEMA`.`TABLES`
WHERE `TABLE_SCHEMA` = DATABASE()
  AND `TABLE_TYPE` = "BASE TABLE"
  AND `TABLE_NAME` = ?