Drop files here

SQL ატვირთვა ( 0 ) x -

გვერდის პარამეტრები Click on the bar to scroll to top of page
მოთხოვნის შესასრულებლად დააჭირეთ Ctrl+Enter მოთხოვნის შესასრულებლად დააჭირეთ Enter
ზრდადობით
კლებადობით
დალაგება:
Debug SQL
რაოდენობა
გაშვების მიმდევრობა
Time taken
დალაგება:
ჯგუფური მოთხოვნები
მოთხოვნების განჯგუფება
ჩაკეცვა ამოკეცვა ტრეისის ჩვენება ტრეისის დამალვა რაოდენობა: Time taken:
სანიშნები
განახლება
დამატება
სანიშნების გარეშე
სანიშნის დამატება
პარამეტრები
ნაგულისხმევი მნიშვნელობების აღდგენა
ჩაკეცვა ამოკეცვა თავიდან მოთხოვნა რედაქტირება ახსნა Profiling სანიშნი მოთხოვნის შეცდომა მონაცემთა ბაზა: გამოთხოვილი დრო:

მრჩეველი სისტემა

Possible performance issues

პრობლემა:
Uptime is less than 1 day, performance tuning may not be accurate.
რეკომენდაცია:
To have more accurate averages it is recommended to let the server run for longer than a day before running this analyzer
ახსნა:
The uptime is only 0 დღე, 1 საათი, 33 წუთი და 50 წამი
Used variable / formula:
Uptime
ტესტი:
value < 86400
პრობლემა:
long_query_time is set to 10 seconds or more, thus only slow queries that take above 10 seconds are logged.
რეკომენდაცია:
It is suggested to set long_query_time to a lower value, depending on your environment. Usually a value of 1-5 seconds is suggested.
ახსნა:
long_query_time is currently set to 10s.
Used variable / formula:
long_query_time
ტესტი:
value >= 10
პრობლემა:
ნელი მოთხოვნების ჟურნალი გათიშულია.
რეკომენდაცია:
Enable slow query logging by setting slow_query_log to 'ON'. This will help troubleshooting badly performing queries.
ახსნა:
slow_query_log is set to 'OFF'
Used variable / formula:
slow_query_log
ტესტი:
value == 'OFF'
პრობლემა:
There are lots of rows being sorted.
რეკომენდაცია:
While there is nothing wrong with a high amount of row sorting, you might want to make sure that the queries which require a lot of sorting use indexed columns in the ORDER BY clause, as this will result in much faster sorting.
ახსნა:
Sorted rows average: 7.66 წამში
Used variable / formula:
Sort_rows / Uptime
ტესტი:
value * 60 >= 1
პრობლემა:
მეტისმეტად ბევრი შეერთება ინდექსების გარეშე.
რეკომენდაცია:
This means that joins are doing full table scans. Adding indexes for the columns being used in the join conditions will greatly speed up table joins.
ახსნა:
ცხრილების შეერთება საშუალოდ: 11.17 წამში. ეს მნიშვნელობა საათში ერთზე ნაკლები არ უნდა იყოს
Used variable / formula:
(Select_range_check + Select_scan + Select_full_join) / Uptime
ტესტი:
value * 60 * 60 > 1
პრობლემა:
პირველი ინდექსის ჩანაწერის წაკითხვის სიხშირე მაღალია.
რეკომენდაცია:
This usually indicates frequent full index scans. Full index scans are faster than table scans but require lots of CPU cycles in big tables, if those tables that have or had high volumes of UPDATEs and DELETEs, running 'OPTIMIZE TABLE' might reduce the amount of and/or speed up full index scans. Other than that full index scans can only be reduced by rewriting queries.
ახსნა:
ინდექსის სკანირების საშუალო: 28.84 წუთში ეს მნიშვნელობა საათში ერთზე ნაკლები უნდა იყოს
Used variable / formula:
Handler_read_first / Uptime
ტესტი:
value * 60 * 60 > 1
პრობლემა:
ფიქსირებული პოზიციებიდან მონაცემების წაკითხვის სიხშირე მაღალია.
რეკომენდაცია:
This indicates that many queries need to sort results and/or do a full table scan, including join queries that do not use indexes. Add indexes where applicable.
ახსნა:
Rate of reading fixed position average: 7.62 წამში, this value should be less than 1 per hour
Used variable / formula:
Handler_read_rnd / Uptime
ტესტი:
value * 60 * 60 > 1
პრობლემა:
შემდეგი ცხრილის მწკრივის წაკითხვის სიხშირე მაღალია.
რეკომენდაცია:
This indicates that many queries are doing full table scans. Add indexes where applicable.
ახსნა:
შემდეგი ცხრილის მწკრივის კითხვის სიხშირე: 289.95 წამში. ეს მნიშვნელობა საათში ერთზე ნაკლები უნდა იყოს
Used variable / formula:
Handler_read_rnd_next / Uptime
ტესტი:
value * 60 * 60 > 1
პრობლემა:
Many temporary tables are being written to disk instead of being kept in memory.
რეკომენდაცია:
Increasing max_heap_table_size and tmp_table_size might help. However some temporary tables are always being written to disk, independent of the value of these variables. To eliminate these you will have to rewrite your queries to avoid those conditions (Within a temporary table: Presence of a BLOB or TEXT column or presence of a column bigger than 512 bytes) as mentioned in the MySQL Documentation
ახსნა:
Rate of temporary tables being written to disk: 51.1 წუთში, this value should be less than 1 per hour
Used variable / formula:
Created_tmp_disk_tables / Uptime
ტესტი:
value * 60 * 60 > 1
პრობლემა:
MyISAM-ის გასაღების ბაფერის (ინდექსის კეში) გამოყენების % დაბალია.
რეკომენდაცია:
You may need to decrease the size of key_buffer_size, re-examine your tables to see if indexes have been removed, or examine queries and expectations about what indexes are being used.
ახსნა:
მაქს % MyISAM-ის გასაღების ბაფერი, რომელიც არასდროს გამოყენებულა: 0%. ეს მნიშვნელობა 95%-ზე მეტი უნდა იყოს
Used variable / formula:
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
ტესტი:
value < 95
პრობლემა:
ცხრილების გახსნის სიხშირე მაღალია.
რეკომენდაცია:
Opening tables requires disk I/O which is costly. Increasing table_open_cache might avoid this.
ახსნა:
ცხრილის გახსნის სიხშირე: 1.61 წუთში. ეს მნიშვნელობა საათში 10-ზე ნაკლები უნდა იყოს
Used variable / formula:
Opened_tables / Uptime
ტესტი:
value*60*60 > 10
პრობლემა:
ფაილების გახსნის სიხშირე მაღალია.
რეკომენდაცია:
Consider increasing open_files_limit, and check the error log when restarting after changing open_files_limit.
ახსნა:
ფაილების გახსნის სიხშირე: 37.73 საათში. ეს მნიშვნელობა საათში 5-ზე ნაკლები უნდა იყოს
Used variable / formula:
Open_files / Uptime
ტესტი:
value * 60 * 60 > 5
პრობლემა:
შეწყვეტილია მეტისმეტად ბევრი შეერთება.
რეკომენდაცია:
Connections are usually aborted when they cannot be authorized. This article might help you track down the source.
ახსნა:
Aborted connections rate is at 2.56 საათში, this value should be less than 1 per hour
Used variable / formula:
Aborted_connects / Uptime
ტესტი:
value * 60 * 60 > 1
პრობლემა:
Less than 80% of the query cache is being utilized.
რეკომენდაცია:
This might be caused by query_cache_limit being too low. Flushing the query cache might help as well.
ახსნა:
The current ratio of free query cache memory to total query cache size is 9%. It should be above 80%
Used variable / formula:
100 - Qcache_free_memory / query_cache_size * 100
ტესტი:
value < 80
პრობლემა:
The max size of the result set in the query cache is the default of 1 MiB.
რეკომენდაცია:
Changing query_cache_limit (usually by increasing) may increase efficiency. This variable determines the maximum size a query result may have to be inserted into the query cache. If there are many query results above 1 MiB that are well cacheable (many reads, little writes) then increasing query_cache_limit will increase efficiency. Whereas in the case of many query results being above 1 MiB that are not very well cacheable (often invalidated due to table updates) increasing query_cache_limit might reduce efficiency.
ახსნა:
query_cache_limit is set to 1 MiB
Used variable / formula:
query_cache_limit
ტესტი:
value == 1024*1024