2010-08-31 5 views
0

Я пытаюсь запустить набор вложенных или сложенных запросов в Microsoft Access.Оптимизация вложенных запросов Microsoft Access

As in I run Query 1 
-->I use the results of Query 1 in Query 2 
---->I use the results of Query 2 in Query 3 
------>I use the results of Query 3 in Query 4 

Запрос 3 занимает менее 1 секунды для запуска.

-- Query 3 results -- 
PARTID INFO 
266 156-10 
266 165-10 
266 183-10 
266 200-10 
266 205-10 
266 219-10 
266 228-10 
266 230-10 
--end Query 3 results -- 

Когда я запускаю Query 4, для запуска требуется более минуты. Довольно медленно. Поэтому я попытался создать новую таблицу (Test_Table) с результатами из Query 3. Я изменил Query 4, чтобы использовать эту таблицу, а не Query 3. Теперь Query 4 работает менее чем за 1 секунду.

Оригинал Slow Query 4 Код:

SELECT INVENTORYLOG.TABLEID, INVENTORYLOG.RECORDID, TIINVENTORYLOG.INFO, INVENTORYLOG.TYPEID 
FROM Query3 INNER JOIN (TIINVENTORYLOG INNER JOIN INVENTORYLOG ON TIINVENTORYLOG.INVENTORYLOGID = INVENTORYLOG.ID) ON (Query3.PARTID = INVENTORYLOG.PARTID) AND (Query3.INFO = TIINVENTORYLOG.INFO) 
WHERE (((INVENTORYLOG.TYPEID)<>40)) 
ORDER BY TIINVENTORYLOG.INFO; 

Модифицированный Fast Query 4 код:

SELECT INVENTORYLOG.TABLEID, INVENTORYLOG.RECORDID, TIINVENTORYLOG.INFO, INVENTORYLOG.TYPEID 
FROM Test_Table INNER JOIN (TIINVENTORYLOG INNER JOIN INVENTORYLOG ON TIINVENTORYLOG.INVENTORYLOGID = INVENTORYLOG.ID) ON (Test_Table.info = TIINVENTORYLOG.INFO) AND (Test_Table.partid = INVENTORYLOG.PARTID) 
WHERE (((INVENTORYLOG.TYPEID)<>40)) 
ORDER BY TIINVENTORYLOG.INFO; 

Inventorylog имеет около 23 000 записей tiinventorylog имеет около 18 000 записей

Так что я думаю, вопрос is: Как заставить Query 4 работать быстро, используя Query 3 вместо моей тестовой таблицы?

Спасибо за любой совет, который вы можете дать.

+1

Вы могли бы дать как sql для запросов 1 и 2? – user158017

+1

и, возможно, любую информацию об индексированных или первичных ключах? – user158017

+0

JETSHOWPLAN - это ценный инструмент для оптимизации запросов в MS-Access. Google JETSHOWPLAN или начать здесь: http://articles.techrepublic.com.com/5100-10878_11-5064388.html Текстовый файл Showplan.out может быть немного подавляющим при первом просмотре, но вы можете получить все, что угодно нужно знать, выполнив поиск в «Сканировании» и «Рашмор» ...«Сканирование» = BAD, «Rushmore» = GOOD – mwolfe02

ответ

0

Не зная первых двух запросов, трудно сразу увидеть, в чем проблема. Тем не менее, я скажу, что вещи всегда замедляются, когда у вас есть таблица, соединяющая две другие таблицы. (объединение в длинную цепочку быстрее, чем объединение в круг, что и есть здесь.) Как вы можете видеть, у вас есть соединение query3 с обеими двумя таблицами. Возможно, что-то вроде этого МОЖЕТ работать лучше. Но это действительно зависит от индексирования, размера таблиц и от ваших двух других запросов - если две таблицы инвентаря огромны, это может фактически замедлить работу.

Итак, как только вы дадите немного больше информации, я мог бы пересмотреть эту мысль.

SELECT * 
from (select INVENTORYLOG.TABLEID, 
      INVENTORYLOG.RECORDID, 
      TIINVENTORYLOG.INFO, 
      INVENTORYLOG.TYPEID, 
      INVENTORYLOG.PARTID 
      from INVENTORYLOG 
      inner join TIINVENTORYLOG 
      on TIINVENTORYLOG.INVENTORYLOGID = INVENTORYLOG.ID 
      where INVENTORYLOG.TYPEID<>40)a  
inner join query3 
    on query3.partid = a.partid 
    and query3.info = a.info 
+0

Одним из основных достижений сохраненного QueryDefs в Access является то, что он избавляет вас от наличия целой группы вложенных производных таблиц, синтаксис которых может быть весьма точным. –

+0

Это правда - это намного проще, но я также обнаружил множество проблем с замедлением, когда я сделал что-то похожее на оригинальный плакат, с одним запросом в качестве источника для другого, а затем другого. Вероятно, есть способ исправить это и оставаться в пределах того, что Access делает хорошо, но я не думаю, что на самом деле достаточно информации, чтобы хорошо ответить на этот вопрос. – user158017

+1

Ну, вы, ребята, помогли мне решить это круглым путем. Я собирался опубликовать код для первых 3 запросов. Запросы 2,3 и 4 были очень чистыми без каких-либо ненужных объединений или столбцов. Однако в запросе 1 было несколько дополнительных функций. Чтобы очистить сообщение, я очистил Query 1 до основы. Затем, черт возьми, я снова запустил оригинальный медленный Query 4. Не медленнее. До 1 секунды или меньше. Поставьте Query 1 extras обратно, Query 4 будет медленным, возьмите дополнительные функции, Query 4 будет быстрым. Я бы по-прежнему готов опубликовать Запросы, если люди заинтересованы, но на данный момент моя проблема решена. Благодарю. – greencherry

0

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

Теперь, когда вы знаете, чего ожидать от своих запросов и можете легко их протестировать, попробуйте комбинировать первые два. Возможно, вам придется сделать это в текстовом редакторе SQL. Если вам повезет, вы можете скопировать SQL из из Query1 и поместить его в Query 2

Select * from Query1; 

становится

Select * from (Select whatever you pasted from Query1) as Query1; 

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

+0

Не должно быть никакой разницы в производительности Jet/ACE между версией с использованием сохраненных QueryDefs и версии с подзапросами производных таблиц. Ну, вероятно, есть немного разница в оптимизации запросов. Возможно, планы оптимизации отдельных запросов могут противоречить плану оптимизации версии с подзапросами, но я использовал вложенные запросы во всех приложениях Access, и это никогда не было проблемой производительности, если они отвечают на запросы компонентов -written. –

+0

Каковы бы ни были короткие предложения, вызванные плохо написанными запросами, дизайн базы данных и индексация будут усугубляться, когда вы идете на 4 глубины. В какой-то момент вам нужно научиться писать подзапрос. – JeffO

+0

Вам не нужно научиться писать подзапрос в Access для этой цели. В общем, я не использую производные подзапросы таблицы в Access, за исключением тех случаев, когда сохраненный QueryDef не будет делать трюк, то есть критерии изменяются во время выполнения. Поскольку я рассматриваю редактирование сохраненных QueryDefs во время выполнения, чтобы избежать чего-то, я пишу динамический SQL с производными подзапросами таблицы. Но это необходимо только там, где сохраненные QueryDefs недостаточны. –

Смежные вопросы