Какой из этих подходов SQL является оптимальным?

Question

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

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

{ created at is a DATETIME column }
SELECT `records`.* 
 FROM `records` 
 WHERE DATE(records.created_at) = '2012-02-02';

SELECT `records`.* 
FROM `records` 
WHERE records.created_at BETWEEN '2012-02-02 00:00:00' AND '2012-02-02 23:59:59';

Answer 1

Это выглядит как MySQL (не моя сильная сторона), поэтому я мог бы говорить совершенно глупости, но я бы посмотрел на

• Создание вычисляемого столбца create_at_date как DATE
• Добавить уникальный индекс в вычисляемом столбце.

Что-то вроде

CREATE TABLE records (
  created_at DATETIME
  , created_at_date AS DATE(created_at)
  , ...
)

CREATE UNIQUE INDEX UIX_RECORDS_CREATED_AT_DATE ON Records (created_at_date)

Answer 2

Если сравнить, что подходит, второй, безусловно, лучше. в первом варианте DATE (somefield) запрещает оптимизатору использовать какой-либо индекс. Так что в первом варианте - mysql просканирует всю таблицу.

Кстати: это не равные запросы. Первый выбирает только '02 -02-2012 ', второй выбирает 2 и 3 февраля.

Но. Оба варианта не подходят, если вам нужно просто избегать дубликатов. Для этого используйте уникальный индекс.

Answer 3

Второй менее вероятно вызовет сканирование таблицы (если, конечно, вы проиндексировали created_at).

Всякий раз, когда вы делаете что-то для столбца, прежде чем проверяете его (если сервер не достаточно умен, чтобы понять, что ему это не нужно, а это не так часто), этот материал должен быть сделан длязначение каждой строки перед тестом.Это означает, что каждая строка в таблице должна быть проверена.Если у вас есть индекс на created_at, сервер вполне может его игнорировать.