Опять ДБ трабл.

[vladiSib]

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

 

[AgentXXX]

Хотя бы расставить.Уже будет хорошо.

[sashka304]

А без лицензии ставить не буду.У меня уже два предупреждения от саппорта по поводу пиратских программ.

Вот родилась мыль, незнаю рабочая или нет.. Если поднять виртуалку с виндой и туда все наставить пропасет саппорт такую штуку или нет?

 

[AgentXXX]

Если поднять виртуалку с виндой и туда все наставить пропасет саппорт такую штуку или нет?

Нет.

[vladiSib]

Дядька, ты лучше раскажи, чей-то ты занялся строительством серверовен?

[AgentXXX]

История длинная, запутанная.

Надо на "англичана" зайти.Там тебе и поведаю.

[vladiSib]

да не вопрос.

звони, пойдем.

среда - пятница. около 12-30

 

[Jin]

есть сложный primary key состояший из prefix CHAR(3), number INT, suffix CHAR(3), year INT.

Я такого не люблю, поэтому primary key - еще некое id INT, a эти 4 поля в таблице просто так.

Но по ним надо искать вместе и поотдельности.

 

Внимание вопрос: сколько доп. индексов должно быть?

5(по каждому на поле + на все сразу) или 1(на все сразу)?

 

MySQL

 

[AgentXXX]

или 1(на все сразу)?

 

Если сложный индекс я бы подумал про Partitioned ( может быть даже Primary - в случае необходимости) Index.

Я не знаю поддерживает ли мускуль Partitioned Index.

[Jin]

а если бы бабушка не была бы дедушкой, то она бы была бабушкой.

 

Так сколько индексов то делать и почему?

 

ПС: Записей мало - до 1млн

[Yevgen35]

надо смотреть на:

- распределение значений в столбцах.

- потом смотерть каков порядок полей будет в запросах.

 

MySQL вроде поддерживает композитные индексы.

Ответ на твой вопрос, "да имет смысл создать один композитный индекс".

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

То есть поля, с большими кол-вом уникальных значений ( более высокая селективность индекса)

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

 

Одинарные индексы на каждое поле не помогут.

Они лишь дополнительно затормозят вставку в таблицу. Больше индексов, больше тормозов на вставке.

 

Прична проста:

Оптимизатор запросов при нахождении оптимального плана не может одновременно

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

 

 

[AgentXXX]

Один по всем полям.Со сбором статистик по каждому полю индекса.

Потому что меньше гемора по рефрешу индекса после изменения данных.

При поиске индекс будет работать.

Будь записей поболе - ещё и экономия места.