Как оптимизировать этот запрос, используя лучшее сравнение дат в SQL? - PullRequest
0 голосов
/ 27 октября 2010

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

SELECT (...) FROM table 
WHERE (YEAR(row_add_date) * 10000 + 
       MONTH(row_add_date) * 100 + 
       DAYOFMONTH(row_add_date)) >= (var_0 * 10000 + var_1 * 100 + var_2) and
      (YEAR(row_add_date) * 10000 + 
       MONTH(row_add_date) * 100 + 
       DAYOFMONTH(row_add_date)) <= (var_3 * 10000 + var_4 * 100 + var_5) 

Кто-нибудь может мне помочь?Привет

Ответы [ 3 ]

2 голосов
/ 27 октября 2010

Я бы предложил использовать встроенное сравнение дат в MySQL.

row_add_date <= '20101027' and row_add_date >= '20101027'

Но обратите внимание, что это странный тест, во-первых: не просто проверять, что дата равна 27 октября, вот так:

row_add_date = '20101027'
2 голосов
/ 27 октября 2010

Почему ты так разбиваешь дату? Функции для каждой строки хорошо масштабируются , а не . Мне кажется, что весь раздел даты в конце можно заменить на:

where row_add_date = '2010-10-27'

Даже если вам нужен диапазон, вам все равно лучше использовать даты такими, какие они есть.


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

0 голосов
/ 27 октября 2010

Я собираюсь догадаться, что row_add_date имеет тип datetime.Если это так, вам нужно превратить 20101027 в datetime и сравнить столбец с этим.

Другими словами:

row_add_date >= firstDateTime and row_add_date <= secondDateTime
...