Эффективность Sql-запроса

[buster 1827]

Лень лезть в инет на тематические форумы, мож кто тут знает. Есть две таблицы - в одной идентификаторы состояний (текущее и нынешнее). В другой - этим идентификаторам сопоставлены текстовые названия. Задача вывести вместо ID сами названия. Сейчас сделал так:

 

SELECT a1.state AS previous, a2.state AS current, b.timestamp
FROM state_names AS a1, state_names AS a2, state_log AS b
WHERE b.ID_previous_state = a1.ID and b.ID_current_state=a2.ID

 

Вроде как все работает, и даже результаты EXPLAIN в mysql не напрягают. Но смущает двойное упоминание одной и той же таблицы (state_names как a1 и она же как a2)

 

Есть у кого мысли на этот счет?

[alp 0]

Всё правильно сделал, расслабся.

Можешь план показать для полной уверенности.

 

ЗЫ

Ведущую таблицу принято писать первой, так читать удобней имхо.

[zloj 1]

Но смущает двойное упоминание одной и той же таблицы (state_names как a1 и она же как a2)

imho: никакого криминала.

 

[buster 1827]

Всё правильно сделал, расслабся.

 

OK, пасиба

 

Можешь план показать для полной уверенности.

 

id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra
1     SIMPLE     b     ALL     NULL     NULL     NULL     NULL     19      
1     SIMPLE     a2     ALL     ID     NULL     NULL     NULL     6     Using where; Using join buffer
1     SIMPLE     a1     ALL     ID     NULL     NULL     NULL     6     Using where; Using join buffer

 

ЗЫ Ведущую таблицу принято писать первой, так читать удобней имхо.

 

ОК, учту... Я вообще это руками набил в форуме, чтобы нагляднее и проще выглядело.

 

zloj, тож спасибо за отклик.

[zloj 1]

Ээээ.... А индексы бы не помешали.

[buster 1827]

Ну да, будут Я только начал...

[AgentXXX 1]

imho: никакого криминала.

+1.

 

Ээээ.... А индексы бы не помешали.

Для таблицы сохранения истории (state_log - я так понимаю история изменения статусов) ну как бы не особо.

 

Есть у кого мысли на этот счет?

Мысли о матчасти.

 

Вроде как все работает

Сохранись и ничего не меняй.

[zloj 1]

Для таблицы сохранения истории (state_log - я так понимаю история изменения статусов) ну как бы не особо.

Поясни?

 

[jes 0]

Не распределена на кластерах.

Я правильно понял твою мысль, AgentXXX?

[AgentXXX 1]

Поясни?

История всякой хрени - это по сути всегда большая помойка.

Обычно для обработки пегче придумать специальную ETL подготавливающую отдельный Data Mart откуда исторические данные юзать и быстрее и приятней.

Пример - актуальный статус чего-либо.Делаешь либо на дневной базе либо по типу tactical query если отслеживаешь в течении дня.(крайне извращенный вариант, встречается у маньяков)

Ну и место.Индекс таки да, таки требует места.Но это критично на какой-нить большой хистори и для мускуля рассматривать наверное не обязательно.

Да, я знаю что вы сейчас скажете что место сейчас копейки стОит и т.д. но оно таки да, бывает критично на определённых объёмах.

[zloj 1]

Вы в страшни дебри забрались!

То, что ETL в полный рост рулит -- это понятно.

То, что логи как правило порядочная помойка -- реальность, но с ней надо бороться.

 

Но вопрос в том, что подобные запросы надо делать здесь и сейчас, а не тогда, когда будет готов полноразмерный BI (который вряд ли кому-то вообще понадобится).

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

[AgentXXX 1]

иметь индексы на поля вроде ID - просто приятно и наверняка пригодится.

 

zloj, я сам любитель подобного подхода и готов проППКСится сто раз.

Скажу больше - поле с префиксом ID_ всегда у меня вызывает желание изобрести способ сделать его индексом просто на уровне подсознания.

Делать здесь и сейчас - значит размер истории позволяет, но когда у меня позволяла история(типа 2-3 млн. записей в месяц, то это что-то одно и для грустных ситуаций можно было индексить и вьюх хитрых навешать и иметь счастье для разных случаев жизни.

А 50-70 млн. записей в день заставляют иногда думать и по-другому.

[zloj 1]

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

 

[alp 0]

Что-то вы, дядьки, в дебри какие-то полезли.

Индекс на stage_log.id_*_state нафих не нужен. (почти наверное)

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

 

Здесь индексы нужны только на первичных ключах и то, для порядку.

[AgentXXX 1]

Ты просто проецируешь свою ситуацию, на чужую.

У кого что болит...

Что-то вы, дядьки, в дебри какие-то полезли.

Альпушка, ты прав.