mysql innodb 引擎内存分配项

MySQL做为最流行的开源数据库,innodb在5.6开始已成为默认引擎,在5.7中系统吧引擎也有myisam改为innodb,可以看出innodb引擎现在已经可以满足绝大部分的业务需求,内存分配直接影响MySQL整体运行效率,有innodb_buffer,还有各种cache_size,这些选项都需要合理分配,合理利用服务器有限的内存让MySQL跑的更嗨皮,直接影响的选项有下面几个:

innodb_buffer_pool_size:缓冲区,存放表数据、索引数据,大小至关重要,直接影响sql执行时IO的开销,假如缓冲区足够大可以缓存下表全部数据,在内存中利用hash链表的方式查找是相当快的

innodb_additional_mem_pool_size:数据字典存放区,打开一个表对应表字典信息就存于这个区域,当数据表越多,需求的空间就越大,一个表大约占用4K空间,这个选项在5.7已移除

innodb_log_buffer_size: innodb事物日志缓存区域大小

binlog_cache_size: binlog缓存区域大小

session级别参数:

join_buffer_size:在使用块嵌套循环时使用,存放链接键的区域大小

sort_buffer_size:排序键存放区域大小

net_buffer_length:客户端连接存放会话信息的缓存区,当需要时会动态增长到max_allowed_packet设置的大小

max_allowed_packet:限制会话一个数据表的最大大小

查询缓存query_cache_size可以根据业务情景具体判断是否开启,查询缓存机制是需要同样的数据同样的sql才能命中,当数据库update、delete、insert比较多时不适合使用查询缓存,只要数据变化就会失效,失效操作会对查询缓存区持全局锁,这样会阻塞其他做匹配的sql,而且一个sql经过连接管理器之后不管是否有查询缓存相匹配都会到查询缓存匹配一次,这也会降低sql执行效率。

内存分配得根据真实业务情况模拟测试做分配,session级别参数每个链接使用上就会分配一个内存区,必须做好测试才能不浪费太多内存。

所写着几个参数都是innodb非常重要的内存配置参数,myisam因为已逐步淘汰,就不做过多解读了。

时间: 2024-08-08 01:39:44

mysql innodb 引擎内存分配项的相关文章

巧用MySQL InnoDB引擎锁机制解决死锁问题(转)

该文会通过一个实际例子中的死锁问题的解决过程,进一步解释innodb的行锁机制 最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starti

MySQL Study之--MySQL innodb引擎备份工具XtraBackup之一(Install)

MySQL Study之--MySQL innodb引擎备份工具XtraBackup之一(Install) Xtrabackup是一个对InnoDB做数据备份的工具,支持在线热备份(备份时不影响数据读写),是商业备份工具InnoDB Hotbackup的一个很好的替代品. Xtrabackup有两个主要的工具:xtrabackup.innobackupex (1)xtrabackup只能备份InnoDB和XtraDB两种数据表,而不能备份MyISAM数据表 (2)innobackupex-1.5

MYSQL,innodb_buffer_pool_size内存分配方式

以前一直以为MYSQL,innodb_buffer_pool_size=8G,MySQL一起动就会将占用掉8G内存(认为TOP可以看到内存被使用了8G),但是最近才仔细研究一下,原来不是这样的(可能自己对Linux malloc内存分配也只是知道了个皮毛吧),MySQL启动时实际只是在虚拟内存中分配了地址空间,而并没有真正的映射到物理内存上. 因为malloc分配内存是先在虚拟内存中分配地址的,到实际使用时才真正的映射到物理内存 因此这个地方,如果由于机器内存使用不当,到了MySQL真正要映射物

Mysql Innodb 引擎优化

介绍: InnoDB给MySQL提供了具有提交,回滚和崩溃恢复能力的事务安全(ACID兼容)存储引擎.InnoDB锁定在行级并且也在SELECT语句 提供一个Oracle风格一致的非锁定读.这些特色增加了多用户部署和性能.没有在InnoDB中扩大锁定的需要,因为在InnoDB中行级锁定适合非常 小的空间.InnoDB也支持FOREIGN KEY强制.在SQL查询中,你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来,甚至在同一个查询中也可以混合. Innodb 的创始人:Hei

MySQL innoDB引擎锁机制(一) —— 行锁和表锁

我们都知道,MyISAM引擎使用的是表锁,而innoDB最小粒度为行锁.但在实际使用中我们有时发现就算我们操作的是不同行的数据,还是会发生锁表.我们先来看一个例子. session1开启事务并更新id=1的数据: session2开启事务,并更新id=2的数据,但session2被阻塞了: 不是说innoDB支持行锁吗,我们这里明明更新的不是同一条数据,为什么还会被阻塞.其实这是因为MySQL innoDB给数据加锁的方式和oracle不一样.oracle是给这条数据行加锁,而innoDB是给索

MYSQL,innodb_buffer_pool_size内存分配

为MYSQL.innodb_buffer_pool_size=8G.MySQL一起动就会将占用掉8G内存(觉得TOP能够看到内存被使用了8G),可是近期才细致研究一下.原来不是这种(可能自己对Linux malloc内存分配也仅仅是知道了个皮毛吧).MySQL启动时实际仅仅是在虚拟内存中分配了地址空间,而并没有真正的映射到物理内存上. 由于malloc分配内存是先在虚拟内存中分配地址的,到实际使用时才真正的映射到物理内存 因此这个地方.假设因为机器内存使用不当.到了MySQL真正要映射物理内存时

mysql InnoDB引擎 共享表空间和独立表空间(转载)

PS:innodb这种引擎,与MYISAM引擎的区别很大.特别是它的数据存储格式等.对于innodb的数据结构,首先要解决两个概念性的问题: 共享表空间以及独占表空间. 1.什么是共享表空间和独占表空间 共享表空间以及独占表空间都是针对innodb表的数据存储而言的,ibdata1为innodb引擎的存储数据与索引的数据文件,ib_logfile0与ib_logfile1为innodb引擎使用的日志文件共享表空间: mysql服务器中所有数据库的innodb表(数据,索引)全部放在一个文件中,默

[MySQL] innoDB引擎的主键与聚簇索引

mysql的innodb引擎本身存储的形式就必须是聚簇索引的形式 , 在磁盘上树状存储的 , 但是不一定是根据主键聚簇的 , 有三种情形: 1. 有主键的情况下 , 主键就是聚簇索引 2. 没有主键的情况下 , 第一个非空null的唯一索引就是聚簇索引 3. 如果上面都没有 , 那么就是有一个隐藏的row-id作为聚簇索引 大部分情况下 , 我们建表的时候都会创建主键 , 因此大部分都是根据主键聚簇的 当我们根据主键字段来进行查询时 , 效率是最高的 , 不需要二次查找 , 直接主键字段查询索引

Mysql InnoDB引擎的读锁

Mysql官方手册读锁说明 如果,在一个相同的事务中,你查询数据,然后插入/更新与此数据相关的数据,那个通常的SELECT语句不会给我们足够的保护.因为在我们当前事务的SELECT和UPDATE之间的时间段内,其他的事务可能会更新/删除我们刚刚读取到的行.而我们根本不会察觉. InnoDB支持两种类型的读锁,可以给我们提供足够的安全. 1.SELECT ... LOCK IN SHARE MODE  这是共享锁,在读取的任何数据上设定一个共享模式的锁.其他事务可以读取这些数据.但是不能修改这些数