Mysql innodb_buffer_pool_size的研究

在mysql的配置文件中,又一个配置选项:

innodb_buffer_pool_size的配置选项:

innodb_buffer_pool_size参数表示缓冲池字节大小,InnoDB缓存表和索引数据的内存区域。mysql默认的值是128M。

 查看命令:

  

show  variables  LIKE ‘%innodb_buffer_pool_size%‘;

结果:

  

对于值的计算: 134217728[byte]/1024[kb]/1024[MB]=128M 也就是说,mysql默认的innodb_buffer_pool_size的大小为128M

时间: 2024-11-06 16:37:03

Mysql innodb_buffer_pool_size的研究的相关文章

MYSQL开发性能研究——批量插入的优化措施

一.我们遇到了什么问题 在标准SQL里面,我们通常会写下如下的SQL insert语句. INSERT INTO TBL_TEST (id) VALUES(1);   很显然,在MYSQL中,这样的方式也是可行的.但是当我们需要批量插入数据的时候,这样的语句却会出现性能问题.例如说,如果有需要插入100000条数据,那么就需要有100000条insert语句,每一句都需要提交到关系引擎那里去解析,优化,然后才能够到达存储引擎做真的插入工作. 正是由于性能的瓶颈问题,MYSQL官方文档也就提到了使

mysql数据库中间件研究

随着互联网的发展,数据量的不断增大. 单台实例已经远远无法满足业务的需要. 对数据库分库分表的需求不断的增加随之而来的就是数据库中间件的开发. 一. 单台实例主要面临下面几个问题: 1.  数据量太大单台机器无法承载 2.  数据查询效率太低,单表数据达到一定的量业务性能就无法满足 3.  数据库优化上的瓶颈 4. 数据安全的问题,大量数据放置在一台机器如果数据出问题回复周期会特别长,对业务影响太大. 随之而来的就是需要分库分表 但是分库分表就四个字做起来可真没有这么简单. 二. 分库分表面临的

mysql高可用研究之主从+MHA架构

最近在研究mysql的高可用架构,自己想总结下常用的高可用方案都有哪些.有哪些优缺点以及应用的场景?搞得是头昏脑涨,天昏地暗,看了诸多资料,每次都觉得公说公有理婆说婆有理.其实嘛,大家都没有说错,只不过适合自己的才是最正确的选择.今天就从比较常用的主从+MHA说起. 学习一种新的架构还是软件,最好还是先从了解它的原理开始,这样才能在做实验时测试出它的优势和弱势. ###################################################################

mysql高可用研究(二) 主从+MHA+Atlas

关于Atlas的详细介绍请访问:https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md 为什么要使用Atlas?应用程序直连数据库不好吗?还要在前面加上一层代理,会不会降低应用的读写性能?会不会增加维护管理的成本?我想这是每个使用atlas之前的疑问. 1.为什么要使用Atlas? 我们使用atlas,主要使用它的读写分离和从库负载均衡功能.因为咱们这读业务远远多于写,故采用读写分离的架构再合适不过了.之前实现读写分离,一般都是通过应

mysql分表研究

分表是分散数据库压力的好方法. 分表,最直白的意思,就是将一个表结构分为多个表,然后,可以再同一个库里,也可以放到不同的库. 当然,首先要知道什么情况下,才需要分表.个人觉得 单表记录条数达到百万到千万级别时就要使用分表了. 1,分表的分类 1>纵向分表 将本来可以在同一个表的内容,人为划分为多个表.(所谓的本来,是指按照关系型数据库的第三范式要求,是应该在同一个表的.) 分表理由:根据数据的活跃度进行分离,(因为不同活跃的数据,处理方式是不同的) 案例: 对于一个博客系统,文章标题,作者,分类

MYSQL开发性能研究——INSERT,REPLACE,INSERT-UPDATE性能比较

一.为什么要有这个实验 我们的系统是批处理系统,类似于管道的架构.而各个数据表就是管道的两端,而我们的程序就类似于管道本身.我们所需要做的事情无非就是从A表抽取数据,经过一定过滤.汇总等操作放置到B表.如果出现了错误,那么就从重新跑这一个管道.所以说,我们的系统其实根本就不要什么事务性,无非就是挂了把表给TRUNCATE(或者有条件地DELETE)一下,然后重跑就行了. 这样一来,对于select语句就相对比较容易,基本上不需要做JOIN操作.然而对于写操作就有一些要求.比如说,需要处理主键重复

mysql高可用研究 主从+MHA+Atlas

于Atlas的详细介绍请访问:https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md 为什么要使用Atlas?应用程序直连数据库不好吗?还要在前面加上一层代理,会不会降低应用的读写性能?会不会增加维护管理的成本?我想这是每个使用atlas之前的疑问. 1.为什么要使用Atlas? 我们使用atlas,主要使用它的读写分离和从库负载均衡功能.因为咱们这读业务远远多于写,故采用读写分离的架构再合适不过了.之前实现读写分离,一般都是通过应用

mysql一机多实例安装记录

因为想研究mycat,所以需要安装多个mysql实例进行研究.限于没有多于计算机,只能在本机安装了.通过mysql文档,自己琢磨着安装成功! 目录结构如下: 其中one和two文件夹用来模拟数据库分库. 操作步骤: 拷贝文件 拷贝mysql-5.7.9-win64目录下的my-default.ini分别到whole.one.two目录下,更名为my.init. 以whole库 为例说明,one库和two库做相应调整即可. 1.编写\instance\whole\my.init innodb_bu

MySQL高可用方案-PXC(Percona XtraDB Cluster)环境部署详解

Percona XtraDB Cluster简称PXC.Percona Xtradb Cluster的实现是在原mysql代码上通过Galera包将不同的mysql实例连接起来,实现了multi-master的集群架构.下图中有三个实例,组成了一个集群,而这三个节点与普通的主从架构不同,它们都可以作为主节点,三个节点是对等的,这种一般称为multi-master架构,当有客户端要写入或者读取数据时,随便连接哪个实例都是一样的,读到的数据是相同的,写入某一个节点之后,集群自己会将新数据同步到其它节