浅谈mysql innodb缓存策略

浅谈mysql innodb缓存策略:

The InnoDB Buffer Pool

Innodb 持有一个存储区域叫做buffer pool是为了在内存中缓存数据和索引,知道innodb bufferpool怎么工作,和利用它读取频繁访问的数据,是mysql优化重要的方面。

理想状况下,把bufferpool的大小调整到足够大,留下足够的内存空间给其他该服务器上的进程(使其无缺页即可)。bufferpool越大,innodb 月表现为内存型数据库,从硬盘上一次读取数据,之后并成了从内存中读取数据。buffer pool甚至缓存那些因为insert,update操作而改变的数据(insert buffer),所以随机磁盘写可以聚集在一块得到更好的性能。

innodb 把缓存池作为链式管理,利用LRU(least recently used)算法,当添加新block到pool中时(无空间),innodb 替换(驱逐)一个最近最少使用的block,然后把新的block添加到链表的中间,"midpoint insertion strategy"策略把链表看出两条子链。

1:在链表的头部,是由一些“NEW”(or "young")block 组成的最近刚被访问的子链;

2:在链表的尾部,是由一些‘old‘ block组成的最近没被访问(或者最少被访问的)的子链;

 该算法使大量查询 blocks 保持在  new sublist. old sublist 持有最少使用的 blocks;这些blocks将成为替换或驱逐的候选者。

1:3/8 的buffer pool 的大小分配给old sublist

2: 链表的 midpoint (中间插入点) 是new sublist 尾部和 old sublist头部聚合的地方

3:当 innodb 读取一个block进 buffer pool时,插入到midpoint(old sublist 的头部),block被读取发生在 客户端操作,eg: sql查询,或者innodb特性 readahead(预读);

4:当访问在old sublist中一个 block时,使其变成‘young‘,把它移动到 buffer pool的头部(new sublist的头部),如果该block 被读取是因为客户端sql查询,则第一次访问立即发生,并且该block变成‘young‘。如果该block被读取是因为read ahead,第一次呗访问不会发生,并且有可能在该Block被替换之前根本不能发生);

5:随着数据库操作,在buffer pool 中的没被访问的blocks(年纪大的)被移动到链表的尾部.在old sublist中的blocks 比插入在midpoint上的block老,最终,一个Block一段长时间未被使用会到达old sublist的尾部会被替换。

默认情况下,被读取的blocks会立即移动到 NEW sublist 的 head,同时意味着他们待着buffer pool中很长一段时间。当扫表时(eg, mysqldump 操作,或者 没有where语句的select操作 )可以使大量的blocks  push into buffer pool中,并且驱逐大量的older 数据,即使那些所谓刚加入的 new blocks 不会再次被访问,相同的,read ahead 后台线程一次载入大量的blocks  ,这些情况使经常被访问的blocks push into 到 old sublist中,然后它们成为被驱逐的候选者。

一些innodb 系统变量控制着buffer pool的大小和使你调整LRU算法

1:innodb buffer pool size

指明Buffer pool的大小,如果你的buffer pool 空间小,并且有充足的空间,使pool大点可以减小磁盘IO的次数来提高性能;

2: innodb buffer pool instances : 分成多个独立的区域,各个区域相同,来减少在并发内存读写操作的竞争;

3:innodb old blocks pct:默认3/8;

4:  innodb old blocks time: 指定多长时间以毫秒为单位(ms),block插入到老子列表必须呆在那里第一次访问后多久,才能搬到新的子列表(解决预读时,缓存污染问题);

检查查询缓存是否存在于你的MySQL服务器:

mysql> show variables like ‘have_query_cache‘;
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+
1 row in set (0.00 sec)

监控查询缓存的性能,使用显示状态查看缓存状态变量:

mysql> show status like ‘qcache%‘;
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 1        |
| Qcache_free_memory      | 16768376 |
| Qcache_hits             | 0        |
| Qcache_inserts          | 0        |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 227      |
| Qcache_queries_in_cache | 0        |
| Qcache_total_blocks     | 1        |
+-------------------------+----------+
8 rows in set (0.00 sec)

  

mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)  

--Qcache_hits表示sql查询在缓存中命中的累计次数,是累加值。
mysql> SHOW STATUS LIKE ‘Qcache_hits‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 0     |  --0次
+---------------+-------+
8 rows in set (0.00 sec)  

mysql>  select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)  

mysql>  SHOW STATUS LIKE ‘Qcache%‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 1     | --表示sql在缓存中直接得到结果,不需要再去解析
+---------------+-------+
8 rows in set (0.00 sec)  

mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)  

mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)  

mysql> SHOW STATUS LIKE ‘Qcache_hits‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 3     |    --上面的sql也是是从缓存中直接取到结果
+---------------+-------+
1 row in set (0.00 sec)  

mysql> insert into animals select 9,‘testsds‘ ; --插入数据后,跟这个表所有相关的sql缓存就会被清空掉
Query OK, 1 row affected (0.00 sec)
Records: 1  Duplicates: 0  Warnings: 0  

mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)  

mysql> SHOW STATUS LIKE ‘Qcache_hits‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 3    |  --还是等于3,说明上一条sql是没有直接从缓存中直接得到的
+---------------+-------+
1 row in set (0.00 sec)  

mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)  

mysql> SHOW STATUS LIKE ‘Qcache_hits‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 4     |
+---------------+-------+
1 row in set (0.00 sec) 
时间: 2024-08-24 22:20:11

浅谈mysql innodb缓存策略的相关文章

浅谈MySQL索引背后的数据结构及算法

摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持 也各不相同,因此MySQL数据库支持多种索引类型,如BTree索引,哈希索引,全文索引等等.为了避免混乱,本文将只关注于BTree索引,因为这是 平常使用MySQL时主要打交道的索引,至于哈希索引和全文索引本文暂不讨论. 文章主要内容分为四个部分. 第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础. 第二部分结合MySQL数据库中

浅谈mysql主从复制的高可用解决方案

1.熟悉几个组件(部分摘自网络)1.1.drbd     —— DRBD(Distributed Replicated Block Device),DRBD号称是 "网络 RAID",开源软件,由 LINBIT 公司开发.DRBD 实际上是一种块设备的实现,主要被用于Linux平台下的高可用(HA)方案之中.他是有内核 模块和相关程序而组成,通过网络通信来同步镜像整个设备,有点类似于一个网络RAID的功能.也就是说当你将数据写入本地的DRBD设备上的文件系统 时, 数据会同时被发送到网

浅谈浏览器的缓存机制

浏览器的缓存可分为HTTP缓存和离线缓存,下面将分别介绍 HTTP缓存 只有GET请求能被缓存,POST不能被缓存.Modified Time/ETag/Expires/Cache都是HTTP协议的缓存策略 先来一个例子 当我们第二次访问百度首页,在Chrome的Network面板中打开一个静态文件时会发现响应的status是:200 OK (from disk cache),不是应该返回304 Not Modified吗?如果你知道答案,那就可以忽略本文了. Cache-Control 简介

浅谈Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景

浅谈Mysql共享锁.排他锁.悲观锁.乐观锁及其使用场景 Mysql共享锁.排他锁.悲观锁.乐观锁及其使用场景 一.相关名词 |--表级锁(锁定整个表) |--页级锁(锁定一页) |--行级锁(锁定一行) |--共享锁(S锁,MyISAM 叫做读锁) |--排他锁(X锁,MyISAM 叫做写锁) |--悲观锁(抽象性,不真实存在这个锁) |--乐观锁(抽象性,不真实存在这个锁) 二.InnoDB与MyISAM Mysql 在5.5之前默认使用 MyISAM 存储引擎,之后使用 InnoDB .查

浅谈加速因子在策略中的意义

他站链接:浅谈加速因子在策略中的意义 NO:01没有完美的交易系统,但是却有完美的交易哲学.交易哲学.交易策略和资金管理三者缺一不可,才能构成正期望的交易系统.投机依赖价格的移动获得盈利(低买高卖或高买更高卖).在上升或下降趋势中,价格虽然在整体上朝着一个方向移动,但中间也会有短暂的反方向移动.而在横盘过程中,价格的移动方向则显得相对"随机"一些. NO:02关于价格的移动,可以类比物理学中的运动.其中包括:位移距离.时间.速度等.价格的位移相对于时间的比率就是价格的速度.除了速度之外

浅谈MySQL存储引擎-InnoDB&MyISAM

存储引擎在MySQL的逻辑架构中位于第三层,负责MySQL中的数据的存储和提取.MySQL存储引擎有很多,不同的存储引擎保存数据和索引的方式是不同的.每一种存储引擎都有它的优势和劣势,本文只讨论最常见的InnoDB和MyISAM两种存储引擎进行讨论.本文中关于数据存储形式和索引的可以查看图解MySQL索引 MySQL逻辑架构图: InnoDB存储引擎 InnoDB是默认的事务型存储引擎,也是最重要,使用最广泛的存储引擎.在没有特殊情况下,一般优先使用InnoDB存储引擎. 1??.数据存储形式

运维角度浅谈MySQL数据库优化

一个成熟的数据库架构并不是一开始设计就具备高可用.高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善.这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 1.数据库表设计 项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验.影响的因素很多,比如慢查询.低效的查询语句.没有适当建立索引.数据库堵塞(死锁)等.当然,有测试工程师的团队

浅谈MySQL数据库优化

一个成熟的数据库架构并不是一开始设计就具备高可用.高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善.这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 1.数据库表设计 项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验.影响的因素很多,比如慢查询.低效的查询语句.没有适当建立索引.数据库堵塞(死锁)等.当然,有测试工程师的团队

(转)运维角度浅谈MySQL数据库优化

转自:http://lizhenliang.blog.51cto.com/7876557/1657465 一个成熟的数据库架构并不是一开始设计就具备高可用.高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善.这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 1.数据库表设计 项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验.影