Tienes que hacer una búsqueda para cada condición de dónde y para cada condición de unión... en. Los dos funcionan igual.
Supongamos que escribimos
select name
from customer
where customerid=37;
De alguna manera, el DBMS tiene que encontrar el registro o los registros con customerid=37. Si no hay un índice, la única forma de hacer esto es leer cada registro en la tabla comparando el ID de cliente con 37. Incluso cuando encuentra uno, no tiene forma de saber que solo hay uno, por lo que tiene que seguir buscando otros.
Si crea un índice en customerid, el DBMS tiene formas de buscar en el índice muy rápidamente. No es una búsqueda secuencial, sino, dependiendo de la base de datos, una búsqueda binaria o algún otro método eficiente. Exactamente cómo no importa, acepte que es mucho más rápido que secuencial. El índice luego lo lleva directamente al registro o registros apropiados. Además, si especifica que el índice es "único", entonces la base de datos sabe que solo puede haber uno, por lo que no pierde el tiempo buscando un segundo. (Y el DBMS le impedirá agregar un segundo).
Ahora considere esta consulta:
select name
from customer
where city='Albany' and state='NY';
Ahora tenemos dos condiciones. Si tiene un índice en solo uno de esos campos, el DBMS usará ese índice para encontrar un subconjunto de los registros y luego los buscará secuencialmente. Por ejemplo, si tiene un índice sobre el estado, el DBMS encontrará rápidamente el primer registro de NY, luego buscará secuencialmente city='Albany' y dejará de buscar cuando llegue al último registro de NY.
Si tiene un índice que incluye ambos campos, es decir, "crear índice en el cliente (estado, ciudad)", entonces el DBMS puede hacer zoom inmediatamente a los registros correctos.
Si tiene dos índices separados, uno en cada campo, el DBMS tendrá varias reglas que aplicará para decidir qué índice usar. Nuevamente, exactamente cómo se hace esto depende del DBMS particular que esté utilizando, pero básicamente trata de mantener estadísticas sobre el número total de registros, el número de valores diferentes y la distribución de valores. Luego buscará en esos registros secuencialmente los que cumplan con la otra condición. En este caso, el DBMS probablemente observaría que hay muchas más ciudades que estados, por lo que al usar el índice de ciudades puede acercarse rápidamente a los registros de 'Albany'. Luego los buscará secuencialmente, verificando el estado de cada uno contra 'NY'. Si tiene registros de Albany, California, estos se omitirán.
Cada combinación requiere algún tipo de búsqueda.
Digamos que escribimos
select customer.name
from transaction
join customer on transaction.customerid=customer.customerid
where transaction.transactiondate='2010-07-04' and customer.type='Q';
Ahora el DBMS tiene que decidir qué tabla leer primero, seleccionar los registros apropiados de allí y luego encontrar los registros coincidentes en la otra tabla.
Si tuviera un índice en transacción. fecha de transacción y cliente. ID de cliente, el mejor plan probablemente sería encontrar todas las transacciones con esta fecha, y luego, para cada una de ellas, encontrar el cliente con el ID de cliente coincidente y luego verificar que el cliente tiene el tipo correcto.
Si no tiene un índice en customer.customerid, entonces el DBMS podría encontrar rápidamente la transacción, pero luego para cada transacción tendría que buscar secuencialmente la tabla de clientes en busca de un customerid coincidente. (Esto probablemente sería muy lento).
Supongamos, en cambio, que los únicos índices que tiene están en transacciones.idcliente y tipo.cliente. Entonces el DBMS probablemente usaría un plan completamente diferente. Probablemente escanearía la tabla de clientes en busca de todos los clientes con el tipo correcto, luego, para cada uno de ellos, buscaría todas las transacciones para este cliente y buscaría secuencialmente la fecha correcta.
La clave más importante para la optimización es descubrir qué índices realmente ayudarán y crear esos índices. Los índices adicionales que no se usan son una carga para la base de datos porque se necesita trabajo para mantenerlos, y si nunca se usan, es un esfuerzo en vano.
Puede saber qué índices usará el DBMS para cualquier consulta dada con el comando EXPLAIN. Lo uso todo el tiempo para determinar si mis consultas se están optimizando bien o si debo crear índices adicionales. (Lea la documentación sobre este comando para obtener una explicación de su salida).
Advertencia:Recuerde que dije que el DBMS mantiene estadísticas sobre la cantidad de registros y la cantidad de valores diferentes, etc., en cada tabla. EXPLAIN puede darle hoy un plan completamente diferente al que le dio ayer si los datos han cambiado. Por ejemplo, si tiene una consulta que une dos tablas y una de estas tablas es muy pequeña mientras que la otra es grande, se inclinará hacia la lectura de la tabla pequeña primero y luego a la búsqueda de registros coincidentes en la tabla grande. Agregar registros a una tabla puede cambiar cuál es más grande y, por lo tanto, hacer que el DBMS cambie su plan. Por lo tanto, debe intentar hacer EXPLAINS en una base de datos con datos realistas. Ejecutar contra una base de datos de prueba con 5 registros en cada tabla tiene mucho menos valor que ejecutar contra una base de datos activa.
Bueno, hay mucho más que se podría decir, pero no quiero escribir un libro aquí.
