mariadb cache1
http://www.percona.com/blog/2006/07/27/mysql-query-cache/
MySQL Query Cache
July 27, 2006 by Peter Zaitsev 74 Comments
MySQL has a great feature called “Query Cache” which is quite helpful for MySQL Performance optimization tasks but there are number of things you need to know.
First let me clarify what MySQL Query Cache is – I’ve seen number of people being confused, thinking MySQL Query Cache is the same as Oracle Query Cache – meaning cache where execution plans are cached. MySQL Query Cache is not. It does not cache the plan but full result sets. This means it is much more efficient as query which required processing millions of rows now can be instantly summoned from query cache. It also means query has to be exactly the same and deterministic, so hit rate would generally be less. In any case it is completely different.
Query cache is great for certain applications, typically simple applications deployed on limited scale or applications dealing with small data sets. For example I’m using Query Cache on server which runs this blog. Updates are rather rare so per-table granularity is not the problem, I have only one server and number of queries is small so cache duplication is not the problem. Finally I do not want to hack wordpress to support eaccelerator cache or memcached. Well honestly speaking if performance would be problem I should have started with full page caching rather than MySQL level caching but it is other story.
Lets talk a bit about features and limitations of Query Cache:
Transparent Caching – Caching is fully transparent to the application, and what is very important it does not change semantics of the queries – you always get actual query results. Really there are some chevats – if you’re not using query_cache_wlock_invalidate=ON locking table for write would not invalidate query cache so you can get results even
if table is locked and is being prepared to be updated. So if you’re
using query cache in default configuration you can’t assume locking
table for write will mean no one will be able to read it – results still
can come from query cache unless you enable
query_cache_wlock_invalidate=ON.
Caching full queries only – Meaning it does not work for subselects, inline views, parts of the UNION. This is also common missunderstanding.
Works on packet level
– This is one of the reason for previous item. Query cache catches
network packets as they sent from client to the server, which means it
can serve responses very fast doing no extra conversion or processing.
Works before parsing
– One more reason for high performance is Query Cache performs query
lookup in the cache before query parsing, so if result is served from
query cache, query parsing step is saved.
Queries must be absolutely the same
As no parsing is done before lookup queries are not normalized (would
require parsing) before cache lookup, so they have to match byte by
byte for cache hit to happen. This means if you would place dynamic
comments in the query, have extra space or use different case – these
would be different queries for query cache.
Only SELECT queries are cached
SHOW commands or stored procedure calls are not, even if stored
procedure would simply preform select to retrieve data from table.
Avoid comment (and space) in the start of the query
– Query Cache does simple optimization to check if query can be cached.
As I mentioned only SELECT queries are cached – so it looks at first
letter of the query and if it is “S” it proceeds with query lookup in
cache if not – skips it.
Does not support prepared statements and cursors
Query Cache works with query text and want full result set at once. In
prepared statements there is query with placeholders and additional
parameter values which would need extra care – it is not implemented.
Cursors get data in chunks so it is even harder to implement.
Might not work with transactions
– Different transactions may see different states of the database,
depending on the updates they have performed and even depending on
snapshot they are working on. If you’re using statements outside of
transaction you have best chance for them to be cached.
Query must be deterministic
– Query might provide same result no matter how many times it is run,
if data remains the same. So if query works with current data, uses
non-deterministic functions such as UUID(), RAND(), CONNECTION_ID() etc
it will not be cached.
Table level granularity in invalidation
– If table gets modification all queries derived from this table are
invalidated at once. Most of them quite likely would not have change
their result set but MySQL has no way to identify which one of them
would so it gets rid of all of them. This is one of the main features
which limits query cache effectiveness – if you have high write
application such as forums, query cache efficiency might be pretty low
due to this. There is also way to set minimal TTL or anything like it
which is allowed by other caching systems. Also note – all queries are
removed from cache on table modifications – if there are a lot of
queries being cached this might reduce update speed a bit.
Fragmentation over time – Over time Query Cache might get fragmented, which reduces performance. This can be seen as large value of Qcache_free_blocks relatively to Qcache_free_memory. FLUSH QUERY CACHE
command can be used for query cache defragmentation but it may block
query cache for rather long time for large query caches, which might be
unsuitable for online applications.
Limited amount of usable memory
– Queries are constantly being invalidated from query cache by table
updates, this means number of queries in cache and memory used can’t
grow forever even if your have very large amount of different queries
being run. Of course in some cases you have tables which are never
modified which would flood query cahe but it unusual. So you might want
to set query cache to certain value and watch Qcache_free_memory and Qcache_lowmem_prunes
– If you’re not getting much of lowmem_prunes and free_memory stays
high you can reduce query_cache appropriately. Otherwise you might wish
to increase it and see if efficiency increases.
Demand operating mode
If you just enable qury cache it will operate in “Cache everything”
mode. In certain caches you might want to cache only some of the
queries – in this case you can set query_cache_type to “DEMAND” and use only SQL_CACHE hint for queries which you want to have cached – such as SELECT SQL_CACHE col from foo where id=5.
If you run in default mode you can also use SQL_NO_CACHE to block
caching for certain queries, which you know do not need to be cached.
Counting query cache efficiency There are few ways you can look at query_cache efficiency. First looking at number of your selects – Com_select and see how many of them are cached. Query Cache efficiency would be Qcache_hits/(Com_select+Qcache_hits).
As you can see we have to add Qcache_hits to Com_select to get total
number of queries as if query cache hit happens Com_select is not
incremented. But if you have just 20% Cache hit rate does it mean
it is not worth it ? Not really it depends on which queries are cached,
as well as overhead query cache provides. One portion of query cache
overhead is of course inserts so you can see how much of inserted
queries are used: Qcache_hits/Qcache_inserts Other portion of overhead comes from modification statements which you can calculate by (Com_insert+Com_delete+Com_update+Com_replace)/Qcache_hits
.
These are some numbers you can play with but it is hard to tell what
is good or bad as a lot depends on statement complexity as well as how
much work is saved by query cache.
Now lets speak a bit about Query Cache configuration and mainance. MySQL Manual is pretty good on this: Query Cache Query Cache Status Query Cache Configuration
I would just mention couple of points – as protection from one query wiping your all query cache option query_cache_limit
was implemented which limits result set which can be stored in query
cache. If you need larger queries to be cached you might increase it,
if you most important queries are smaller you can decrease it. The
other one is Qcache_lowmem_prunes – This one is used to
identify if you have enough memory for query cache. Note however due to
fragmentation lowmem_prunes can be triggered even if there is some
free space, just badly fragmented.
Looking at performance I’ve
seen query cache offering about double performance for simple queries
with select done by primary key, obviously there is no upper boundary –
Very complex queries producing small result set will be offering best
speed up.
So when it is good idea to use query cache ?
Third party application – You can’t change how it works with MySQL to add caching but you can enable query cache so it works faster.
Low load applications
– If you’re building application which is not designed for extreme
load, like many personal application query cache might be all you need.
Especially if it is mostly read only scenario.
Why Look for alternatives ?
There are few reasons why Query Cache might be not cache for your application:
It caches queries
Application objects might need several queries to compose so it is
efficient to cache whole objects rather than individual queries.
No control on invalidation
Table granularity is often too bad. With other caches you may
implement version based or timeout based invalidation which can offer
much better hit ratio for certain application.
It is not that fast Query Cache is fast compared to running the queries but it is still not as fast as specially designed systems such as memcached or local shared memory.
It can’t retrieve multiple objects at the same time
You have to query cache object by object which adds latency, there is
no way you can request all objects you need to be retrieved at the same
time (again memcached has it)
It is not distributed
If you have 10 slaves and use query cache on all of them cache content
will likely be the same, so you have multiple copies of the same data in
cache effectively wasting memory. Distirbuted caching systems can
effectively use memory on multiple systems so there is no duplication.
Memcached
is probably the most popular distributed caching system and it works
great. I should write an article comparing performance of various
caching systems some time.
mariadb cache1的更多相关文章
- Docker笔记一:基于Docker容器构建并运行 nginx + php + mysql ( mariadb ) 服务环境
首先为什么要自己编写Dockerfile来构建 nginx.php.mariadb这三个镜像呢?一是希望更深入了解Dockerfile的使用,也就能初步了解docker镜像是如何被构建的:二是希望将来 ...
- 续 CentOS7(mini) 运行MVC5 + Mariadb
上一篇,介绍了在CentOS7上使用mono官方二进制安装包快速安装mono环境 并且成功运行了一个Owin自宿主应用(Booker) 由于Owin自宿主应用不需要System.Web的支持,所以可以 ...
- 读书笔记--SQL必知必会--常用MySQL(MariaDB)命令
DBMS信息 显示DBMS的版本 select version(); 显示DBMS状态 status; 显示DBMS资源状态 show status; 显示DBMS支持的权限 show privile ...
- 从MySQL 5.5迁移到Mariadb 10.1.14
从MySQL 5.5迁移到Mariadb 10.1.14 迁移计划如下: 1.备份MySQL 5.5的数据库,对指定库进行备份. 2.还原到Mariadb,然后建立复制. 3.然后就可以愿意啥时候切换 ...
- mariadb数据库忘记密码如何找回
1.systemctl stop mariadb ==>停止mariadb数据库 2.mysqld_safe --skip-grant-tables & ==>进入单机模式 3.m ...
- CentOS 7 x64下Apache+MySQL(Mariadb)+PHP56的安装
每次搭建新服务器,都要来来回回把这些包再装一下,来来回回搞了不下20遍了吧,原来都是凭经验,配置过程中重复入坑是难免的,故写此文做个备忘.虽然有像xampp这样的集成包,但是在生产环境的Linux发行 ...
- Ubuntu 16.04 LAMP server 指南 - 配置 Apache2.4,PHP7,和MariaDB(而不是MySQL)
翻译自:https://www.howtoforge.com/tutorial/install-apache-with-php-and-mysql-on-ubuntu-16-04-lamp/ 昨天在虚 ...
- CentOS 7.0 使用 yum 安装 MariaDB 与 MariaDB 的简单配置
1.安装MariaDB 安装命令 yum -y install mariadb mariadb-server 安装完成MariaDB,首先启动MariaDB,两条命令都可以 systemctl sta ...
- MySQL/MariaDB/PerconaDB-提权条件竞争漏洞
背景 2016年11月01日,国外安全研究员Dawid Golunski在 MySQl, MariaDB 和 PerconaDB 数据库中发现条件竞争漏洞,该漏洞允许本地用户使用低权限(CREATE/ ...
随机推荐
- 贝叶斯分类器(Bayes分类器)
贝叶斯(Bayes)定理 (条件概率) 贝叶斯分类器(Bayes分类器) 1概念: 将每个属性及类别标记视为随机变量 给定一个具有属性集合(A1, A2,…,An)的记录 目标是预测 ...
- hosts.deny 和hosts.allow 配置不生效
需求:需要用hosts.deny限制用户通过ssh登录 在/etc/hosts.deny中加入 sshd: all 在/etc/hosts.allow中加入 sshd:all #拒绝所有的ip链接ss ...
- spring XML格式
使用spring遇见一个很坑的问题,在XML中 这样配置: <method name="newSoapParam2" parameters="java.lang.S ...
- mysql免安装版使用方法
1.下载并解压mysql免安装版至自定义目录 2.添加环境变量 变量名:MYSQL_HOME 变量值:D:\Program Files\mysql-5.6.11-winx64 即为mysql的自定义解 ...
- white-space详解
white-space共有5种属性normal,nowrap,pre,pre-wrap,pre-line 网上的解释多半过于详细冗长,先做个简化处理,以便查询 normal 忽略空白 过长换行 ...
- Swift\本地文件管理
转载自:http://www.coloroud.com/2015/06/01/Swift-File-Manager/ 开头 看来Swift这趟浑水是非干不可,既然如此,那索性就来的彻底吧,来一次全方位 ...
- 转:浅谈手机app测试注意点
现在我们测试时,开发会先在本地机上打好测试包,自己安装,轮完一轮,开发修改好后,再打一个包.以下是功能测试时需要注意的点: 1.登录 ●登录用户名和密码错误时,界面有提示信息 ●用户主动退出登录后,下 ...
- Discuz登录慢、退出也慢的原因?
Discuz登录慢.退出也慢的原因? 2009-02-21 12:50:11 分类: 转载自:http://www.aiseminar.cn/bbs/thread-201-1-1.html 由于服务 ...
- ViewPager+Fragment,Fragment会预加载的问题
http://www.bubuko.com/infodetail-535920.html 在Fragmetn里,onCreateView去加载布局,真正的加载数据通过这个方法setUserVisibl ...
- eclipse快捷键(转载)
Ctrl+1 快速修复(最经典的快捷键,就不用多说了)Ctrl+D: 删除当前行 Ctrl+Alt+↓ 复制当前行到下一行(复制增加)Ctrl+Alt+↑ 复制当前行到上一行(复制增加)Alt+↓ 当 ...