mysql innodb 性能优化

默认情况下,innodb的参数设置的非常小,在生产环境中远远不够用
比如最重要的两个参数
innodb_buffer_pool_size 默认是8M
innodb_flush_logs_at_trx_commit 默认设置的是1 也就是同步刷新log(可以这么理解)

innodb_buffer_pool_size: 这是InnoDB最重要的设置,对InnoDB性能有决定性的影响。默认的设置只有8M,所以默认的数据库设置下面InnoDB性能很差。在只有 InnoDB存储引擎的数据库服务器上面,可以设置60-80%的内存。更精确一点,在内存容量允许的情况下面设置比InnoDB tablespaces大10%的内存大小。

innodb_data_file_path:指定表数据和索引存储的空间,可以是一个或者 多个文件。最后一个数据文件必须是自动扩充的,也只有最后一个文件允许自动扩充。这样,当空间用完后,自动扩充数据文件就会自动增长(以8MB为单位)以 容纳额外的数据。例如: innodb_data_file_path=/disk1 /ibdata1:900M;/disk2/ibdata2:50M:autoextend两个数据文件放在不同的磁盘上。数据首先放在ibdata1 中,当达到900M以后,数据就放在ibdata2中。一旦达到50MB,ibdata2将以8MB为单位自动增长。如果磁盘满了,需要在另外的磁盘上面 增加一个数据文件。

innodb_data_home_dir:放置表空间数据的目录,默认在mysql的数据目录,设置到和MySQL 安装文件不同的分区可以提高性能。

innodb_log_file_size:该参数决定了recovery speed。太大的话recovery就会比较慢,太小了影响查询性能,一般取256M可以兼顾性能和recovery的速度

innodb_log_buffer_size: 磁盘速度是很慢的,直接将log写道磁盘会影响InnoDB的性能,该参数设定了log buffer的大小,一般4M。如果有大的blob操作,可以适当增大。

innodb_flush_logs_at_trx_commit=2: 该参数设定了事务提交时内存中log信息的处理。

1) =1时,在每个事务提交时,日志缓冲被写到日志文件,对日志文件做到磁盘操作的刷新。Truly ACID。速度慢。
   2) =2时,在每个事务提交时,日志缓冲被写到文件,但不对日志文件做到磁盘操作的刷新。只有操作系统崩溃或掉电才会删除最后一秒的事务,不然不会丢失事务。
   3) =0时, 日志缓冲每秒一次地被写到日志文件,并且对日志文件做到磁盘操作的刷新。任何mysqld进程的崩溃会删除崩溃前最后一秒的事务

innodb_file_per_table: 可以存储每个InnoDB表和它的索引在它自己的文件中。

transaction-isolation=READ-COMITTED: 如果应用程序可以运行在READ-COMMITED隔离级别,做此设定会有一定的性能提升。

innodb_flush_method: 设置InnoDB同步IO的方式:

1) Default – 使用fsync()。
   2) O_SYNC 以sync模式打开文件,通常比较慢。
   3) O_DIRECT,在Linux上使用Direct IO。可以显著提高速度,特别是在RAID系统上。避免额外的数据复制和double buffering(mysql buffering 和OS buffering)。

innodb_thread_concurrency: InnoDB kernel最大的线程数。

1) 最少设置为(num_disks+num_cpus)*2。
   2) 可以通过设置成1000来禁止这个限制

=========================================

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

为什么要学习Innodb的调优: 
  目前来说:InnoDB是为Mysql处理巨大数据量时的最大性 能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。在数据量大的网站或是应用中Innodb是倍受青睐的。
  另一方 面,在数据库的复制操作中Innodb也是能保证master和slave数据一致有一定的作用。

参数调优内容:
  1. 内存利用方面
  2. 日值控制方面
  3. 文件IO分 配,空间占用方面
  4. 其它相关参数

