phpmyadmin working

1 files changed, 57 insertions, 0 deletions

diff --git a/srcs/phpmyadmin/libraries/advisory_rules_mysql_before80003.txt b/srcs/phpmyadmin/libraries/advisory_rules_mysql_before80003.txt
new file mode 100644
index 0000000..e28b7f4
--- /dev/null
+++ b/srcs/phpmyadmin/libraries/advisory_rules_mysql_before80003.txt
@@ -0,0 +1,57 @@
+# 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