Текущий сервер:
Перетащите файлы сюда

Выгрузка SQL ( 0 ) x -

Настройки, касающиеся страницы Кликните на строку, чтобы перейти вверх страницы
Нажмите Ctrl+Enter для выполнения запроса Нажмите Enter для выполнения запроса
по возрастанию
по убыванию
Порядок сортировки:
Отладка SQL
Количество
Порядок выполнения
Занято времени
Сортировки по:
Группировать запросы
Разгруппировать запросы
Свернуть Развернуть Показать трассировку Скрыть трассировку Количество: Занято времени:
Закладки
Обновить
Добавить
Нет закладок
Добавить закладку
Параметры
Восстановить значения по умолчанию
Свернуть Развернуть Повторный запрос Изменить Анализировать Профилирование Закладка Сбой выполнения запроса База данных: Время запроса:

Системный советник

Возможные проблемы производительности

Проблема:
Сервер работает менее одного дня, настройки производительности могут быть не достаточно точны.
Рекомендация:
Для получения более точных средних значений, рекомендуется, перед запуском анализатора, дать проработать серверу более одного дня
Обоснование:
Сервер работает только 0 дн, 9 ч, 32 мин и 29 с
Использованная переменная / формула:
Uptime
Тест:
value < 86400
Проблема:
Значение long_query_time равно 10 секундам или более, таким образом, только медленные запросы, превышающие по времени выполнения 10 секунд, будут записаны в журнал.
Рекомендация:
Предлагается понизить значение переменной long_query_time, в соответствии с вашим окружением. Рекомендуемым значением является 1-5 секунд.
Обоснование:
Переменная long_query_time установлена в 10 секунд.
Использованная переменная / формула:
long_query_time
Тест:
value >= 10
Проблема:
Отключен журнал медленных запросов.
Рекомендация:
Включите запись журналов медленных запросов установив переменную slow_query_log в 'ON'. Это поможет в поиске медленных, недостаточно оптимизированных запросов.
Обоснование:
Переменная slow_query_log установлена в 'OFF'
Использованная переменная / формула:
slow_query_log
Тест:
value == 'OFF'
Проблема:
Было отсортировано большое количество строк.
Рекомендация:
Несмотря на то, что большое количество сортировок само по себе не является плохим показателем, вы должны убедиться, что запросы требующие сортировки используют поля индексов в выражении ORDER BY, так как это приведет к значительно более быстрой сортировке.
Обоснование:
Средний показатель отсортированных строк: 3.16 в секунду
Использованная переменная / формула:
Sort_rows / Uptime
Тест:
value * 60 >= 1
Проблема:
Слишком большое количество объединения не использующих индексы.
Рекомендация:
Это означает сканирование всей таблицы при объединении. Добавление индексов для полей используемых в условии, значительно увеличит скорость объединения.
Обоснование:
Среднее значение объединения таблиц: 3.2 в секунду, данное значение должно быть менее 1 в час
Использованная переменная / формула:
(Select_range_check + Select_scan + Select_full_join) / Uptime
Тест:
value * 60 * 60 > 1
Проблема:
Доля чтения первого вхождения индекса высока.
Рекомендация:
Обычно это означает частое полноиндексное сканирование. Полноиндексное сканирование быстрее сканирования таблицы, но для больших таблиц требует прохождения значительного количества циклов центрального процессора. Если для этих таблиц часто выполняются запросы UPDATE и DELETE, выполнение 'OPTIMIZE TABLE' может уменьшить объем и увеличить скорость полноиндексного сканирования. Другим образом уменьшить полноиндексное сканирование можно только переписав запросы.
Обоснование:
Среднее значение сканирования индексов: 9.02 в минуту, значение должно быть менее 1 в час
Использованная переменная / формула:
Handler_read_first / Uptime
Тест:
value * 60 * 60 > 1
Проблема:
Доля чтения данных из фиксированного положения высока.
Рекомендация:
Указывает на то, что большое количество запросов нуждается в сортировке и/или полном сканировании таблицы, включая запросы объединения не использующие индексы. Добавьте индексы где это возможно.
Обоснование:
Средняя доля чтений из фиксированной позиции: 3.15 в секунду, значение должно быть менее 1 в час
Использованная переменная / формула:
Handler_read_rnd / Uptime
Тест:
value * 60 * 60 > 1
Проблема:
Доля чтения следующей строки таблицы высока.
Рекомендация:
Указывает на то, что большое количество запросов совершают полное сканирование таблицы. Добавьте индексы где это возможно.
Обоснование:
Доля чтения следующей строки таблицы: 113.6 в секунду, данное значение должно быть менее 1 в час
Использованная переменная / формула:
Handler_read_rnd_next / Uptime
Тест:
value * 60 * 60 > 1
Проблема:
Значительное количество временных таблиц было записано на диск, вместо то чтобы быть сохранено в памяти.
Рекомендация:
Может помочь увеличение значений переменных max_heap_table_size и tmp_table_size. Однако некоторые временные таблицы всегда будут записываться на диск, вне зависимости от значений данных переменных. Для исправления данной проблемы вы должны переписать запросы таким образом, чтобы исключить условия (Внутри временной таблицы: Наличие столбца BLOB или TEXT, или наличие столбца более, чем 512 байт), упомянутые в Документации MySQL
Обоснование:
Соотношение временных таблиц записанных на диск: 15.03 в минуту, данное значение должно быть менее 1 в час
Использованная переменная / формула:
Created_tmp_disk_tables / Uptime
Тест:
value * 60 * 60 > 1
Проблема:
Малый % использования буфера ключей MyISAM (кеш индекса).
Рекомендация:
Вероятно необходимо уменьшение размера key_buffer_size, пересмотрите ваши таблицы, чтобы убедиться в удалении индексов, или просмотрите запросы и используемые ими индексы.
Обоснование:
Максимальный % буфера ключей MyISAM, который был использован: 0%, данное значение должно быть выше 95%
Использованная переменная / формула:
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
Тест:
value < 95
Проблема:
Высокое соотношение открытых таблиц.
Рекомендация:
Открытые таблицы требуют выполнения затратных операций ввода-вывода. Избежать этого можно увеличением значения переменной table_open_cache.
Обоснование:
Соотношение открытых таблиц: 14.99 в час, данное значение должно быть менее 10 в час
Использованная переменная / формула:
Opened_tables / Uptime
Тест:
value*60*60 > 10
Проблема:
Высокое соотношение открытых файлов.
Рекомендация:
Рассмотрите возможность увеличения значения переменной open_files_limit и после её изменения и перезагрузки проверьте журнал ошибок.
Обоснование:
Соотношение открытых файлов: 8.07 в час, данное значение должно быть менее 5 в час
Использованная переменная / формула:
Open_files / Uptime
Тест:
value * 60 * 60 > 5
Проблема:
Использовано менее 80% кеша запросов.
Рекомендация:
Это может быть вызвано низким значением переменной query_cache_limit. Так же, может помочь очистка кеша запросов.
Обоснование:
Текущее соотношение свободного кеша запросов по отношению к полному кешу запросов составляет 15%. Значение должно быть выше 80%
Использованная переменная / формула:
100 - Qcache_free_memory / query_cache_size * 100
Тест:
value < 80
Проблема:
Максимальный размер результата установленный в кеше запросов, по умолчанию составляет 1 МиБ.
Рекомендация:
Изменение query_cache_limit (обычно повышение) может увеличить эффективность. Данная переменная определяет максимальный размер результата запроса, который будет добавлен в кеш запросов. При большом количестве результатов запросов свыше 1 МиБ, которые могут быть без труда кешированы (большое количество процессов чтения, малое количество процессов записи), увеличение значения query_cache_limit увеличит эффективность. В то же время, при большом количестве результатов запросов превышающих 1 МиБ, которые не подпадают под условие кеширования (часто недействительны при обновлении таблиц), увеличение query_cache_limit может снизить эффективность.
Обоснование:
query_cache_limit установлен на 1 MiB
Использованная переменная / формула:
query_cache_limit
Тест:
value == 1024*1024