1.内存利用方面:
首先介绍一个Innodb最重要的参数:
innodb_buffer_pool_size 
   这个参数和MyISAM的key_buffer_size有相似之处,但也是有差别的。这个参数主要缓存innodb表的索引,数据,插入数据时的缓 冲。为Innodb加速优化首要参数。
  该参数分配内存的原则:这个参数默认分配只有8M,可以说是非常小的一个值。如果是一个专用DB服务 器,那么他可以占到内存的70%-80%。这个参数不能动态更改,所以分配需多考虑。分配过大,会使Swap占用过多,致使Mysql的查询特慢。如果你 的数据比较小,那么可分配是你的数据大小+10%左右做为这个参数的值。例如:数据大小为50M,那么给这个值分配 innodb_buffer_pool_size=64M
设置方法:
innodb_buffer_pool_size=4G 
这 个参数分配值的使用情况可以根据show innodb status/G; 中的
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4668764894;
 
去确认使用情况。

第二个:
innodb_additional_mem_pool: 
作用:用来存放 Innodb的内部目录
这个值不用分配太大,系统可以自动调。不用设置太高。通常比较大数据设置16M够用了,如果表比较多,可以适当的增大。如 果这个值自动增加,会在error log有中显示的。
分配原则:
show innodb status/G; 去 查看运行中的DB是什么状态(参考BUFFER POOL AND MEMORY段中),然后可以调整到适当的值。
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4668764894; in additional pool allocated 16777216
参考:in additional pool allocated 16777216
根据你的参数情况,可以适当的调整。
设置方法:
innodb_additional_mem_pool=16M

2.关于日值方面:
innodb_log_file_size 
作用:指定日值的大小
分 配原则:几个日值成员大小加起来差不多和你的innodb_buffer_pool_size相等。上限为每个日值上限大小为4G.一般控制在几个LOG 文件相加大小在2G以内为佳。具体情况还需要看你的事务大小,数据大小为依据。
说明:这个值分配的大小和数据库的写入速度,事务大小,异常重启后 的恢复有很大的关系。
设置方法:
innodb_log_file_size=256M

innodb_log_files_in_group
作用:指定你有几个日值组。
分配 原则: 一般我们可以用2-3个日值组。默认为两个。
设置方法:
innodb_log_files_in_group=3

innodb_log_buffer_size:
作用:事务在内存中的缓冲。
分配原 则:控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在Oracle等数据库了解这个,一 般最大指定为3M比较合适。
参考:Innodb_os_log_written(show global status 可以拿到)
如果 这个值增长过快,可以适当的增加innodb_log_buffer_size
另外如果你需要处理大理的TEXT,或是BLOB字段,可以考虑增 加这个参数的值。
设置方法:
innodb_log_buffer_size=3M

innodb_flush_logs_at_trx_commit 
作用:控制事务的提交方式
分 配原则:这个参数只有3个值,0,1,2请确认一下自已能接受的级别。默认为1,主库请不要更改了。
性能更高的可以设置为0或是2,但会丢失一秒 钟的事务。
说明: 
这个参数的设置对Innodb的性能有很大的影响,所以在这里给多说明一下。
当 这个值为1时:innodb 的事务LOG在每次提交后写入日值文件,并对日值做刷新到磁盘。这个可以做到不丢任何一个事务。
当这个值为2时:在 每个提交,日志缓冲被写到文件,但不对日志文件做到磁盘操作的刷新,在对日志文件的刷新在值为2的情况也每秒发生一次。但需要注意的是,由于进程调用方面 的问题,并不能保证每秒100%的发生。从而在性能上是最快的。但操作系统崩溃或掉电才会删除最后一秒的事务。
当这个值为0时:日志缓冲每秒一次 地被写到日志文件,并且对日志文件做到磁盘操作的刷新,但是在一个事务提交不做任何操作。mysqld进程的崩溃会删除崩溃前最后一秒的事务。

从以上分析,当这个值不为1时,可以取得较好的性能,但遇到异常会有损失,所以需要根据自已的情况去衡量。

设置方法:
innodb_flush_logs_at_trx_commit=1

3. 文件IO分配,空间占用方面
innodb_file_per_table 
作用:使每个 Innodb的表,有自已独立的表空间。如删除文件后可以回收那部分空间。
分配原则:只有使用不使用。但DB还需要有一个公共的表空间。
设 置方法:
innodb_file_per_table=1

