pour les tables avec 1.000.000 lignes et peut-être beaucoup plus!Paging efficace avec de grandes tables en SQL 2008
Je n'ai pas fait de benchmark moi-même donc je voulais obtenir l'avis des experts.
jeté un œil sur quelques articles sur row_number(), mais il semble avoir des répercussions sur la performance
Quels sont les autres choix/solutions de rechange?
Nous utilisons row_number() pour un excellent effet et il n'y a pas vraiment eu de problèmes de performance. La structure de base de nos requêtes paginés ressemble à ceci:
WITH result_set AS (
SELECT
ROW_NUMBER() OVER (ORDER BY <ordering>) AS [row_number],
x, y, z
FROM
table
WHERE
<search-clauses>
) SELECT
*
FROM
result_set
WHERE
[row_number] BETWEEN a AND b
Il fonctionne très bien pour nous sur les tables avec> 1.000.000 lignes.
Je comprends la performance est une fonction de serveur charge et ressources serveur entre autres, pls voir les deux liens dans mes commentaires ci-dessus pour un autre pov – Kumar
Comme je l'ai dit, nous utilisons réellement en production sur des tables avec 1.000.000 enregistrements. Les résultats reviennent en <100ms (selon les critères de recherche, bien sûr). Bien sûr, les performances dépendront de la charge du serveur et de votre scénario d'utilisation spécifique. –
Je suppose que vous avez suffisamment de RAM, de sorte que la table est entièrement mise en cache. Je viens d'essayer avec une simple table 'personne (email, prénom, nom)' contenant 3.000.000 d'enregistrements mais paginer pour durer des enregistrements cela prend 6 secondes avec la requête ci-dessus. J'utilise sql server 2008 r2. Ai-je manqué quelque chose. – broadband
cela vous dérangerait de partager les articles qui montrent row_number() ne fonctionne pas ... –
Toutes les requêtes sauf les plus triviales nécessitent des index et des statistiques à jour pour bien fonctionner. –
Dupliquer: http://stackoverflow.com/questions/1897436/row-number-over-not-fast-enough-with-large-result-set-any-good-solution –