MariaDB 10.2.19 на Linux - производительность очень низкая - PullRequest
0 голосов
/ 17 января 2020

Основная проблема - у меня есть запрос, соединяющий две таблицы, которые проиндексированы. Когда я запускаю запрос, даже после пяти часов он все еще выполняется ... Я никогда не получал результаты обратно. это как бесконечный запрос. Это новая база данных, которую мы только что установили, и действительно первый запрос, который мы попробовали. Производительность очень низкая. На данный момент я пытаюсь выяснить, связана ли проблема с SERVER / CPU / Network / IO / RAM или самой базой данных (необходимо настроить файл конфигурации) или это запрос. Когда я объясняю план, я вижу, как используются индексы. Является ли мой объем данных слишком большим для обработки MariaDB на основе чисел, представленных ниже? Где я могу начать устранение неполадок? Любая помощь очень ценится.

Спецификации -

• У нас есть MariaDB 10.2.19 на linux rhel7.5 • Наша база данных в основном используется для хранения ежемесячных данных, а затем мы отчитываемся по ним и делать аналити c работы. • У нас около 70 с лишним таблиц.
• 3-4 пользователя • Я выполняю запрос, объединяющий две таблицы. Размер таблиц указан ниже. Запрос не сложен - простое внутреннее объединение столбцов и для обеих таблиц я ищу данные за год / месяц 201911. Две таблицы объединены двумя столбцами, и оба столбца проиндексированы в обеих таблицах. Я изменил запрос для многих вариантов, и ни один из запросов не возвращает никаких строк ... даже после выполнения в течение 5 часов он все еще никогда не завершается, и мне пришлось убить запрос.

Размер базы данных (Innodb) 1919.69G

Размер таблицы1 - daily_2019
Всего рядов 1 034 987 628 Анализируемых данных (с помощью выражения where) 73 895 929 Общий размер таблицы 230,62 ГБ

Размер таблицы 2 - ZIPCODES

                   Total Rows                                            68,429,146                
                   Data I’m analyzing (using where clause)               3,998,975
                   Total table size                                      28.70GB

Объяснить план - у таблиц daily_2019 и почтовых индексов по три индекса по три разных поля. Каждый Col1, col2 и col3 имеют индексы для daily_2019 и почтовых индексов. В плане объяснения используются два ключа. Один из каждой таблицы.

Мы установили для innodb_buffer_pool_size значение 128G

Объяснить план

+------+-------------+-------+------+-------------------------------------+-------------+---------+-----------------------+---------+------------------------------------+
| id   | select_type | table | type | possible_keys                       | key         | key_len | ref                   | rows    | Extra
+------+-------------+-------+------+-------------------------------------+-------------+---------+-----------------------+---------+------------------------------------+
|    1 | SIMPLE      | T2    | ref  | ZIP_I2,ZIP_I1,ZIP_I3                | ZIP_I1      | 5       | const                 | 7994358 | Using where
|    1 | SIMPLE      | T1    | ref  | ADHOC_I2,ADHOC_I1,ADHOC_I3          | ADHOC_I3    | 13      | T2.ID                 |      12 | Using index condition; Using where
+------+-------------+-------+------+-------------------------------------+-------------+---------+-----------------------+---------+------------------------------------+
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...