Qu'est-ce qui est le mieux - requête avec un long 'where' ou beaucoup de petites requêtes?

Question

Peut-être que c'est un peu bête, mais je ne suis pas sûr de ce qui est mieux. Si je dois vérifier plus de 10k lignes en db pour existanse, ce que je ferais?

# 1 - une requête

select id from table1 where name in (smth1,smth2...{till 30k}) 

# 2 - de nombreuses requêtes

select id from table1 where name=smth1 

Bien que, perfomance est pas le but, je ne veux pas aller vers le bas avec MySQL soit;) Peut-être, toutes les autres solutions seront plus appropriées ... Merci.

màj: La tâche est de récupérer la liste des domaines, sauf nouvelle (qui ne sont pas encore db) et supprimer ceux qui dissappeared de la liste. L'espoir, ça va aider un peu ...

Answer 1

Ce que vous devez faire est de créer une table temporaire, insérez tous les noms, et (à l'aide d'une requête) se joignent contre cette table pour votre sélection.

select id 
from table1 t1 
inner join temptable tt on t1.name = tt.name 

Answer 2

La requête unique fonctionnera très probablement mieux car la seconde donnera beaucoup de délais aller-retour. Mais si vous avez beaucoup de noms comme dans votre exemple, la première méthode pourrait vous amener à atteindre une limite interne.

Dans ce cas, il peut être préférable de stocker la liste des noms dans une table temporaire et de s'y joindre.

Answer 3

En fonction de votre avenir a besoin de faire des choses semblables, vous pouvez ajouter une fonction dans la base de données « strlist_to_table ». Laissez la fonction prendre un texte où votre entrée est délimitée par un caractère délimiteur (éventuellement aussi passé à la fonction), divisez-le sur le délimiteur pour créer une table à la volée. Ensuite, vous pouvez utiliser

where in strlist_to_table('smth1|smth2', '|') 

et également obtenir une protection de l'injection sql (peut-être peu de Bobby Tables apparaît dans l'entrée).

Juste mes 2 cents ...

Answer 4

Je ne suis pas sûr la flexibilité de votre conception de l'application est, mais il pourrait être intéressant de regarder en retirer la liste complètement délimitée et faisant simplement une troisième table permanente pour représenter les nombreux -to-many relation, puis rejoignant les tables sur chaque requête.