Форум MySQL

> стараются сразу переводить на UNIXSTAMP - дата компактная и прекрасно индексируется
Я даты в TIMESTAMP храню. По крайней мере всегда когда это возможно. Это по сути целочисленный формат, так что проблем быть не должно.
Кстати, статус тут ENUM, что по сути тоже целочисленный формат. Так что должно быть шустро.

С индексом

... FORCE INDEX(dogovor_add_date)

помогло. Эксплэйн стал:

5 | DERIVED | dogovor | range | dogovor_add_date | dogovor_add_date | 4 | NULL | 5 | Using where

вместо

5 | DERIVED | dogovor | ALL | dogovor_add_date | NULL | NULL | NULL | 14 | Using where

Вообще с индексированием дат в SQL-формате что-то не чисто, они у вас без аванса нормально индексируются? Были версии MySQL (не отслеживал исправили или нет), которые никак не хотели использоваться индекс по дате, поэтому высоконагруженные проекты стараются сразу переводить на UNIXSTAMP - дата компактная и прекрасно индексируется.

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

+----+-------------+------------+--------+---------------------------+------------+---------+-----------------------------+------+---------------------------------+ | id | select_type | table      | type   | possible_keys             | key        | key_len | ref                         | rows | Extra                           | +----+-------------+------------+--------+---------------------------+------------+---------+-----------------------------+------+---------------------------------+ |  1 | PRIMARY     | <derived2> | ALL    | NULL                      | NULL       | NULL    | NULL                        |   12 | Using temporary; Using filesort | |  2 | DERIVED     | <derived6> | system | NULL                      | NULL       | NULL    | NULL                        |    1 |                                 | |  2 | DERIVED     | <derived7> | system | NULL                      | NULL       | NULL    | NULL                        |    1 |                                 | |  2 | DERIVED     | <derived3> | ALL    | NULL                      | NULL       | NULL    | NULL                        |   12 |                                 | |  7 | DERIVED     | NULL       | NULL   | NULL                      | NULL       | NULL    | NULL                        | NULL | No tables used                  | |  6 | DERIVED     | NULL       | NULL   | NULL                      | NULL       | NULL    | NULL                        | NULL | No tables used                  | |  3 | DERIVED     | <derived4> | ALL    | NULL                      | NULL       | NULL    | NULL                        |   23 | Using temporary; Using filesort | |  3 | DERIVED     | color_mod  | eq_ref | PRIMARY,price_id,color_id | PRIMARY    | 4       | t.color_mod_id              |    1 |                                 | |  3 | DERIVED     | color      | eq_ref | PRIMARY                   | PRIMARY    | 1       | sfinks_l.color_mod.color_id |    1 | Using where                     | |  3 | DERIVED     | price      | eq_ref | PRIMARY,naimen_id         | PRIMARY    | 4       | sfinks_l.color_mod.price_id |    1 | Using where                     | |  3 | DERIVED     | naimen     | eq_ref | PRIMARY                   | PRIMARY    | 4       | sfinks_l.price.naimen_id    |    1 |                                 | |  4 | DERIVED     | <derived5> | ALL    | NULL                      | NULL       | NULL    | NULL                        |    6 |                                 | |  4 | DERIVED     | position   | ref    | dogovor_id                | dogovor_id | 4       | t.dogovor_id                |    1 |                                 | |  5 | DERIVED     | dogovor    | ALL    | NULL                      | NULL       | NULL    | NULL                        |    9 | Using where                     | +----+-------------+------------+--------+---------------------------+------------+---------+-----------------------------+------+---------------------------------+ | id | select_type | table      | type   | possible_keys             | key        | key_len | ref                         | rows | Extra                           | +----+-------------+------------+--------+---------------------------+------------+---------+-----------------------------+------+---------------------------------+ |  1 | PRIMARY     | <derived2> | ALL    | NULL                      | NULL       | NULL    | NULL                        |   12 | Using temporary; Using filesort | |  2 | DERIVED     | <derived6> | system | NULL                      | NULL       | NULL    | NULL                        |    1 |                                 | |  2 | DERIVED     | <derived7> | system | NULL                      | NULL       | NULL    | NULL                        |    1 |                                 | |  2 | DERIVED     | <derived3> | ALL    | NULL                      | NULL       | NULL    | NULL                        |   12 |                                 | |  7 | DERIVED     | NULL       | NULL   | NULL                      | NULL       | NULL    | NULL                        | NULL | No tables used                  | |  6 | DERIVED     | NULL       | NULL   | NULL                      | NULL       | NULL    | NULL                        | NULL | No tables used                  | |  3 | DERIVED     | <derived4> | ALL    | NULL                      | NULL       | NULL    | NULL                        |   23 | Using temporary; Using filesort | |  3 | DERIVED     | color_mod  | eq_ref | PRIMARY,price_id,color_id | PRIMARY    | 4       | t.color_mod_id              |    1 |                                 | |  3 | DERIVED     | color      | eq_ref | PRIMARY                   | PRIMARY    | 1       | sfinks_l.color_mod.color_id |    1 | Using where                     | |  3 | DERIVED     | price      | eq_ref | PRIMARY,naimen_id         | PRIMARY    | 4       | sfinks_l.color_mod.price_id |    1 | Using where                     | |  3 | DERIVED     | naimen     | eq_ref | PRIMARY                   | PRIMARY    | 4       | sfinks_l.price.naimen_id    |    1 |                                 | |  4 | DERIVED     | <derived5> | ALL    | NULL                      | NULL       | NULL    | NULL                        |    6 |                                 | |  4 | DERIVED     | position   | ref    | dogovor_id                | dogovor_id | 4       | t.dogovor_id                |    1 |                                 | |  5 | DERIVED     | dogovor    | ALL    | dogovor_add_date          | NULL       | NULL    | NULL                        |    9 | Using where                     | +----+-------------+------------+--------+---------------------------+------------+---------+-----------------------------+------+---------------------------------+

Первый без ключа на дате, второй с ключем.
Но ключ почему-то все-равно не используется.

Какой смысл и почему не используется?

А главное - почему не используется?
Последняя строка относится к самому вложенному подзапросу, а именно:

SELECT dogovor_id  FROM dogovor  WHERE dogovor_add_date BETWEEN '2012-09-17 00:00:00' AND '2012-09-23 23:59:59'   AND dogovor_status='аванс'

Из-за аванса? И что, добавить индекс на статус или тоже разбить на 2 подзапроса?

Интересно... Я подумаю. Спасибо!

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

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

> На самом деле меняют, локализуют код для работы с базой данных в модели и
> постоянно проводят рефакторинг...

Значит, думаю, нужно, как кто-то тут советовал, выносить все sql-запросы в отдельный файл в виде статических функций разных вспомогательных классов, чтобы в случае чего не по всему коду их выискивать, а все в одном файле.

Судя по всему интуиция побеждает =)
Интуитивно хотелось сделать с суррогатными ключами, но логика не позволяла =)

З.Ы. Я думал, что в индексе и при поиске по индексу любая выборка все равно сводится к работе с целыми числами.

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

PS Если вы подозреваете большие объемы в будущем, стоит думать о том, чтобы таблицы были маленькие, особенно, те, которые будете объединять, желательно, чтобы они сплошь состояли из числовых индексов, а весь текст хранился в отдельных таблицах.

EXPLAIN показателен когда будет объем данных.... А он будет в процессе использования. А в процессе использования менять структуру будет проблематично =)