¿Cuál es la mejor consulta: con una condición larga de "donde está" o muchas consultas pequeñas?

Question

Quizás es un poco tonto, pero no estoy seguro de qué es mejor. Si tengo que verificar más de 10k filas en db para existanse, ¿qué haría?

# 1 - una consulta

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

# 2 - muchas consultas

select id from table1 where name=smth1 

Aunque, del perfomance no es la meta, yo no quiero ir hacia abajo con MySQL tampoco;) Tal vez, cualquier otra solución será más adecuada ... Gracias.

upd: La tarea es obtener la lista de dominios, guardar nuevos (que aún no están en db) y eliminar los que desaparecieron de la lista. Espero que ayude un poco ...

Answer 1

Lo que debes hacer es crear una tabla temporal, insertar todos los nombres, y (usando una consulta) unir contra esta tabla para tu selección.

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

Answer 2

La única consulta probablemente tendrá un mejor rendimiento ya que la segunda dará muchos retrasos de ida y vuelta. Pero si tiene muchos nombres como en su ejemplo, el primer método puede hacer que alcance un límite interno.

En este caso, sería mejor almacenar la lista de nombres en una tabla temporal y unirnos a ella.

Answer 3

Según sus futuras necesidades para hacer cosas similares, es posible que desee agregar una función en la base de datos 'strlist_to_table'. Deje que la función tome un texto donde su entrada esté delimitada por un carácter delimitador (posiblemente también transferido a la función), divídalo en el delimitador para crear una tabla sobre la marcha. A continuación, puede utilizar

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

y también obtener protección contra la inyección de SQL (tal vez poco mesas Bobby aparece en la entrada).

Sólo mi 2 centavos ...

Answer 4

no estoy seguro de lo flexible que el diseño de su aplicación es, pero podría ser digno de mirar en la eliminación de la lista delimitada por completo y simplemente hacer una tercera tabla permanente para representar los muchos -to-many relationship, luego unir las tablas en cada consulta.