Что является лучшей стратегией при работе с несколькими индексами в Mysql

Question

Итак, я создаю веб-сайт с несколькими темами, люди публикуют контент в этих темах, и люди могут комментировать контент. Люди также могут комментировать комментарии, но только на одном уровне. Таким образом, будут комментарии и подкомы, и ничего больше. Все замечания по подкомандам будут перечислены в качестве подкомментариев основного комментария. Мне не нравятся 20 уровней глубоких комментариев, где каждый уровень отмечен отступом. Это разрушает внешний вид моей страницы.

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

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

Answer 1

Я обычно индексировал бы что-нибудь, с которым вы, вероятно, запускаете запрос, тем более, что это доска комментариев, и если вы надеетесь на какой-либо трафик вообще, то не индексирование их может серьезно замедлить рендеринг комментариев.

Редактировать: Решение действительно зависит от того, как вы ожидаете ответа человеческого элемента. Сайт будет загружаться быстрее с большим количеством индексов, но обновления могут быть немного медленнее. Поскольку несколько людей вряд ли будут обновлять информацию одновременно, но люди, как правило, хотят сначала прочитать, я бы опирался на более быстрое время select.

Answer 2

MySQL может использовать индексы с несколькими столбцами для запросов, которые проверяют все столбцы в индексе, или запросы, которые проверяют только первый столбец, первые 2 столбца, первые 3 столбца и т. Д. Если вы укажете столбцы в правильном порядке в определении индекса, один составной индекс может ускорить несколько видов запросов в одной таблице.

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

• Если столбцы в «Где» каждое условие построено с использованием условий «И», лучше создать многоколоночный составной индекс.
• Если столбцы в «Где» каждое условие построено с использованием «OR'conditions», лучше создать несколько индексов на основе каждой колонки.
• кластерные индексы должны иметь уникальный ключ (столбец идентичности, который я бы рекомендовал) в качестве первого столбца. В основном это помогает вставить ваши данные в конце индекса, а не вызывать дисковое разделение диска и разбиение на разделы.
• Если вы создали другие указатели на свои данные, и они построены умно, они будут повторно использованы.

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

состояние, округ, почтовый индекс.

Вы иногда ищете только по штату. вы иногда ищете по штату и округу. вы часто просматриваете по штату, графству, почтовому индексу. Затем индекс с состоянием, графством, zip. будет использоваться во всех трех этих поисках.

Если вы довольно часто выполняете поиск по zip, то указанный выше индекс не будет использоваться (по-разному SQL Server), поскольку zip является третьей частью этого индекса, а оптимизатор запросов не будет считать этот индекс полезным.

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

Я думаю, что ответ, который вы ищете, это то, что он зависит от ваших предложений часто используемых запросов, а также от вашей группы.