Tiene que hacer una búsqueda de todas las condiciones y para cada unión ... con la condición. Los dos funcionan igual.
Supongamos que escribir
select name
from customer
where customerid=37;
De alguna manera el DBMS tiene que encontrar el registro o registros con idcliente = 37. Si no hay un índice, la única forma de hacerlo es leer cada registro de la tabla que compare el ID de cliente con 37. Incluso cuando encuentra uno, no tiene forma de saber que solo hay uno, por lo que debe seguir buscando otros.
Si crea un índice en customerid, el DBMS tiene formas de buscar el índice muy rápidamente. No es una búsqueda secuencial, sino que, según la base de datos, una búsqueda binaria u otro método eficiente. Exactamente lo que no importa, acepta que es mucho más rápido que secuencial. El índice lo lleva directamente al registro o registros apropiados. Además, si especifica que el índice es "único", la base de datos sabe que solo puede haber uno, por lo que no pierde el tiempo buscando un segundo. (Y el DBMS evitará que la adición de un segundo.)
ahora esto 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 buscar un subconjunto de los registros, luego los buscará secuencialmente.Por ejemplo, si tiene un índice en estado, el DBMS encontrará rápidamente el primer registro para NY, luego buscará en forma secuencial city = 'Albany', y dejará de buscar cuando llegue al último registro para NY.
Si tiene un índice que incluye ambos campos, es decir "crear índice en el cliente (estado, ciudad)", entonces el DBMS puede acercar de inmediato a los registros correctos.
Si tiene dos índices separados, uno en cada campo, el DBMS tendrá varias reglas que aplica para decidir qué índice usar. Nuevamente, exactamente cómo se hace esto depende del DBMS particular que esté usando, 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á esos registros secuencialmente para aquellos que satisfacen 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 la ciudad puede acercarse rápidamente a los registros de 'Albany'. Luego los buscará secuencialmente, verificando el estado de cada uno contra 'NY'. Si tiene registros para Albany, California, se omitirán.
Cada unió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 a leer en primer lugar, seleccionar los registros apropiados de allí, y luego encontrar los registros coincidentes en la otra tabla.
Si tiene un índice en transaction.transactiondate y customer.customerid, es probable que el mejor plan sea encontrar todas las transacciones con esta fecha, y luego, para cada una de ellas, encontrar al cliente con la identificación del cliente correspondiente, 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 del cliente buscando un customerid coincidente. (Esto probablemente sea muy lento.)
Supongamos, en cambio, que los únicos índices que tiene están en transaction.customerid y customer.type. Entonces, el DBMS probablemente usaría un plan completamente diferente. Probablemente escanear la tabla de clientes para todos los clientes con el tipo correcto, luego para cada uno de estos encontrar todas las transacciones para este cliente, y buscarlas secuencialmente para la fecha correcta.
La clave más importante para la optimización es averiguar qué índices realmente ayudarán y crear esos índices. Los índices extra no utilizados son una carga para la base de datos porque requiere mantenimiento para mantenerlos, y si nunca se utilizan, se trata de un esfuerzo desperdiciado.
Puede decir qué índices usará el DBMS para cualquier consulta dada con el comando EXPLAIN. Utilizo esto todo el tiempo para determinar si mis consultas están siendo optimizadas o si debería crear índices adicionales. (Lea la documentación de este comando para obtener una explicación de su resultado).
Advertencia: Recuerde que dije que el DBMS guarda estadísticas sobre el número de registros y el número de valores diferentes, y así sucesivamente en cada tabla. EXPLAIN puede darle un plan completamente diferente hoy de lo que dio ayer si los datos han cambiado. Por ejemplo, si tiene una consulta que une dos tablas y una de ellas es muy pequeña, mientras que la otra es grande, estará sesgada hacia la lectura de la tabla pequeña primero y luego hacia 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, llevar al DBMS a cambiar su plan. Por lo tanto, debe intentar hacer EXPLICACIONES contra una base de datos con datos realistas. Correr contra una base de datos de prueba con 5 registros en cada tabla es de mucho menos valor que correr contra una base de datos en vivo.
Bueno, hay mucho más que decir, pero no quiero escribir un libro aquí.
Wow, mucha información, gracias, he aprendido un par de cosas al leer esto que puedo usar de inmediato – walnutmon