Индексы MySQL - как повысить производительность?

Question

Я пытаюсь улучшить производительность существующей базы данных MySQL.

Это база данных о ресторанах, есть две соответствующие таблицы:

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

Позвольте мне также сказать, что эта структура базы данных в значительной степени существует, поэтому я не хочу вносить большие изменения, яЯ не собираюсь удалять таблицу всех сущностей, например.(Сама база данных не имеет данных, но движок PHP построен, поэтому будет сложно внести большие изменения в структуру).

есть также таблица только для объектов, есть несколько типов объектов вэта база данных, но рестораны, в частности, будут искать много, так как это тема веб-сайта, рестораны имеют несколько полей: страна, город, название, жанр.не может быть двух ресторанов с одинаковым названием в одном городе и стране (например, МОЖЕТ быть два ресторана с одинаковым названием, но в разных городах одной страны или в двух городах с одинаковым названием, норазные страны)

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

Также я хочу сказать, что URL также созданв форме www.domain.com/Country/City/Restuarant-Name, поэтому комбинация названия страны-города должна быть получена быстро, и этот тип запроса будет происходить много.

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

Вероятно, наиболее часто используемые запросы будут: (а) искать название ресторана в определенном городе и стране (что будет таким же, как запрос, используемый при вводе URL-адреса).но будет использовать LIKE), (б) поиск ресторанов определенного типа в определенном городе и стране.и, наконец, (c) поиск названия ресторана в глобальном масштабе (во всей базе данных, без указания города и страны)

эта таблица (таблица объектов) в настоящее время имеет PRIMARY KEY, который является идентификатором объектов,Идентификатор также часто используется, будет ли передовая практика такой:

1. сделать трехзначный УНИКАЛЬНЫЙ индекс из страны, города, имени
2. сделать другой (не-unique) индекс из имен (поэтому запрос типа c, который я написал выше, будет выполнен быстро)
3. может создать какую-то подстолью, которая содержит только рестораны из объектовтаблица, так что эта под-таблица будет запрошена.(это менее важно, поскольку, если я решу внести большие изменения, я, вероятно, сначала отделю рестораны от остальной части объекта)

Я был бы очень признателен за любую помощьЯ пытался решить это в течение долгого времени.

ps в таблице объектов некоторые объекты не будут иметь какого-либо жанра или любой страны или города, поэтому они останутся NULL, я знаю, что NULLзначения допускаются в УНИКАЛЬНОМ КЛЮЧЕ, но окажет ли это влияние на производительность?

Большое спасибо всем, кто хотел прочитать этот длинный вопрос:)

Answer 1

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

составной ключ
Ваш составной ключ "название страны" кажется наиболее полезнымпорядок, так как он упорядочен от самого широкого до самого узкого критерия выбора.Я уверен, что вы сделали это намеренно, так как значения составного ключа можно использовать только слева направо.Поскольку name не стоит на первом месте в этом индексе, вам понадобится отдельный ключ только для name , как вы заметили.

значения индекса NULL
Согласно imysql.cn , «разрешение значений NULL в индексе действительно не влияет на производительность».Это просто заявлено как отступление без данных или ссылки, поэтому я не знаю, как / если бы они это доказали.

разделение таблицы
Если есть много другихданные, смешанные с записями ресторана, конечно, могут немного затормозить.Если вы осколок таблицы в идентичные структуры "ресторан" и "другие" таблицы, вы все равно можете легко запросить их объединенные данные, если это необходимо, с простым UNION.Если у вас нет представления о ожидаемых данных / замедлении, я бы предпочел избегать разбиения таблицы без необходимости, по крайней мере, для простоты / однородности.

Существуют ли какие-либо предсказуемые запросы, которые текущая индексация бы нене приходится, например, город без страны?Если это так, не забудьте соответствующим образом индексировать, чтобы охватить все предсказуемые случаи.Вы не упомянули об этом, но я предполагаю, что у вас также будет индекс на жанр .

---

В конечном счете, вам нужно сгенерировать много тестовых данных и попробовать (Определите, какой объем данных вы в конечном итоге ожидаете, и сгенерируйте , по крайней мере, , чтобы утроить столько тестовых данных, чтобы система прошла все шаги.) Из того, что вы описали, звучит дизайндовольно хорошо, но тестирование может выявить неожиданные проблемы, места, в которых вы могли бы извлечь выгоду из другой индексации, и т. д. При обнаружении любой проблемы у вас будет конкретная цель, а не просто обдумывание всех сценариев «что если».