Вы должны найти все условия где и каждое соединение ... при условии. Два работают одинаково.
Предположим, мы пишем
select name
from customer
where customerid=37;
Каким-то образом СУБД должна найти запись или записи с customerid = 37. Если индекса нет, единственный способ сделать это - прочитать каждую запись в таблице, сравнивая значение Customerid с 37. Даже когда он находит его, он не может знать, что есть только один, поэтому он должен искать др.
Если вы создаете индекс для customerid, у СУБД есть способы очень быстрого поиска в индексе. Это не последовательный поиск, а, в зависимости от базы данных, бинарный поиск или другой эффективный метод. Точно, как не важно, примите, что это намного быстрее, чем последовательный. Затем индекс переносит его непосредственно в соответствующую запись или записи. Кроме того, если вы укажете, что индекс является «уникальным», то база данных знает, что он может быть только один, поэтому не тратит время на поиски секунды. (А СУБД не позволит вам добавить секунду.)
Теперь рассмотрим этот запрос:
select name
from customer
where city='Albany' and state='NY';
Теперь у нас есть два условия. Если у вас есть индекс только для одного из этих полей, СУБД будет использовать этот индекс для поиска подмножества записей, а затем последовательно искать их. Например, если у вас есть индекс состояния, СУБД быстро найдет первую запись для Нью-Йорка, затем последовательно выполнит поиск в поиске city = 'Albany' и прекратит поиск, когда достигнет последней записи для Нью-Йорка.
Если у вас есть индекс, который включает оба поля, т. Е. «Создать индекс по клиенту (штат, город)», то СУБД может немедленно увеличить нужные записи.
Если у вас есть два отдельных индекса, по одному на каждое поле, СУБД будет иметь различные правила, которые она применяет, чтобы решить, какой индекс использовать. Опять же, как именно это делается, зависит от конкретной СУБД, которую вы используете, но в основном она пытается вести статистику по общему количеству записей, количеству различных значений и распределению значений. Затем он будет последовательно искать те записи, которые удовлетворяют другому условию. В этом случае СУБД, вероятно, заметит, что городов гораздо больше, чем штатов, поэтому с помощью индекса города можно быстро увеличить записи «Олбани». Затем он будет последовательно искать их, проверяя состояние каждого по отношению к «NY». Если у вас есть записи для Олбани, Калифорния, они будут пропущены.
Каждое соединение требует своего рода поиска.
Скажем, мы пишем
select customer.name
from transaction
join customer on transaction.customerid=customer.customerid
where transaction.transactiondate='2010-07-04' and customer.type='Q';
Теперь СУБД должна решить, какую таблицу читать в первую очередь, выбрать соответствующие записи и затем найти соответствующие записи в другой таблице.
Если бы у вас был индекс для транзакций.transactiondate и customer.customerid, наилучшим планом, вероятно, было бы найти все транзакции с этой датой, а затем для каждой из них найти клиента с совпадающим параметром customerid, а затем убедиться, что клиент имеет правильный тип.
Если у вас нет индекса для customer.customerid, то СУБД может быстро найти транзакцию, но тогда для каждой транзакции ей придется последовательно искать таблицу клиентов в поисках подходящей таблицы привязок. (Это, вероятно, будет очень медленно.)
Предположим, что вместо этого у вас есть только индексы для транзакции.customerid и customer.type. Тогда СУБД, скорее всего, будет использовать совершенно другой план. Вероятно, он просканирует таблицу клиентов для всех клиентов с правильным типом, а затем для каждой из них найдет все транзакции для этого клиента и последовательно найдет для них правильную дату.
Самый важный ключ к оптимизации - выяснить, какие индексы действительно помогут, и создать эти индексы. Дополнительные неиспользуемые индексы являются обременительными для базы данных, поскольку для их обслуживания требуется работа, а если они никогда не используются, это напрасная трата усилий.
Вы можете указать, какие индексы СУБД будет использовать для любого запроса с помощью команды EXPLAIN.Я использую это все время, чтобы определить, хорошо ли оптимизируются мои запросы или мне нужно создавать дополнительные индексы.(Прочитайте документацию по этой команде для объяснения ее вывода.)
Предостережение: Помните, что я сказал, что СУБД ведет статистику по количеству записей и количеству различных значений и так далее в каждой таблице.EXPLAIN может дать вам сегодня совершенно другой план, чем вчера, если данные изменились.Например, если у вас есть запрос, который объединяет две таблицы, и одна из этих таблиц очень мала, а другая большая, она будет смещена к чтению маленькой таблицы, а затем к поиску совпадающих записей в большой таблице.Добавление записей в таблицу может изменить размер, который больше, и, следовательно, приведет к тому, что СУБД изменит свой план.Таким образом, вы должны попытаться сделать EXPLAINS для базы данных с реалистичными данными.Работа с тестовой базой данных с 5 записями в каждой таблице имеет гораздо меньшее значение, чем работа с действующей базой данных.
Что ж, можно сказать гораздо больше, но я не хочу писать здесь книгу.