Tengo un buen número de sentencias SQL, como por ejemplo:En mysql o postgres, ¿hay un límite para el tamaño de una instrucción IN (1,2, n)?
SELECT foo FROM things WHERE user_id IN (1,2,3..n)
¿Existe un límite conocido con el número de elementos que de manera segura en forma en una cláusula IN así?
No hay límite técnico, pero hay una cierta clase de 'buen sentido' límite ..
tener demasiado elementos en la cláusula IN significa la consulta tiene probablemente un mal diseño (en mi humilde opinión)
No, pero tenga cuidado al usar la instrucción IN. Si utiliza una subconsulta en su instrucción IN, el rendimiento puede verse negativamente afectado porque SQL Server debe generar el conjunto de resultados completo y, esencialmente, construir internamente una declaración IF potencialmente grande.
Por ejemplo, algo así como Select * From MyTable where MyColumn IN (Select myColumn from AnotherTable) puede ser algo lento si la subconsulta devuelve una gran cantidad de filas. Muchas veces es más eficiente usar EXISTS.
Estoy bastante seguro de que Postgres tiene un límite de 1000 ... pero no puedo encontrar ningún docco que lo soporte.
Eso podría ser Oracle. –
El límite de 1000 en PostgreSQL no es un límite estricto, es un límite de optimización, es decir; después de 1000 PostgreSQL no lo maneja muy bien. Por supuesto, tengo que preguntar qué demonios estás haciendo con una cláusula IN de 1000 entradas.
Lo he usado, en consultas dinámicas creadas para postgres con sqlalchemy, con más de 25k parámetros. Además, se pasaron a las funciones de Python a través de parámetros posicionales (* args) ... pero no noté una desaceleración en mi caso. YMMV
Para MySQL, desde el manual:
El número de valores en la lista de IN sólo está limitado por el valor max_allowed_packet.
Casi siempre puede reemplazar IN con una declaración JOIN, a menos que tenga la lista de una fuente externa (no SQL). –
@sf: sí, totalmente de acuerdo. – Strae
y si la lista es externa, siempre puede insertarla en una tabla temporal y luego hacer una combinación, lo que tal vez después de crear algunos índices podría ser un buen plan – araqnid