Mysql5.5 InnoDB存储引擎配置和优化

环境为CentOS系统,1G内存,Mysql5.5.30。
在/etc/my.cnf内添加:


代码如下:

skip-external-locking
skip-name-resolve
max_connections = 1024
query_cache_size = 16M
sort_buffer_size = 1M
table_cache = 256
innodb_buffer_pool_size = 128M
innodb_additional_mem_pool_size = 4M
innodb_log_file_size = 128M
innodb_log_files_in_group = 2
innodb_log_buffer_size = 2M
innodb_flush_log_at_trx_commit = 1

修改前先将mysql服务停止:
service mysqld restart
由于修改了日志大小重启会报错:
130319 04:45:14 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
130319 05:02:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130319 5:02:54 [Note] Plugin 'FEDERATED' is disabled.
130319 5:02:59 InnoDB: The InnoDB memory heap is disabled
130319 5:02:59 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
130319 5:02:59 InnoDB: Compressed tables use zlib 1.2.3
130319 5:02:59 InnoDB: Using Linux native AIO
130319 5:03:01 InnoDB: Initializing buffer pool, size = 128.0M
130319 5:03:02 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 134217728 bytes!
130319 5:03:02 [ERROR] Plugin 'InnoDB' init function returned error.
130319 5:03:02 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130319 5:03:02 [ERROR] Aborting
将/var/lib/mysql下原先的ib_logfile0、ib_logfile1删除再重启mysql。
service mysqld start
正常启动:
130319 05:20:59 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
130319 05:22:53 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130319 5:22:56 [Note] Plugin 'FEDERATED' is disabled.
130319 5:22:57 InnoDB: The InnoDB memory heap is disabled
130319 5:22:57 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
130319 5:22:57 InnoDB: Compressed tables use zlib 1.2.3
130319 5:22:57 InnoDB: Using Linux native AIO
130319 5:22:57 InnoDB: Initializing buffer pool, size = 128.0M
130319 5:22:57 InnoDB: Completed initialization of buffer pool
130319 5:22:57 InnoDB: highest supported file format is Barracuda.
130319 5:22:58 InnoDB: Waiting for the background threads to start
130319 5:22:59 InnoDB: 5.5.30 started; log sequence number 2621452
130319 5:22:59 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130319 5:22:59 [Note] - '0.0.0.0' resolves to '0.0.0.0';
130319 5:22:59 [Note] Server socket created on IP: '0.0.0.0'.
130319 5:23:00 [Warning] 'proxies_priv' entry '@ root@server08' ignored in --skip-name-resolve mode.
130319 5:23:04 [Note] Event Scheduler: Loaded 0 events
130319 5:23:04 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.30' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
使用mysqladmin variables命令可查看所有参数变量。

InnoDB引擎配置优化
innodb_buffer_pool_size=1G //一个Innodb最重要的参数,这个参数和MyISAM的key_buffer_size有相似之处,但也是有差别的。这个参数主要缓存innodb表的索引,数据,插入数据时的缓冲,设置得越大,存取表里面数据时所需要的磁盘I/O越少,一般是内存的一半,不超过2G,否则系统会崩溃。为Innodb加速优化首要参数。该参数分配内存的原则:这个参数默认分配只有8M,可以说是非常小的一个值。如果是一个专用DB服务器,那么他可以占到内存的70%-80%。这个参数不能动态更改,所以分配需多考虑。分配过大,会使Swap占用过多,致使Mysql的查询特慢。如果你的数据比较小,那么可分配是你的数据大小+10%左右做为这个参数的值。
例如:数据大小为50M,那么给这个值分配innodb_buffer_pool_size=64M
innodb_additional_mem_pool_size=16M //用来存放Innodb的内部目录这个值不用分配太大,系统可以自动调。不用设置太高。通常比较大数据设置16M够用了,如果表比较多,可以适当的增大。如果这个值自动增加,会在error log有中显示的。
innodb_log_file_size=256M //在日志组中每个日志文件的大小,一般是innodb_buffer_pool_size的25%,官方推荐是innodb_buffer_pool_size的40-50%。一般控制在几个LOG文件相加大小在2G以内为佳。具体情况还需要看你的事务大小,数据大小为依据。说明:这个值分配的大小和数据库的写入速度,事务大小,异常重启后的恢复有很大的关系。
innodb_log_files_in_group=2 //指定你有几个日志组。分配原则:一般我们可以用2-3个日值组。默认为两个。
innodb_log_buffer_size=3M //事务在内存中的缓冲。分配原则:控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在oracle等数据库了解这个,一般最大指定为3M比较合适。
innodb_flush_logs_at_trx_commit=0 //控制事务的提交方式分配原则:这个参数只有3个值,0,1,2请确认一下自已能接受的级别。默认为1,主库请不要更改了。性能更高的可以设置为0或是2,但会丢失一秒钟的事务。说明:这个参数的设置对Innodb的性能有很大的影响,所以在这里给多说明一下。当这个值为1时:innodb 的事务LOG在每次提交后写入日值文件,并对日值做刷新到磁盘。这个可以做到不丢任何一个事务。当这个值为2时:在每个提交,日志缓冲被写到文件,但不对日志文件做到磁盘操作的刷新,在对日志文件的刷新在值为2的情况也每秒发生一次。但需要注意的是,由于进程调用方面的问题,并不能保证每秒100%的发生。从而在性能上是最快的。但操作系统崩溃或掉电才会删除最后一秒的事务。当这个值为0时:日志缓冲每秒一次地被写到日志文件,并且对日志文件做到磁盘操作的刷新,但是在一个事务提交不做任何操作。mysqld进程的崩溃会删除崩溃前最后一秒的事务。

