Ускорение внутренних соединений между большим столом и маленьким столом

Это может быть глупый вопрос, но он может пролить свет на то, как объединения работают внутри.

Скажем, у меня есть большая таблица L и небольшая таблица S (100K строк против 100 строк).

Будет ли разница в скорости между двумя следующими вариантами?:

OPTION 1:                 OPTION 2:
---------                 ---------
SELECT *                  SELECT *
FROM L INNER JOIN S       FROM S INNER JOIN L
ON L.id = S.id;           ON L.id = S.id;

Обратите внимание, что единственная разница - это порядок, в котором эти таблицы объединены.

Я понимаю, что производительность может варьироваться в зависимости от разных языков SQL. Если да, то как MySQL сравнивается с Access?

Ответ 1

Нет, порядок не имеет значения.

Почти все РСУБД (такие MS Access, MySQL, SQL Server, ORACLE и т.д.) используют оптимизатор на основе затрат, основанный на статистике столбцов. В большинстве ситуаций оптимизатор выберет правильный план. В приведенном примере заказ не будет иметь значения (при условии, что статистика обновлена).

Чтобы решить, какую стратегию запроса использовать, оптимизатор Jet Engine использует статистика. Следующие факторы некоторые из факторов, которые статистика основана на:

Количество записей в таблице

Количество страниц данных в таблице

Расположение таблицы

Имеются ли индексы

Насколько уникальны индексы
Примечание. Вы не можете просматривать схемы оптимизации движка базы данных Jet, и вы не может указать, как оптимизировать запрос. Однако вы можете использовать Документ базы данных для определения имеются ли индексы и как уникальный индекс.

Основываясь на этих статистических данных, Затем оптимизатор выбирает лучшие стратегия внутреннего запроса для решения с конкретным запросом.

Статистика обновляется всякий раз, когда запрос скомпилирован. Запрос помечен для компиляции при сохранении любых изменения в запросе (или его основные таблицы), и когда база данных уплотнена. Если запрос помечены для компиляции, компиляция и происходит обновление статистики при следующем запуске запроса. Компиляция обычно берет с одного от секунды до четырех секунд.

Если вы добавите значительное количество записей в вашу базу данных, вы должны откройте, а затем сохраните свои запросы перекомпилируйте запросы. Например, если вы проектируете, а затем проверяете запрос используя небольшой набор выборочных данных, вы должен повторно скомпилировать запрос после дополнительные записи добавляются к база данных. Когда вы это сделаете, вы хотите чтобы обеспечить оптимальный запрос производительность достигается, когда приложение используется.

Ссылка.

Может показаться интересным: ACC: Как оптимизировать запросы в Microsoft Access 2.0, Microsoft Access 95 и Microsoft Access 97

Tony Toews Часто задаваемые вопросы по производительности Microsoft.

Ответ 2

Я знаю, что Oracle не в вашем списке, но я думаю, что большинство современных баз данных будут вести себя именно так.

В следующем плане выполнения вы можете видеть, что между этими двумя утверждениями нет разницы.

Это полный доступ к каждой из двух таблиц (без индекса в моем случае), а затем HASH JOIN. Поскольку вам нужно все, что угодно из обеих таблиц, обе таблицы должны быть прочитаны и объединены, последовательность не влияет.

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |   100 |   700 |    42  (12)| 00:00:01 |
|*  1 |  HASH JOIN         |      |   100 |   700 |    42  (12)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| S    |   100 |   300 |     2   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| L    |   100K|   390K|    38   (8)| 00:00:01 |
---------------------------------------------------------------------------