JET SQL Performance/SQL Understanding

Question

Это не проблема, на которую нужно ответить, и больше вопрос о том, почему это происходит.

У меня есть поле в одной таблице, которая заполняется «Y» или «N», и у меня есть запрос, который просто принимает значение этого поля и всплывает в другую таблицу

Таблица имеет около 25000 записи в ней

запрос ниже занимает около 25 секунд, чтобы запустить

UPDATE ObjectivesApproved 
     INNER JOIN Approved 
      ON ObjectivesApproved.ID = Approved.ID 
    SET ObjectivesApproved.Football = [Approved].[Cri Football Related]; 

Удаление операции JOIN делает запрос еще дольше.

Если же я сделать ниже, вся операция занимает менее 5 секунд, даже если он выполняет 2 запросов

UPDATE ObjectivesApproved 
     INNER JOIN Approved 
      ON ObjectivesApproved.ID = Approved.ID 
    SET ObjectivesApproved.Football = 'Y' 
WHERE (([Approved].[Cri Football Related]='Y')); 

UPDATE Approved 
     INNER JOIN ObjectivesApproved 
      ON Approved.ID = ObjectivesApproved.ID 
    SET ObjectivesApproved.Football = 'N' 
WHERE (([ObjectivesApproved].[Football] Is Null)); 

Я доволен своим обходного, даже если это немного безвкусный, но для дальнейшего понимания SQL, почему это может произойти?

Answer 1

Ваша первая версия обновляет строки 25K, несмотря ни на что, но она должна поддерживать синхронизацию таблиц, поскольку она использует значения от одного к другому на по строкам. Каждая обновленная строка должна считывать из поля - 25 тыс. Раз.

Ваша вторая версия (оба утверждения) фильтрует данные вместо сравнения строк за строкой. Внутренний набор записей найден, а затем обновляется в пакете вместо вычисления строки за строкой. Значение «Y» не нужно искать каждый раз - оно постоянно.

Представьте, если бы я попросил вас покрасить 25-килограммовые коробки черного или белого цвета на основе списка, который я вам дал. Быстрее забрать первый ящик, проверить список и покрасить его, забрать второй блок, проверить список, покрасить его, повторить. Или быстрее вытащить все из них, которые должны быть белыми и покрасить их, затем все черные и покрасить их. Обратите внимание, что вам нужно только «проверить список» 2 раза во втором случае, но в 25K раз больше первого.

Answer 2

Я положил их в комментариях, но понимаю, что они представляют собой что-то ответ:

Вы говорите, что нет индексов, но говорят, что поля ID являются PKs. Если это так, в этих полях должен быть уникальный индекс. Если их нет, то они не являются PK, и это может объяснить, почему версии с предложениями WHERE быстрее, чем версия только с JOIN.

Кроме того, Google «Jet SHOWPLAN», чтобы вы могли видеть, что делает оптимизатор запросов Jet, и вы действительно можете увидеть, что происходит.

С индексами вы получите слияние индексов, и это должно быть довольно быстро. Без них я не уверен, как Jet это сделает. Кроме того, это может иметь значение, если ваше поле Y/N индексируется. Силы, которые не рекомендуют индексировать малонаселенные поля (т. Е. Поля с низкой мощностью), но я обнаружил, что индексные логические поля в Jet/ACE могут существенно повлиять на производительность.