MySQL скорость, индекс таблицы и выберите / обновить / вставить

Question

У нас есть таблица MySQL, в которой более 7 000 000 (да, семь миллионов) строк. Мы всегда делаем так много запросов SELECT / INSERT / UPDATE за 5 секунд.

Хорошо ли, что если мы создадим MySQL INDEX для этой таблицы? Будут ли плохие последствия, такие как повреждение данных или потеря служб MySQL и т. Д.?

Маленькая информация:

• MySQL версия 5.1.56
• Сервер CentOS
• Настольные двигатели MyISAM
• Загрузка процессора MySQL между 200% - 400% всегда

Answer 1

Как правило, индексы улучшают скорость операций SELECT и замедляют операции INSERT / UPDATE / DELETE, поскольку и базовая таблица, и индексы должны изменяться при изменении.

Answer 2

У меня была такая же проблема , которую вы описали.

Я сделал несколько изменений и 1 запрос прошел от 11 секунд до нескольких миллисекунд

1- Обновлен до MariaDB 10.1

2 - поменял ВСЕ мои БД на движок ARIA

3 - изменен my.cnf на строгий минимум

4- Обновлен php 7.1 (но это немного повлияло)

5 - с CentOS: «Yum update» в терминале или через ssh (поддерживая все в актуальном состоянии)

---

1- MariaDB - это новая версия MYSQL с открытым исходным кодом

2- Двигатель ARIA - это эволюция MYISAM

3 - в my.cnf обычно слишком много изменений, влияющих на производительность Вот пример

[mysqld]
performance-schema=1
general_log=0
slow_query_log=0
max_allowed_packet=268435456

Удаляя все дополнительные параметры из my.cnf, он говорит mysql использовать значения по умолчанию.

В MYSQL 5 (5.1, 5.5, 5.6 ...), когда я это сделал; Я заметил только небольшую разницу.

Но в MariaDB -> маленький my.cnf, как этот, сделал БОЛЬШУЮ разницу.

******* ВСЕ эти изменения; аппаратное обеспечение сервера осталось прежним.

Надеюсь, это поможет вам

Answer 3

Если вы ищете производительность, индексы - это путь. Индексы ускоряют ваши запросы. Если у вас 7 миллионов записей, ваши запросы, вероятно, занимают много секунд в минуту, в зависимости от объема вашей памяти.

Вообще говоря, я бы создал индексы, которые соответствуют наиболее частым операторам SELECT. Все говорят о негативном влиянии индексов на размер и скорость таблицы, но я бы пренебрег этим влиянием, если только у вас нет таблицы, для которой вы выполняете вставки и обновления в 95% времени, но даже тогда, если эти вставки происходят ночью и вы запрашиваете в течение дня зайдите и создайте эти индексы, ваши пользователи в дневное время оценят это. Каково фактическое влияние времени на оператор вставки или обновления, если есть дополнительный индекс, может быть 0,001 секунды? Если индекс экономит много секунд на каждый запрос, я думаю, дополнительное время, необходимое для обновления индекса, того стоит.

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

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

Answer 4

Очень сложно сказать такое. Я ожидаю, что само индексирование может занять некоторое время. Но после этого у вас должны быть некоторые улучшения. По словам @Joe и @Patrick, это может повредить время вашей модификации, но выбор будет быстрее.

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

Answer 5

Индексы значительно помогут при выборе. Особенно, если они хорошо совпадают с обычно фильтруемыми полями. И у вас есть хороший простой первичный ключ. Они помогут как со временем запросов, так и с циклами обработки.

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

То, сколько вы будете сообщать (выберите оператор) против обновления (должно!), Сильно повлияет как на ваш первоначальный дизайн, так и на ваши последующие корректировки, когда ваша БД окажется в дикой природе. Поскольку у вас уже есть то, что у вас есть, тестирование даст вам ответы на ваши вопросы. Если вы действительно делаете много запросов на выборку и много обновлений, ваше решение может заключаться в том, чтобы время от времени копировать данные в таблицу отчетов . Тогда вы можете индексировать как сумасшедший без вредных последствий.

Вы на самом деле задали большой вопрос, и вам следует больше изучить этот вопрос. Общие вещи, которые я упомянул выше, применимы для большинства всех реляционных БД, но есть также специфическое поведение конкретных баз данных (в вашем случае MySQL), главным образом в том, как они решают, когда и где использовать индексы.