innodb_file_io_threads 
作用:文件读写IO数,这个参数只在Windows上起 作用。在LINUX上只会等于4
设置方法:
innodb_file_io_threads=4

innodb_open_files 
作用:限制Innodb能打开的表的数据。
分配原则:如果 库里的表特别多的情况,请增加这个。这个值默认是300。
设置方法:
innodb_open_files=800 
请 适当的增加table_cache

4. 其它相关参数 
这里说明一个比较重要的参数:
innodb_flush_method 
作 用:Innodb和系统打交道的一个IO模型
分配原则:Windows不用设置。
Unix可以设置:fsync() or O_SYNC/O_DSYNC
如果系统可以禁止系统的Cache那就把他禁了。
Linux可以选择:O_DIRECT 
直接写入 磁盘,禁止系统Cache了
设置方法:
innodb_flush_method=O_DIRECT

innodb_max_dirty_pages_pct 
作用:控制Innodb的脏页在缓冲中在那个 百分比之下,值在范围1-100,默认为90.
这个参数的另一个用处:当Innodb的内存分配过大,致使Swap占用严重时,可以适当的减小调 整这个值,使达到Swap空间释放出来。建义:这个值最大在90%,最小在15%。太大,缓存中每次更新需要致换数据页太多,太小,放的数据页太小,更新 操作太慢。
设置方法:
innodb_max_dirty_pages_pct=90
动态更改需要有Super权限:
set global innodb_max_dirty_pages_pct=50;

总结: 
  这里只算是列出了Innodb部分的重要参数,不能认为是对Mysql的整体调优。 Mysql的参数一般分为:全局参数,具体引擎的参数。全局参数方面请参考http://imysql.cn/2007_12_08_optimize_mysql_under_linuxyejr的那个Mysql调优的PPT。

========================================

通过这次MySQL InnoDB的调优经历,发现一些和MySQL官方推荐配置不符合的疑惑之处,值得思考和探索:

1、innodb_flush_method究竟应不应该使用O_DIRECT?

所有MySQL调优的建议都说,如果硬件没有预读功能,那么使用O_DIRECT将极大降低InnoDB的性能,因为O_DIRECT跳过了操作系 统的文件系统Disk Cache,让MySQL直接读写磁盘了。

但是在我的实践中来看,如果不使用O_DIRECT,操作系统被迫开辟大量的Disk Cache用于innodb的读写缓存,不但没有提高读写性能,反而造成读写性能急剧下降。而且buffer pool的数据缓存和操作系统Disk Cache缓存造成了Double buffer的浪费,显然从我这个实践来看,浪费得非常厉害。

说O_DIRECT造成MySQL直接读写磁盘造成得性能下降问题,我觉得完全是杞人忧天。因为从JavaEye的数据库监测来看,Innodb的 buffer pool命中率非常高,有98%以上,真正的磁盘操作是微乎其微的。为了1%的磁盘操作能够得到Disk Cache,而浪费了98%的double buffer内存空间,无论从性能上看,还是从内存资源的消耗来看,都是非常不明智的。

2、innodb_log_file_size究竟应该大一点,还是小一点?

所有MySQL调优建议都说,innodb_log_file_size要越大越好,避免无谓的buffer pool的flush操作。

但是在我的实践中来看,innodb_log_file_size开得太大,会明显增加innodb的log写入操作,而且会造成操作系统需要更多 的Disk Cache开销。

因此从我的经验来看,innodb_flush_method =O_DIRECT 是必须的,而innodb_log_file_size也不宜太大。

mysql innodb 性能优化,布布扣,bubuko.com

时间: 2025-01-08 18:18:44

mysql innodb 性能优化的相关文章

架构设计:系统存储(8)——MySQL数据库性能优化(4)

================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的

架构设计:系统存储(9)——MySQL数据库性能优化(5)

=================================== (接上文<架构设计:系统存储(9)--MySQL数据库性能优化(5)>) 4-3-3-3.避免死锁的建议 上一篇文章我们主要介绍了MySQL数据库中锁的基本原理.工作过程和产生死锁的原因.通过上一篇文章的介绍,可以确定我们需要业务系统中尽可能避免死锁的出现.这里为各位读者介绍一些在InnoDB引擎使用过程中减少死锁的建议. 正确使用读操作语句 经过之前文章介绍,我们知道一般的快照读是不会给数据表任何锁的.那么这些快照读操作

