Почему объединение Cint (char field) в поле int быстрее, чем int в int? - PullRequest
Новая
       35

Почему объединение Cint (char field) в поле int быстрее, чем int в int?

3 голосов
/ 11 января 2012

Я выполняю следующие 2 запроса в Microsoft Access, которые дают тот же результат, но второй запрос выполняется примерно через 5 секунд, тогда как первый занимает около 10 минут.Я полностью потерян здесь.Первый запрос соединяет целочисленное поле с другим целочисленным полем, а второй запрос соединяет поле cint(text) с целочисленным полем и работает НАМНОГО быстрее.

Запускается через 10 минут:

Я задаю tblA.number = целочисленное поле 

SELECT A, B, sum(d) as C
FROM tblA 
INNER JOIN (tblB INNER JOIN tblC ON tblB.A = tblC.A) 
    ON tblA.number = tbl B.B)
GROUP BY A, B
HAVING F like '*808*'

Запускается через 5 секунд: - обратите внимание на cint(tblA.A)

I set tblA.number = text field
SELECT A, B, sum(d) as C
FROM tblA 
INNER JOIN (tblB INNER JOIN tblC ON tblB.A = tblC.A) 
    ON cint(tblA.number) =   tbl B.B)
GROUP BY A, B
HAVING F like '*808*'

Ответы [ 3 ]

1 голос
/ 12 января 2012

Вы говорите, что tblA.number является типом данных char?

Я думаю, что имеет смысл, что использование cint () будет быстрее, поскольку вы преобразуете строку в число, а затем проводите сравнение чисел со столбцом tblB.B.

Я не могу представить, чтобы кого-то удивило, что сравнение строк (которое происходит символ за символом) приведет к чему-то близкому к сравнению двух чисел.

В первом примере, поскольку типы данных не совпадают, первый tblA.number является строкой, и поэтому он, вероятно, преобразует столбец tblB.B в строку для этого сравнения.

Таким образом, преобразование числа в строку, вероятно, происходит медленнее (требуется больше памяти для пространства строк, а затем возникает проблема сбора мусора, когда вы выбрасываете строку). Так что не только создание строки будет стоить времени, но и хуже, сравнение строк будет медленнее.

С помощью cint () вы конвертируете (приводите) строку в число (возможно, быстрее, чем в строку), а затем выполняете сравнение чисел (которое, безусловно, быстрее, чем сравнение строк).

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

0 голосов
/ 11 января 2012

Некоторые возможности, которые приходят на ум:

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

К сожалению, есть много факторов в планировании и оптимизации запросов. Иногда просто невозможно понять, почему все происходит так, как это происходит.

0 голосов
/ 11 января 2012

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

...