Ужасная производительность по простому запросу INDEX

Question

Ужасная производительность по простому запросу INDEX

0

Я запускаю это в базе данных с 55 ГБ встроенного буфера. Сервер находится на amazon с EBS 7000 IOPS SSD-производительностью, настолько впечатляющим.

Таблица составляет 190 ГБ данных и 116 ГБ общих индексов.

Запрос выполняется в индексированном столбце varchar:

 Query   14246   Sending data    select count(*) from profile WHERE name is not null

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

Mysql: Распространение 5.5.42 Я не могу обновить, в общей сложности у меня есть 2 терабайта хранилища баз данных, и его обновление будет необходимо экспортировать и снова прочитать, поэтому я заблокирован этой версией mysql.

Результаты объяснения:

1       SIMPLE  profile        NULL    range   name    name    771     NULL    153588811       100.00  Using where; Using index

Что я могу сделать с этой ужасной работой? Я бы ожидал, может, 5 минут, а не 5 часов..

John 25 май 2018, в 20:43

Источник

0

Любые изменения, если вы используете первичный ключ в подсчете?
Mihai 25 май 2018, в 17:57
0

Я могу попытаться использовать первичный ключ (count (id)), но мне сказали, что * это правильный способ подсчета в отношении производительности. Чтобы получить результаты, потребуется некоторое время :) Но даже если это поможет, полное сканирование должно занять полчаса, верно? Так почему же эта штука работает с 5 часов?
John 25 май 2018, в 17:59
0

Может быть ошибка в MySQL. Покажите определение таблицы в любом случае, для завершения.
Mihai 25 май 2018, в 18:01
0

Да, ты прав. Даже если столбец не проиндексирован, подсчет ненулевых значений не должен занимать часы. Сколько записей у вас в этой таблице?
Racil Hilan 25 май 2018, в 18:02
0

около 400 миллионов записей
John 25 май 2018, в 18:09
0

Сколько времени занимает count(*) ? Возможно, вам не повезло, и при подсчете было много операций DML.
Gordon Linoff 25 май 2018, в 21:31
0

Гордон, в прошлый раз, когда я пытался, потребовалось около часа, чтобы сделать полный подсчет. Дело в том, что если бы я сделал простую копию файла, я мог бы сделать это примерно через полчаса. Это означает, что чтение и запись всех данных в несколько раз быстрее, чем при использовании простого чтения MySQL.
John 25 май 2018, в 22:37
0

Никогда не сравнивайте копию файла с операциями базы данных. Копирование файла - это низкоуровневая операционная система чтения и записи байтов в блоках, практически не требующая обработки. С другой стороны, даже такой простой запрос, как ваш, требует большого объема обработки, механизм БД должен собрать и проанализировать данные, а затем применить вычисления, необходимые для получения результатов, которые должны быть отформатированы для отображения. Я не говорю, что для вашего простого запроса достаточно одного часа, вероятно, это займет гораздо меньше, но это не имеет никакого отношения к копированию файла.
Racil Hilan 25 май 2018, в 22:54

Показать ещё 6 комментариев

Теги:

mysql

sql

2 ответа

-2

Пожалуйста, попробуй:

 select count(name) from profile;

** Изменение: count (name) count rows, где name не Null. Без предложения WHERE этот запрос может быть быстрее, чем оригинал в вопросе.
Я не тестировал его с 5.5.42 и большими таблицами.

Eperbab 25 май 2018, в 17:31

0

У меня нет сервера 5.5.42 с 2 ТБ реальных данных для тестирования. Так что я на самом деле не знаю, как быстро это.
Eperbab 25 май 2018, в 18:53
0

Любой комментарий о том, как улучшить его без фактического тестирования его производительности с вышеуказанными настройками?
Eperbab 25 май 2018, в 19:01

Ещё вопросы

Любые изменения, если вы используете первичный ключ в подсчете?
Я могу попытаться использовать первичный ключ (count (id)), но мне сказали, что * это правильный способ подсчета в отношении производительности. Чтобы получить результаты, потребуется некоторое время :) Но даже если это поможет, полное сканирование должно занять полчаса, верно? Так почему же эта штука работает с 5 часов?
Может быть ошибка в MySQL. Покажите определение таблицы в любом случае, для завершения.
Да, ты прав. Даже если столбец не проиндексирован, подсчет ненулевых значений не должен занимать часы. Сколько записей у вас в этой таблице?
Сколько времени занимает count(*) ? Возможно, вам не повезло, и при подсчете было много операций DML.
Гордон, в прошлый раз, когда я пытался, потребовалось около часа, чтобы сделать полный подсчет. Дело в том, что если бы я сделал простую копию файла, я мог бы сделать это примерно через полчаса. Это означает, что чтение и запись всех данных в несколько раз быстрее, чем при использовании простого чтения MySQL.
Никогда не сравнивайте копию файла с операциями базы данных. Копирование файла - это низкоуровневая операционная система чтения и записи байтов в блоках, практически не требующая обработки. С другой стороны, даже такой простой запрос, как ваш, требует большого объема обработки, механизм БД должен собрать и проанализировать данные, а затем применить вычисления, необходимые для получения результатов, которые должны быть отформатированы для отображения. Я не говорю, что для вашего простого запроса достаточно одного часа, вероятно, это займет гораздо меньше, но это не имеет никакого отношения к копированию файла.
У меня нет сервера 5.5.42 с 2 ТБ реальных данных для тестирования. Так что я на самом деле не знаю, как быстро это.
Любой комментарий о том, как улучшить его без фактического тестирования его производительности с вышеуказанными настройками?

Bernd Buffen · Accepted Answer · 2018-05-25T16-12-00.000Z

Я не знаю, сколько процентов строк имеет имя = NULL. Поэтому в большинстве случаев гораздо быстрее использовать индекс. Если MySQL использует индекс, строки обрабатываются в порядке индекса. Вот почему MySQL часто должен читать другой блок, чтобы получить следующую ROW. Это занимает много времени.

Попробуйте такой запрос, который читает всю строку, но на физическом диске на диске

SELECT sum(name is not null) as cnt FROM profile;

пожалуйста, дайте мне знать, это влияет.

Это интересное предложение. Я постараюсь, однако, это не делает меня счастливым. На этот раз: вся информация на самом деле в индексе. почему он вообще должен искать в таблице? И нет ли способа ускорить такой статистический подсчет без принудительного полного сканирования?
Это примерно в 3 раза быстрее, чем индексированный запрос. Я почему-то сомневаюсь, что правильное решение возможно, так как это кажется недостатком внутренней логики mysqls, поэтому я принимаю это.
Примечание: count (name) учитывает только те строки, в которых name не равно NULL. Поэтому я предложил проверить скорость «выбрать количество (имя) из профиля;», но мой ответ был опущен и удален. Я до сих пор не понимаю, почему? @triggernz