Since MariaDB Galera cluster versions 5.5.40 and 10.0.14 you can use the query cache. Earlier versions do NOT support the query cache.
http://www.fromdual.com/regularly-flushing-mysql-query-cache
Mariadb 5.5.31 and the new incredible query cache information plugin
Hi guys, i was reading the new query cache plugin from Roland Bouman, now default in mariadb-5.5.31
This is a very old feature request at mysql (27 Oct 2006 12:31):
http://bugs.mysql.com/bug.php?id=23714
And recent mariadb (thanks Sergei reading my MDEV =) ) (2012-05-04 01:22)
https://mariadb.atlassian.net/browse/MDEV-249
Well this is a very nice piece of code...
Every time i google about "mysql performace", "mysql cache" etc ... i get something like this:
http://www.cyberciti.biz/tips/how-does-query-caching-in-mysql-works-and-how-to-find-find-out-my-mysql-query-cache-is-working-or-not.html
or this:
http://stackoverflow.com/questions/4139936/query-cache-efficiency
But... What global statistics tell you about your specific query? How
you know if your query is cached? You can do this via status variables,
but you may not know if your cache have a good global cache hit for only
one query, or only one database.
Well mariadb plugin tell you some infomations about what you need... but
less information that might be usefull for a good query/table statistic
You can read the query and the size of query in cache memory. What this
tell about "is my query qith a high hit rate?"? hum... this tell you
have the query inside query cache, that's the only information...
Reading more and studying mariadb source code, i created a patch... at MDEV-4581 (https://mariadb.atlassian.net/browse/MDEV-4581), ok mariadb guys i don't know how to use lauchpad to help mariadb yet, but you can use the patch =)
well i will not explain statistics, let's show the results for 4 queries in cache:
SELECT
query_hits/(select max(query_hits) from query_cache_queries)*100 as p_query_hit,
select_expend_time_ms/(select max(select_expend_time_ms) from query_cache_queries)*100 as p_select_expend_time_ms,
select_rows_read/(select max(select_rows_read) from query_cache_queries)*100 AS p_select_rows_read,
result_found_rows/(select max(result_found_rows) from query_cache_queries)*100 AS p_result_found_rows,
select_rows_read/(select max(select_rows_read) from query_cache_queries)*100 AS p_select_rows_read,
`ENTRY_POSITION_IN_CACHE`,
`STATEMENT_SCHEMA`,
`STATEMENT_TEXT`,
`RESULT_FOUND_ROWS`, `QUERY_HITS`, `SELECT_EXPEND_TIME_MS`,
`SELECT_LOCK_TIME_MS`, `SELECT_ROWS_READ`, `TABLES`,
from_unixtime(`QUERY_INSERT_TIME`)
as time, `RESULT_LENGTH`, `RESULT_BLOCKS_COUNT`,
`RESULT_BLOCKS_SIZE`, `RESULT_BLOCKS_SIZE_USED`, `RESULT_TABLES_TYPE`,
`FLAGS_CLIENT_LONG_FLAG`, `FLAGS_CLIENT_PROTOCOL_41`,
`FLAGS_PROTOCOL_TYPE`, `FLAGS_MORE_RESULTS_EXISTS`, `FLAGS_IN_TRANS`,
`FLAGS_AUTOCOMMIT`, `FLAGS_PKT_NR`, `FLAGS_CHARACTER_SET_CLIENT_NUM`,
`FLAGS_CHARACTER_SET_RESULTS_NUM`, `FLAGS_COLLATION_CONNECTION_NUM`,
`FLAGS_LIMIT`, `FLAGS_SQL_MODE`, `FLAGS_MAX_SORT_LENGTH`,
`FLAGS_GROUP_CONCAT_MAX_LEN`, `FLAGS_DIV_PRECISION_INCREMENT`,
`FLAGS_DEFAULT_WEEK_FORMAT`
FROM `information_schema`.`QUERY_CACHE_QUERIES`
ORDER BY statement_schema,`QUERY_HITS`
You can see the result if you have a very very big monitor =)
| p_query_hit | p_select_expend_time_ms | p_select_rows_read | p_result_found_rows | p_select_rows_read | ENTRY_POSITION_IN_CACHE | STATEMENT_SCHEMA | STATEMENT_TEXT | RESULT_FOUND_ROWS | QUERY_HITS | SELECT_EXPEND_TIME_MS | SELECT_LOCK_TIME_MS | SELECT_ROWS_READ | TABLES | time | RESULT_LENGTH | RESULT_BLOCKS_COUNT | RESULT_BLOCKS_SIZE | RESULT_BLOCKS_SIZE_USED | RESULT_TABLES_TYPE | FLAGS_CLIENT_LONG_FLAG | FLAGS_CLIENT_PROTOCOL_41 | FLAGS_PROTOCOL_TYPE | FLAGS_MORE_RESULTS_EXISTS | FLAGS_IN_TRANS | FLAGS_AUTOCOMMIT | FLAGS_PKT_NR | FLAGS_CHARACTER_SET_CLIENT_NUM | FLAGS_CHARACTER_SET_RESULTS_NUM | FLAGS_COLLATION_CONNECTION_NUM | FLAGS_LIMIT | FLAGS_SQL_MODE | FLAGS_MAX_SORT_LENGTH | FLAGS_GROUP_CONCAT_MAX_LEN | FLAGS_DIV_PRECISION_INCREMENT | FLAGS_DEFAULT_WEEK_FORMAT |
| null | 100 | 1,7857 | 3,5714 | 1,7857 | 0 | dev_cadastros | SELECT SQL_CACHE SQL_SMALL_RESULT moeda FROM moedas | 1 | 0 | 1 | 0 | 1 | `dev_cadastros`.`moedas` | 2013-05-25 22:35:52.000 | 91 | 1 | 512 | 155 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 8 | 8 | 8 | -1 | 33554434 | 1024 | 1024 | 4 | 0 |
| null | 100 | 100 | 100 | 100 | 1 | dev_cadastros | SELECT indice,nome,grupo FROM analise_credito_indices ORDER BY grupo,ordem | 28 | 0 | 1 | 1 | 56 | `dev_cadastros`.`analise_credito_indices` | 2013-05-25 22:35:52.000 | 1234 | 1 | 1304 | 1298 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 8 | 8 | 8 | -1 | 33554434 | 1024 | 1024 | 4 | 0 |
| null | 0 | 1,7857 | 3,5714 | 1,7857 | 2 | shared | SELECT SQL_CACHE SQL_SMALL_RESULT inteiro,inteiros,centavo,centavos,decimais,precisao_fatores,cod_bcb,ultima_alteracao,nome FROM moedas_atual WHERE moeda="R$" | 1 | 0 | 0 | 0 | 1 | `shared`.`moedas_atual` | 2013-05-25 22:35:52.000 | 759 | 1 | 824 | 823 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 8 | 8 | 8 | -1 | 33554434 | 1024 | 1024 | 4 | 0 |
| null | 0 | 1,7857 | 3,5714 | 1,7857 | 3 | shared | SELECT SQL_CACHE SQL_SMALL_RESULT fator_venda,fator_compra,ultima_alteracao,nome FROM moedas_atual WHERE moeda="R$" | 1 | 0 | 0 | 0 | 1 | `shared`.`moedas_atual` | 2013-05-25 22:35:52.000 | 393 | 1 | 512 | 457 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 8 | 8 | 8 | -1 | 33554434 | 1024 | 1024 | 4 | 0 |
------------
ok you don't have a 180" monitor? here the columns:
p_query_hit
p_select_expend_time_ms
p_select_rows_read
p_result_found_rows
p_select_rows_read
ENTRY_POSITION_IN_CACHE
STATEMENT_SCHEMA
STATEMENT_TEXT
RESULT_FOUND_ROWS
QUERY_HITS
SELECT_EXPEND_TIME_MS
SELECT_LOCK_TIME_MS
SELECT_ROWS_READ
TABLES
time (it return as unixtime stamp) => QUERY_INSERT_TIME
RESULT_LENGTH
RESULT_BLOCKS_COUNT
RESULT_BLOCKS_SIZE
RESULT_BLOCKS_SIZE_USED
RESULT_TABLES_TYPE
FLAGS_CLIENT_LONG_FLAG
FLAGS_CLIENT_PROTOCOL_41
FLAGS_PROTOCOL_TYPE
FLAGS_MORE_RESULTS_EXISTS
FLAGS_IN_TRANS
FLAGS_AUTOCOMMIT
FLAGS_PKT_NR
FLAGS_CHARACTER_SET_CLIENT_NUM
FLAGS_CHARACTER_SET_RESULTS_NUM
FLAGS_COLLATION_CONNECTION_NUM
FLAGS_LIMIT
FLAGS_SQL_MODE
FLAGS_MAX_SORT_LENGTH
FLAGS_GROUP_CONCAT_MAX_LEN
FLAGS_DIV_PRECISION_INCREMENT
FLAGS_DEFAULT_WEEK_FORMAT
------------
What more you need now?
You can see: how many hits you have in each query
How many time it take to execute if your query cache entry is "lost"
How many rows it read to result and many, many, many others informations
What's the oldest query entry
Humm do you want know what query in table X?
select * from information_schema.query_cache_queries where tables like "%´my_database´.´my_table´%"
And you got all queries from that table
You can do many things now =)
Now, we have a nice (very nice) tool to improve query cache statistics =)
Thanks Sergei from Mariadb with mariadb source code help, and many many thanks to Roland Bouman with this nice peace of code
New life to query cache!