J'ai une grande table (60+) des millions d'enregistrements.
J'utilise un script php pour naviguer dans cette table. p>
Script php (avec pagination) Charge très vite car:
Le moteur de table est innodb, donc Mais la question est de quoi faire avec la pagination pour les résultats de recherche? P> Jusqu'à présent, je le fais avec 2 Étapes: P> 1. P> Compte () code> est très lent et
mysql_num_rows () code> n'est pas une option, donc je garde le nombre total de lignes ( Le nombre que j'utilise pour générer une pagination) dans une table séparée (je mettez à jour cet enregistrement
total_rows = total_rows-1 code> et
total_rows = total_rows1 + 1 code> pendant
Supprimer code> et
insérer code>). p>
$condition = " fname='rinchik' ";
$result = "SELECT * FROM my_large_table WHERE" . $condition;
$result_count = mysql_num_rows($result);
3 Réponses :
Utilisez le nombre (ID). Il ne renvoie que le nombre de comptes, avec et enfin, n'utilisez pas MySQL_ * Fonctions. P>
Alternatives suggérées p>
L'utilisation de cette extension est découragée. Au lieu de cela, le mysqli ou pdo_mysql
L'extension doit être utilisée. Voir aussi MySQL: choisir un guide API et
FAQ associé pour plus d'informations. Alternatives à cette fonction
Inclure: p>
MYSQLI_STMT_NUM_ROWS () PDOSTUMENT :: Rowcount () P>
blockQuote> mysql_num_rows ($ résultat); code> PHP récupère toutes les données de la MySQL et comptez le nombre de résultats trouvés. P>
Eh bien puis appliquez ceci à mysqli_num_rows
Utiliser Lorsque vous portez Lorsque vous utilisez pense à cela comme les pseudo scénarios suivants: p>
Hey Bob, combien de personnes sont dans la salle de classe? P>
blockQuote>
Hey Bob, envoyez toutes les personnes de la classe à moi, ... je les compterai pour obtenir le nombre de personnes moi-même p>
blockQuote>
en résumé, lors de l'utilisation de comptez code>, à l'interne, le serveur traitera la demande différemment. p>
comptent code>, le serveur n'alloit que la mémoire pour stocker le résultat du nombre de comptes. P>
mysql_num_rows code>, le serveur traitera l'ensemble du jeu de résultats, allouer la mémoire pour tous ces résultats et mettre le serveur en mode de récupération, ce qui implique de nombreux détails différents, tels que le verrouillage. p>
SELECT compte (*) code> strong> p> p>
mysql_num_rows code> strong> p>
mysql_num_rows code> Vous transférez tous les enregistrements au client et que le client devra calculer le compte lui-même. P>
Et si malade obtenir une rangée de 1 m dans un résultat? La mémoire n'est pas un problème. La question est ce qui serait plus rapide?
Maintenant, à propos de ma question: Bob m'a déjà donné la liste de toutes les personnes. Devrais-je demander à Bob combien de personnes dans la salle de classe? Ou devrais-je utiliser la liste qu'il m'a donné et comptez-moi?
Si vous avez déjà les données, alors faire un NUM_ROWS serait la chose plus rapide à faire (car vous ne faites pas une autre requête), mais vous avez dit que vous utilisez la pagination, alors les numéros numériques seraient une limite du résultat de la pagaie Set, pas le total?
J'ai eu quelques résultats de la DB. J'ai 10 résultats par page. Donc, j'ai besoin de compter la quantité totale de pages (compte (résultats) / 10) et générer des liens de navigation. Puisque j'ai déjà des données de DB, je vous demande si je devrais utiliser ($ ($ query_again) / 10) de (mysql_num_rows (résultats) / 10)
La façon dont je le ferais, il a deux questions. Première requête pour obtenir le nombre total, puis le 2e pour obtenir les données paginées à l'aide de limite x décalage y code>.
Testé dans Le inodb code> moteur et mysql 5.5.
ID code> est index et je pense que c'est très rapide p>
$q = "SELECT count(`id`) FROM table where 1";
$rows = mysql_query($q);
$count = mysql_fetch_array($rows);
echo $count[0];
En règle générale, moins vous appuyez sur la base de données, plus votre code sera plus rapide.
Plutôt que
compteur (id) code> (qui nécessite MySQL d'inspecter si l'identifiant code> code> de chaque enregistrement est
null code> et doit donc être exclu du compte). , vous devez utiliser
compter (*) code>.
@eggyal ID n'est jamais nul. Je ne suis pas sûr du processus d'inspection, mais je pense que son seul cas si vous définissez "Autoriser null" pour la colonne.
@Rinchik: C'est la sémantique de
compteur (expr, ...) code> vs
compte (*) code>.
@Antonsoradoi qui est une règle générale que je suis au courant. Il y a toujours des exceptions près.