MySQL数据库性能优化的技巧和窍门

数据库表表面上存在索引和防错机制,然而一个简单的查询就会耗费很长时间.Web应用程序或许在开发环境中运行良好,但在产品环境中表现同样糟糕.如果你是个数据库管理员,你很有可能已经在某个阶段遇到上述情况.因此,本文将介绍对MySQL进行性能优化的技巧和窍门. 1.存储引擎的选择 如果数据表需要事务处理,应该考虑使用InnoDB,因为它完全符合ACID特性.如果不需要事务处理,使用默认存储引擎MyISAM是比较明智的.并且不要尝试同时使用这两个存储引擎.思考一下:在一个事务处理中,一些数据表使用Inn

淘宝内部分享:MySQL &amp; MariaDB性能优化

淘宝内部分享:MySQL & MariaDB性能优化 发表于2015-01-20 16:26| 17496次阅读| 来源mysql.taobao.org| 21 条评论| 作者淘宝数据库团队 MySQL性能优化淘宝数据库 摘要:MySQL是目前使用最多的开源数据库,但是MySQL数据库的默认设置性能非常的差,必须进行不断的优化,而优化是一个复杂的任务,本文描述淘宝数据库团队针对MySQL相关的数据库优化方案. 编者按:MySQL是目前使用最多的开源数据库,但是MySQL数据库的默认设置性能非常的

【MySql】性能优化之分析命令

[MySql]性能优化之分析命令     一 当发现程序运行比较慢的时候,首先排除物力资源问题之后,就将注意力转向mysq数据库: 1.首先确定运行慢的sql语句: mysql> show full processlist; 2.确认低效的查询: 多次执行第一步发现time耗费大的sql语句.查看耗费的时间. 3.为sql生成一个执行计划query Execution plan(QEP) mysql> explain select * from tbal_name where ...; 4.查

170727、MySQL查询性能优化

MySQL查询性能优化 MySQL查询性能的优化涉及多个方面,其中包括库表结构.建立合理的索引.设计合理的查询.库表结构包括如何设计表之间的关联.表字段的数据类型等.这需要依据具体的场景进行设计.如下我们从数据库的索引和查询语句的设计两个角度介绍如何提高MySQL查询性能. 数据库索引 索引是存储引擎中用于快速找到记录的一种数据结构.索引有多种分类方式,按照存储方式可以分为:聚簇索引和非聚簇索引:按照数据的唯一性可以分为:唯一索引和非唯一索引:按照列个数可以分为:单列索引和多列索引等.索引也有多

mysql数据库性能优化(包括SQL,表结构,索引,缓存)

优化目标减少 IO 次数IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段.降低 CPU 计算除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了.order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算).当我们的 IO 优化做到一定阶段之后

MySQL插入性能优化(转)

原文:http://tech.uc.cn/?p=634 对于一些数据量较大的系统,数据库面临的问题除了查询效率低下,还有就是数据入库时间长.特别像报表系统,每天花费在数据导入上的时间可能会长达几个小时或十几个小时之久.因此,优化数据库插入性能是很有意义的. 经过对MySQL innodb的一些性能测试,发现一些可以提高insert效率的方法,供大家参考参考. 1. 一条SQL语句插入多条数据. 常用的插入语句如: INSERT INTO `insert_table` (`datetime`, `

Mysql数据库性能优化大总结

目录:[TOC] 影响数据库服务器性能的因素 超高的QPS(每秒钟处理的查询量)和TPS导致SQL处理效率下降. 大量的并发导致的数据库连接数被占满和超高的CPU占用率导致资源耗尽服务器宕机. 磁盘IO性能瓶颈导致数据传输效率下降,计划任务导致磁盘IO下降. 网卡IO性能瓶颈,要减少从服务器数量,缓存要分级,避免使用 select * 这样的查询. 大表导致的问题: 不同数据库引擎对于大表的概念是不一样的. InnoDB存储引擎没有明确的大表概念. 实际使用中发现当一个数据表中的数据超过千万行的