1#@!#!123s

: / usr / share / phpmyadmin / libraries /
Filename : advisory_rules_mysql_before80003.txt
back
# phpMyAdmin Advisory rules file
#
# See doc in advisory_rules_generic.txt
#

#
# Query cache

# Lame: 'ON' == 0 is true, so you need to compare 'ON' == '0'
rule 'Query cache disabled'
	query_cache_size
	value == 0 || query_cache_type == 'OFF' || query_cache_type == '0'
	The query cache is not enabled.
	The query cache is known to greatly improve performance if configured correctly. Enable it by setting {query_cache_size} to a 2 digit MiB value and setting {query_cache_type} to 'ON'. <b>Note:</b> If you are using memcached, ignore this recommendation.
	query_cache_size is set to 0 or query_cache_type is set to 'OFF'

rule 'Query cache efficiency (%)' [Com_select + Qcache_hits > 0 && !fired('Query cache disabled')]
	Qcache_hits / (Com_select + Qcache_hits) * 100
	value  < 20
	Query cache not running efficiently, it has a low hit rate.
	Consider increasing {query_cache_limit}.
	The current query cache hit rate of %s% is below 20% | round(value,1)

rule 'Query Cache usage' [!fired('Query cache disabled')]
	100 - Qcache_free_memory / query_cache_size * 100
	value < 80
	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 %s%. It should be above 80% | round(value,1)

rule 'Query cache fragmentation' [!fired('Query cache disabled')]
	Qcache_free_blocks / (Qcache_total_blocks / 2) * 100
	value > 20
	The query cache is considerably fragmented.
	Severe fragmentation is likely to (further) increase Qcache_lowmem_prunes. This might be caused by many Query cache low memory prunes due to {query_cache_size} being too small. For a immediate but short lived fix you can flush the query cache (might lock the query cache for a long time). Carefully adjusting {query_cache_min_res_unit} to a lower value might help too, e.g. you can set it to the average size of your queries in the cache using this formula: (query_cache_size - qcache_free_memory) / qcache_queries_in_cache
	The cache is currently fragmented by %s% , with 100% fragmentation meaning that the query cache is an alternating pattern of free and used blocks. This value should be below 20%. | round(value,1)

rule 'Query cache low memory prunes' [Qcache_inserts > 0 && !fired('Query cache disabled')]
	Qcache_lowmem_prunes / Qcache_inserts * 100
	value > 0.1
	Cached queries are removed due to low query cache memory from the query cache.
	You might want to increase {query_cache_size}, however keep in mind that the overhead of maintaining the cache is likely to increase with its size, so do this in small increments and monitor the results.
	The ratio of removed queries to inserted queries is %s%. The lower this value is, the better (This rules firing limit: 0.1%) | round(value,1)

rule 'Query cache max size' [!fired('Query cache disabled')]
	query_cache_size
	value > 1024 * 1024 * 128
	The query cache size is above 128 MiB. Big query caches may cause significant overhead that is required to maintain the cache.
	Depending on your environment, it might be performance increasing to reduce this value.
	Current query cache size: %s | ADVISOR_formatByteDown(value, 2, 2)

rule 'Query cache min result size' [!fired('Query cache disabled')]
	query_cache_limit
	value == 1024*1024
	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