SQL: оптимизировать неинтенсивный SELECT для полей DateTime - PullRequest
Новая
       9

SQL: оптимизировать неинтенсивный SELECT для полей DateTime

0 голосов
/ 24 апреля 2010

У меня есть приложение для планирования определенных событий. И все эти события должны проверяться после каждого запланированного времени.

Итак, в основном у нас есть 3 таблицы:

  • предметов (идентификатор, имя)
  • schedule_items (id, item_id, execute_at - datetime) - столбец item_id имеет опцию индекса.
  • Review_items (id, item_id, created_at - datetime) - столбец item_id имеет опцию индекса.

Таким образом, основная функция приложения - «дать мне какие-либо предметы (которые еще не рассмотрены) на текущий момент».

Как я могу оптимизировать это решение для скорости (потому что это очень важная бизнес-функция, а не микрооптимизация)?

Я полагаю, что добавление индекса к полям даты и времени не имеет никакого смысла, потому что количество элементов или уникальность этих полей очень велико, и индекс не даст никакого (?) Ускорения. Это правильно?

Что бы вы порекомендовали? Стоит ли попробовать no-SQL?

- 

mysql -V
5.075

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

обновлен.

1 Ответ

1 голос
/ 24 апреля 2010

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

Разве обзоры не должны быть связаны с запланированными элементами, а не с элементами? Теперь вы должны сравнить даты, чтобы увидеть, какие отзывы идут после одного запланированного элемента, но до следующего. Кроме того, если элемент запланирован дважды с коротким промежутком времени, вы можете получить оба отзыва, относящиеся ко второму расписанию.

С этим изменением вы можете легко выделить непроверенные расписания: 

select i.id, i.name, s.execute_at
from items i
inner join scheduled_items s on s.item_id = i.id
left join reviewed_items r on r.scheduled_items_id = s.id
where r.id is null

По вашему вопросу:

Я полагаю, что добавление индекса к поля даты и времени не имеют никакого смысла потому что мощность или уникальность на этих полях очень высоки и индекс не даст никакого (?) ускорения. Это исправить?

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

...