N'importe quelle base de données SQL: quand est-il préférable de récupérer une table entière au lieu d'interroger des lignes particulières?

Question

J'ai une table qui contient peut-être 10k à 100k lignes et j'ai besoin de différents ensembles jusqu'à 1 ou 2 mille lignes, mais assez souvent beaucoup moins. Je veux que ces requêtes soient aussi vite que possible et je voudrais savoir quelle approche est généralement plus intelligent:

1. Toujours requête pour exactement les lignes dont j'ai besoin avec une clause WHERE qui est différent tout le temps.
2. Charger la table entière dans un cache en mémoire dans mon application et y effectuer une recherche, synchroniser le cache régulièrement
3. Toujours interroger toute la table (sans clause WHERE), laisser le serveur SQL gérer le cache (c'est toujours la même requête donc il peut mettre en cache le résultat) et filtrer la sortie au besoin

Je voudrais être agnostique d'un moteur de DB spécifique pour l'instant.

Answer 1

Je crois fermement l'option 1 devrait être préférée dans une situation initiale. Lorsque vous rencontrez des problèmes de performance, vous pouvez voir comment l'optimiser en utilisant la mise en cache. (L'optimisation pré est la racine de tout le mal, a dit une fois Dijkstra).

, rappelez-vous aussi que si vous choisissez l'option 3, vous enverrez la complète du table contenu sur le réseau ainsi. Cela a également un impact sur les performances.

Answer 2

Dans mon expérience, il est préférable d'interroger ce que vous voulez et laisser la figure de base de données sur la meilleure façon de le faire. Vous pouvez examiner le plan de requête pour voir si vous avez des goulets d'étranglement qui pourraient également être aidés par les index.

Answer 3

avec 10K à 100K lignes, le numéro 1 est le gagnant clair pour moi. Si c'était < 1K je pourrais dire garder en cache dans l'application, mais avec autant de lignes, laissez la DB faire ce pour quoi elle a été conçue. Avec les bons index, le numéro 1 serait le meilleur pari.

Si vous récupériez le même ensemble de données à chaque fois, la mise en cache des résultats pourrait être un meilleur pari, mais si vous devez toujours avoir un autre emplacement, il est préférable de laisser le DB en prend soin.

Comme je l'ai dit bien, assurez-vous indexez bien sur tous les champs appropriés.

Answer 4

Il me semble qu'un système conçu pour accélérer la recherche, le découpage et la découpe d'informations va être beaucoup plus rapide que le code moyen des développeurs. D'un autre côté, certains facteurs que vous ne mentionnez pas incluent l'emplacement ou l'emplacement potentiel du serveur de base de données par rapport à l'application - renvoyer de grands ensembles de données sur des réseaux plus lents ferait pencher la balance en faveur du recherche locale "option. Je pense que, dans le cas «général», je recommanderais d'interroger juste ce que vous voulez, mais que dans des circonstances spéciales, d'autres options pourraient être meilleures.

Answer 5

si vous faites ceci:

SELECT * FROM users; 

MySQL devrait deux requêtes: un pour les champs de la table et une autre pour ramener les données que vous avez demandé.

faire

SELECT id, email, password FROM users; 

MySQL n'accéder aux données depuis les champs sont explicites.À propos des limites: toujours ss mieux interroger la quantité de lignes dont vous aurez besoin, ni plus ni moins. plus de données signifie plus de temps pour conduire

Answer 6

La seule raison d'utiliser autre chose que l'option 1 est que si lui-même est énorme clause WHERE (à savoir si votre clause WHERE identifie chaque ligne individuellement, par exemple WHERE id = 3 or id = 4 or id = 32 or ...).

Answer 7

Tout d'abord, laissons tomber # 2. La recherche de tables est la raison d'être des serveurs de données, et ils feront presque certainement un meilleur travail que toute recherche ad hoc que vous préparez. Pour le n ° 3, vous dites simplement "filtrer la sortie si nécessaire" sans dire où ce filtre a été fait.Si c'est dans le code de l'application comme dans # 2, que, comme aveC# 2, que vous avez le même problème # 2.

les bases de données ont été créées spécifiquement pour gérer ce problème précis. Ils sont très bon. Laissez-les faire.

Answer 8

est quelque chose de changer d'autre vos données? le point de laisser le moteur SQL de façon optimale Il serait surprenant que vous travailliez avec une base de données et que vous n'ayez pas la possibilité que quelqu'un d'autre change les données.

Answer 9

confiance que le serveur SQL fera un meilleur travail à la fois la mise en cache et le filtrage que vous pouvez vous permettre de vous faire (à moins que des tests de performance montre le contraire.)

Notez que je l'ai dit « se permettre de faire » non seulement " faire". Vous pouvez très bien être en mesure de le faire mieux mais vous êtes payé (vraisemblablement) pour fournir des fonctionnalités qui ne sont pas mises en cache.

Posez-vous cette question ... Vous passez du temps à rédiger un code de gestion de cache pour vous aider à remplir votre cahier des charges?