EXISTS / IN / NOT EXISTS (subconsulta)

Oracle

-- Customers with orders (EXISTS)
SELECT name FROM customer m
WHERE EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

-- List membership with IN
SELECT name FROM customer
WHERE city IN ('Ankara', 'Izmir');

-- Customers with no orders at all (NOT EXISTS)
SELECT name FROM customer m
WHERE NOT EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

EXISTS comprueba si una subconsulta correlacionada devuelve al menos una fila (se detiene en la primera coincidencia, por lo que es rápido). IN comprueba si un valor está en una lista/resultado de subconsulta. Atención: si la subconsulta puede producir NULL, NOT IN da resultados inesperados; NOT EXISTS es más seguro. El optimizador de Oracle a menudo convierte ambos en el mismo plan.

PostgreSQL

SELECT name FROM customer m
WHERE EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

SELECT name FROM customer
WHERE city IN (SELECT city FROM target_cities);

SELECT name FROM customer m
WHERE NOT EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

PostgreSQL admite plenamente EXISTS/IN/NOT EXISTS. Con NOT IN, si la subconsulta contiene NULL todo el resultado puede quedar vacío, por lo que se recomienda NOT EXISTS o LEFT JOIN ... IS NULL. El planificador trata IN y EXISTS de forma equivalente como un semi-join en la mayoría de los casos.

MySQL

SELECT name FROM customer m
WHERE EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

SELECT name FROM customer
WHERE city IN ('Ankara', 'Izmir');

SELECT name FROM customer m
WHERE NOT EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

MySQL/MariaDB admiten EXISTS/IN/NOT EXISTS. Antes de MySQL 5.6 las subconsultas correlacionadas podían ser lentas; 5.6+ aceleró las subconsultas IN con las optimizaciones semi-join y materialization. La trampa de NOT IN + NULL también se aplica aquí.

SQL Server

SELECT name FROM customer m
WHERE EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

SELECT name FROM customer
WHERE city IN (SELECT city FROM target_cities);

SELECT name FROM customer m
WHERE NOT EXISTS (SELECT 1 FROM orders s WHERE s.customer_id = m.id);

SQL Server admite EXISTS/IN/NOT EXISTS, y el optimizador los procesa mayoritariamente como semi/anti-joins. Si una subconsulta NOT IN contiene NULL, el resultado puede quedar vacío de forma inesperada; NOT EXISTS es la opción segura. INTERSECT/EXCEPT también pueden usarse para una lógica de pertenencia similar.

MongoDB

// IN equivalent: the $in operator
db.customer.find({ city: { $in: ["Ankara", "Izmir"] } })

// EXISTS equivalent: match check with $lookup + $match
db.customer.aggregate([
  { $lookup: { from: "orders", localField: "id",
      foreignField: "customer_id", as: "s" } },
  { $match: { "s.0": { $exists: true } } }  // at least one order
])

En MongoDB, la pertenencia a una lista de valores se hace con los operadores $in / $nin. El equivalente de un EXISTS con subconsulta es obtener con $lookup el array de documentos coincidentes y filtrar según si el array está vacío. Comprobar la existencia de un campo es un operador aparte, { field: { $exists: true } } (la presencia de un campo, no una relación entre filas).

Redis

# Membership check with Set/Hash:
SISMEMBER target_cities "Ankara"   # is it in the set? (IN-like)
EXISTS customer:1                 # does the key exist?

Redis no tiene subconsultas. Para la pertenencia de valores, use SISMEMBER sobre un Set (similar a IN). El comando EXISTS no es una subconsulta; devuelve si la clave indicada existe. Las comprobaciones de existencia relacionales se hacen en la aplicación leyendo varias claves.

Elasticsearch

# IN equivalent: terms query
GET customer/_search
{ "query": { "terms": { "city": ["Ankara", "Izmir"] } } }

# Field existence: exists query
GET customer/_search
{ "query": { "exists": { "field": "phone" } } }

En Elasticsearch, el equivalente de IN es la consulta 'terms' (coincide con uno de varios valores), y NOT IN es terms dentro de bool must_not. La consulta 'exists' no corresponde a EXISTS de SQL; comprueba si un campo tiene valor en el documento. Un EXISTS correlacionado entre tablas suele requerir desnormalización.