Скинути файли сюди

Вивантаження SQL ( 0 ) x -

Налаштування пов'язаної сторінки Натисніть на панелі, щоб перейти на верх сторінки
Натисніть Ctrl+Enter для виконання запиту Натисніть Enter для виконання запиту
за зростанням
за спаданням
Порядок:
Відлагодити SQL
Відлік
Порядок виконання
Витрачений час
Порядок:
Груповати запити
Розгрупувати запити
Згорнути Розгорнути Показати трасіровку Приховати тарсіровку Кількість: Час створення:
Параметри
Відновлення значень за замовчуванням
Згорнути Розгорнути Повторити запит Редагувати Тлумачити Профілювання Збій виконання запиту База даних: Час запиту:

Система порад

Можливі проблеми з продуктивністю

Результат:
Сервер працює менше доби, налаштування продуктивності можуть бути неточними.
Рекомендація:
Для отримання точніших середніх значень перед запуском аналізатора бажано дати попрацювати серверу понад одну добу
Правомірність:
Сервер працює лише 0 днів, 0 годин, 8 хвилин і 24 секунд
Використана змінна / формула:
Uptime
Тест:
value < 86400
Результат:
Змінній long_query_time присвоєно значення 10 секунд або більше, і з цієї причини в журналі записуються повільні запити понад 10 секунд.
Рекомендація:
Пропонується присвоїти змінній long_query_time менше значення, в залежності від оточення. Рекомендоване значення 1-5 секунд.
Правомірність:
long_query_time наразі встановлений у 10s.
Використана змінна / формула:
long_query_time
Тест:
value >= 10
Результат:
Журнал повільних запитів вимкнено.
Рекомендація:
Увімкніть запис журналів повільних запитів встановивши змінну slow_query_log в 'ON. Це допоможе в усуненні неполадок погано виконаних запитів.
Правомірність:
значення long_query_time встановлено на 'OFF'
Використана змінна / формула:
slow_query_log
Тест:
value == 'OFF'
Результат:
Було відсортовано велику кількість рядків.
Рекомендація:
У великій кількості сортувань рядків немає нічого поганого. Тільки необхідно переконатися, що запити, які вимагають великої кількості сортувань, використовують у виразах ORDER BY стовпці індексів, оскільки це призводить до набагато швидкого сортування.
Правомірність:
Середня кількість відсортованих рядків: 217.93 за секунду
Використана змінна / формула:
Sort_rows / Uptime
Тест:
value * 60 >= 1
Результат:
Забагато об'єднань без індексів.
Рекомендація:
Це означає сканування всієї таблиці при об'єднанні. Додавання індексів до стовпців використаних в операторах об'єднання, значно підвищать швидкість об'єднання таблиці.
Правомірність:
Середнє значення об'єднання таблиць: 66.26 за секунду, це значення не повинно перевищувати 1 на годину
Використана змінна / формула:
(Select_range_check + Select_scan + Select_full_join) / Uptime
Тест:
value * 60 * 60 > 1
Результат:
Рівень читання першого входження індексу завеликий.
Рекомендація:
Це зазвичай вказує на часті повні сканування індексу. Повні сканування індексу виконуються швидше, ніж сканування таблиці, але на великих таблицях це забирає багато ресурсів процесора. Якщо для цих таблиць часто виконуються запити UPDATE та DELETE, запуск команди 'OPTIMIZE TABLE' може зменшити кількість та/або прискорити повні сканування індексу. Ще зменшити повне сканування індексу можна тільки шляхом переписування запитів.
Правомірність:
Середнє значення сканування індексу: 33.19 за секунду, це значення має бути меншим ніж 1 на годину
Використана змінна / формула:
Handler_read_first / Uptime
Тест:
value * 60 * 60 > 1
Результат:
Рівень читання даних з фіксованого положення великий.
Рекомендація:
Вказує на те що багато запитів потребують сортування результатів та/або повного сканування таблиці, включно із запитами об'єднання, що не використовують індекси. Додайте індекси, де це можливо.
Правомірність:
Середній рівень читання з фіксованого положення: 87.17 за секунду, це значення повинно бути меншим 1 на годину
Використана змінна / формула:
Handler_read_rnd / Uptime
Тест:
value * 60 * 60 > 1
Результат:
Рівень читань наступного рядка таблиці високий.
Рекомендація:
Показує, скільки запитів виконує повні сканування таблиць. Додайте індекси, де це можливо.
Правомірність:
Рівень читань наступного рядка: 4800.98 за секунду, це значення повинно бути меншим 1 на годину
Використана змінна / формула:
Handler_read_rnd_next / Uptime
Тест:
value * 60 * 60 > 1
Результат:
Багато тимчасових таблиць пишуться на диск замість того, щоб зберігатися в пам'яті.
Рекомендація:
Може допомогти збільшення змінних max_heap_table_size та tmp_table_size. Однак деякі тимчасові таблиці завжди записуються на диск, незалежно від значення цих змінних. Щоб усунути це потрібно переписати запити таким чином, щоб уникнути умов (У тимчасовій таблиці: наявність стовпчика BLOB або TEXT або стовпчика розміром понад 512 байт) згаданих у Документації MySQL
Правомірність:
Рівень тимчасових таблиць, що записуються на диск: 14.29 за годину, це значення має бути меншим 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 допоможе уникнути цього.
Правомірність:
Рівень відкритих таблиць: 1.62 за секунду, має бути меншим, ніж 10 на годину
Використана змінна / формула:
Opened_tables / Uptime
Тест:
value*60*60 > 10
Результат:
Рівень відкритих файлів високий.
Рекомендація:
Розгляньте можливість збільшення open_files_limit та після зміни open_files_limit і перезавантаження перегляньте журнал помилок.
Правомірність:
Рівень відкритих файлів: 57.14 за годину, має бути меншим, ніж 5 на годину
Використана змінна / формула:
Open_files / Uptime
Тест:
value * 60 * 60 > 5