(0)

相关推荐

  • MySQL性能优化之路---修改配置文件my.cnf

    在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分.对于Discuz!论坛程序也是如此,MySQL的设置是否合理优化,直接影响到论坛的速度和承载量!同时,MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数. 下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分,一是服务器物理硬件的优化,二是MySQL自身(my.cnf)的优化. 一.服务

  • MySQL5.6基本优化配置

    随着 大量默认选项的改进, MySQL 5.6比以前版本需要调优的选项大为减少. 在本文中我将讲述需要优化的配置项. InnoDB设置 1.innodb_buffer_pool_size  -- 默认值为 128M. 这是最主要的优化选项,因为它指定 InnoDB 使用多少内存来加载数据和索引(data+indexes). 针对专用MySQL服务器,建议指定为物理内存的 50-80%这个范围. 例如,拥有64GB物理内存的机器,缓存池应该设置为50GB左右. 如果将该值设置得更大可能会存在风险,

  • Nginx 0.7.x + PHP 5.2.6(FastCGI)+ MySQL 5.1 在128M小内存VPS服务器上的配置优化第1/2页

    对其用户和应用程序来讲,每一个VPS平台的运行和管理都与一台独立主机完全相同,因为每一个VPS均可独立进行重启并拥有自己的root访问权限.用户.IP地址.内存.过程.文件.应用程序.系统函数库以及配置文件.VPS服务器最重要的指标就是内存大小,多个VPS服务器可以共享一颗CPU,但不能共享同一块内存.内存越大,价格越贵. 下面,以我的博客所在的VPS为例,介绍在128M内存下对 Nginx 0.7.x + PHP 5.2.6(FastCGI)+ MySQL 5.1 的优化. 至于 Nginx

  • MySQL性能优化之max_connections配置参数浅析

    MySQL的max_connections参数用来设置最大连接(用户)数.每个连接MySQL的用户均算作一个连接,max_connections的默认值为100.本文将讲解此参数的详细作用与性能影响. 与max_connections有关的特性 MySQL无论如何都会保留一个用于管理员(SUPER)登陆的连接,用于管理员连接数据库进行维护操作,即使当前连接数已经达到了max_connections.因此MySQL的实际最大可连接数为max_connections+1: 这个参数实际起作用的最大值

  • MySQL性能优化配置参数之thread_cache和table_cache详解

    一.THREAD_CACHE MySQL里面为了提高客户端请求创建连接过程的性能,提供了一个连接池也就是 Thread_Cache池,将空闲的连接线程放在连接池中,而不是立即销毁.这样的好处就是,当又有一个新的请求的时候,mysql不会立即去创建连接 线程,而是先去Thread_Cache中去查找空闲的连接线程,如果存在则直接使用,不存在才创建新的连接线程. 有关Thread_Cache在MySQL有几个重要的参数,简单介绍如下: thread_cache_size Thread_Cache 中

  • MySQL 4G内存服务器配置优化

    公司网站访问量越来越大(日均超10万PV),MySQL自然成为瓶颈,关于 MySQL 的优化,最基本的是 MySQL 系统参数的优化. MySQL对于web架构性能的影响最大,也是关键的核心部分.MySQL的设置是否合理优化,直接影响到web的速度和承载量!同时,MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数. 下面我们了解一下MySQL优化的一些基础,MySQL自身(my.cnf)的优化. 我们介绍一

  • MySQL优化必须调整的10项配置

    当我们被人雇来监测MySQL性能时,人们希望我们能够检视一下MySQL配置然后给出一些提高建议.许多人在事后都非常惊讶,因为我们建议他们仅仅改动几个设置,即使是这里有好几百个配置项.这篇文章的目的在于给你一份非常重要的配置项清单. 我们曾在几年前在博客里给出了这样的建议,但是MySQL的世界变化实在太快了!写在开始前-即使是经验老道的人也会犯错,会引起很多麻烦.所以在盲目的运用这些推荐之前,请记住下面的内容: 一次只改变一个设置!这是测试改变是否有益的唯一方法. 大多数配置能在运行时使用SET

  • MySQL配置文件my.cnf参数优化和中文详解

    Mysql参数优化对于新手来讲,是比较难懂的东西,其实这个参数优化,是个很复杂的东西,对于不同的网站,及其在线量,访问量,帖子数量,网络情况,以及机器硬件配置都有关系,优化不可能一次性完成,需要不断的观察以及调试,才有可能得到最佳效果. 复制代码 代码如下: [client]port = 3306socket = /tmp/mysql.sock [mysqld]port = 3306socket = /tmp/mysql.sock basedir = /usr/local/mysqldatadi

  • MySQL配置文件my.cnf中文详解附mysql性能优化方法分享

    下面先说我的服务器的硬件以及论坛情况,CPU: 2颗四核Intel Xeon 2.00GHz内存: 4GB DDR硬盘: SCSI 146GB论坛:在线会员 一般在 5000 人左右 – 最高记录是 13264.下面,我们根据以上硬件配置结合一份已经做过一次优化的my.cnf进行分析说明:有些参数可能还得根据论坛的变化情况以及程序员的程序进行再调整.[mysqld]port = 3306serverid = 1socket = /tmp/mysql.sockskip-locking # 避免My

  • Mysql5.5 InnoDB存储引擎配置和优化

    环境为CentOS系统,1G内存,Mysql5.5.30.在/etc/my.cnf内添加: 复制代码 代码如下: skip-external-lockingskip-name-resolvemax_connections = 1024query_cache_size = 16Msort_buffer_size = 1Mtable_cache = 256innodb_buffer_pool_size = 128Minnodb_additional_mem_pool_size = 4Minnodb_

  • Mysql Innodb存储引擎之索引与算法

    目录 一.概述 二.数据结构与算法 1.二分查找 2.二叉查找树和平衡二叉树 1)二叉查找树 2)平衡二叉树 三.B+树 1.B+树完整定义 2.关于 M 和 L的选定案例 四.B+树索引 1.聚集索引 2.辅助索引 五.关于 Cardinality 值 1.Cardinality定义 2.Cardinality的更新 六.B+树索引的使用 1.联合索引 2.覆盖索引 3.优化器选择不使用索引的情况 4.索引提示 5.Multi-Range Read 优化 (MRR) 6.Index Condi

  • MySql InnoDB存储引擎之Buffer Pool运行原理讲解

    目录 1. 前言 2. Buffer Pool 2.1 Buffer Pool结构 2.2 Free链表 2.3 缓冲页哈希表 2.4 Flush链表 2.5 LRU链表 2.6 多个实例 2.7 Buffer Pool状态信息 3. 总结 1. 前言 我们已经知道,对于InnoDB存储引擎而言,页是磁盘和内存交互的基本单位.哪怕你要读取一条记录,InnoDB也会将整个索引页加载到内存.哪怕你只改了1个字节的数据,该索引页就是脏页了,整个索引页都要刷新到磁盘.InnoDB是基于磁盘的存储引擎,如

  • MySQL InnoDB存储引擎的深入探秘

    前言 在MySQL中InnoDB属于存储引擎层,并以插件的形式集成在数据库中.从MySQL5.5.8开始,InnoDB成为其默认的存储引擎.InnoDB存储引擎支持事务.其设计目标主要是面向OLTP的应用,主要特点有:支持事务.行锁设计支持高并发.外键支持.自动崩溃恢复.聚簇索引的方式组织表结构等. 体系架构 InnoDB存储引擎是由内存池.后台线程.磁盘存储三大部分组成. 线程 InnoDB 使用的是多线程模型, 其后台有多个不同的线程负责处理不同的任务 Master Thread Maste

  • 详解MySql中InnoDB存储引擎中的各种锁

    目录 什么是锁 InnoDB存储引擎中的锁 锁的算法 行锁的3种算法 幻像问题 锁的问题 脏读 不可重复读 丢失更新 死锁 什么是锁 现实生活中的锁是为了保护你的私有物品,在数据库中锁是为了解决资源争抢的问题,锁是数据库系统区别于文件系统的一个关键特性.锁机制用于管理对共享资源的并发访. 数据库系统使用锁是为了支持对共享资源进行并发访问,提供数据的完整性和一致性 InnoDB存储引擎区别于MyISAM的两个重要特征就是:InnoDB存储引擎支持事务和行级别的锁,MyISAM只支持表级别的锁 In

  • InnoDb 体系架构和特性详解 (Innodb存储引擎读书笔记总结)

    后台线程 •Master Thread 核心后台线程,主要负责将缓冲池的数据异步刷新到磁盘.例如脏页的刷新,插入缓冲的合并,undo 页的回收等. 每秒一次的操作: 1.日志缓冲刷新到磁盘,即使该事务还没有提交.该操作总是会发生,这个就是为了再大的事务,提交时间都很短. 2.当IO压力很小时(1s内发生的IO次数小于5% innodb_io_capacity)合并5% innodb_io_capacity 的插入缓冲. 3.当脏页比例大于 innodb_max_dirty_pages_cnt,

  • MySQL中InnoDB存储引擎的锁的基本使用教程

    MyISAM和MEMORY采用表级锁(table-level locking) BDB采用页面锁(page-leve locking)或表级锁,默认为页面锁 InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁 各种锁特点 表级锁:开销小,加锁快:不会出现死锁:锁定粒度大,发生冲突的概率最高,并发度最低 行级锁:开销大,加锁慢:会出现死锁:锁定粒度最小,发生锁冲突的概率最低,并发度也最高 页面锁:开销和加锁时间介于表锁和行锁之间:会出现死锁:锁定粒度介于表锁和行锁之

  • MySQL学习(七):Innodb存储引擎索引的实现原理详解

    概述 在数据库当中,索引就跟树的目录一样用来加快数据的查找速度,对于一个SQL查询操作,根据索引快速过滤掉不符合要求的数据并定位到符合要求的数据,从而不需要扫描整个表来获取所需的数据. 在innodb存储引擎中,主要是基于B+树来实现索引,在非叶子节点存放索引关键字,在叶子节点存放数据记录或者主键索引(或者说是聚簇索引)中的主键值,所有的数据记录都在同一层,叶子节点,即数据记录直接之间通过指针相连,构成一个双向链表,从而可以方便地遍历到所有的或者某一范围的数据记录. B树,B+树 B树和B+树都

  • 简述MySQL InnoDB存储引擎

    前言: 存储引擎是数据库的核心,对于 MySQL 来说,存储引擎是以插件的形式运行的.虽然 MySQL 支持种类繁多的存储引擎,但最常用的当属 InnoDB 了,本篇文章将主要介绍 InnoDB 存储引擎相关知识. 1. InnoDB 简介 MySQL 5.5 版本以后,默认存储引擎就是 InnoDB 了.InnoDB 是一种兼顾了高可靠性和高性能的通用存储引擎.在 MySQL 5.7 中,除非你配置了其他默认存储引擎,否则执行 CREATE TABLE 不指定 ENGINE 的语句将创建一个

  • 详解MySQL InnoDB存储引擎的内存管理

    存储引擎之内存管理 在InnoDB存储引擎中,数据库中的缓冲池是通过LRU(Latest Recent Used,最近最少使用)算法来进行管理的,即最频繁使用的页在LRU列表的最前段,而最少使用的页在LRU列表的尾端,当缓冲池不能存放新读取到的页时,首先释放LRU列表尾端的页. 上面的图中,我使用8个数据页来表示队列,具体作用,先卖个关子.在InnoDB存储引擎中,缓冲池中页的默认大小是16KB,LRU列表中有一个midpoint的位置,新读取到的数据页并不是直接放入到LRU列表的首部,而是放入

随机推荐