技术改变世界 阅读塑造人生! - shaogx.com

This string was altered by TechBlog\Plugins\Example.; This is an example to show the potential of an offcanvas layout pattern in Bootstrap. Try some responsive-range viewport sizes to see it in action.

MySQL InnoDB存储引擎之锁

    概念:         锁是用来管理对共享文件的并发访问。innodb会在行级别上对数据库上锁。不过innodb存储引擎会在数据库内部其他多个地方使用锁,从而允许对不同资源提供并发访问。例如操作缓冲池中的LRU列表,删除,添加,移动LRU列表中的元素,为了保证一致性,必须有锁的介入。MyISAM引擎是表锁,而InnoDB提供一致性的非锁定读、行级锁,且行级锁没有相关额外的开销。     锁         table-level locking(表级锁)             整个表被客户锁定。根据锁定的类型,其他客户不能向表中插入记录,甚至从中读数据也受到限制MyISAM、MEMORY默认锁级别,个别时候,InnoDB也会升级为表级锁         row-level locking(行级锁)             只有线程当前使用的行被锁定,其他行对于其他线程都是可用的InnoDB默认行级锁。是基于索引数据结构来实现的,而不是像ORACLE的锁,是基于block的。InnoDB也会升级为表级锁,全表/全索引更新,请求autoinc锁等         page-level locking(页级锁)             锁定表中某些行集合(称做页),被锁定的行只对锁定最初的线程是可行。如果另外一个线程想要向这些行写数据,它必须等到锁被释放。不过其他页的行仍然可以使用BDB默认页级锁     lock与latch         latch称为闩锁(轻量级的锁),因为其要求锁定的时间必须非常短。若持续的时间长,则应用的性能会非常差。在InnoDB存储引擎中,又可以分为mutex(互斥量)和rwlock(读写锁)。其目的是用来保证并发线程操作临界资源的正确性,并且通常没有死锁检测的机制。latch可以通过命令show engine innodb mutex来进行查看。如图:         由上图可以看出列Type显示的总是InnoDB,列Name显示latch的信息以及所在源码的行数,列Status中显示的os_waits表示操作系统等待的次数。         lock的对象是事务,用来锁定的是数据库中的对象,如表、页、行。并且一般lock的对象仅在事务commit或者rollback后释放(不同事务隔离级别释放的时间可能不一样)。有死锁机制。二则的区别如下:             特点:     InnoDB是通过对索引上的索引项加锁来实现行锁。这种特点也就意味着,只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁。     锁的类型:         有两种标准的行级锁:             共享锁(S lock):允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁.SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE             排它锁(X lock):允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享读锁和排他锁.SELECT * FROM table_name WHERE ... FOR UPDATE         InnoDB存储引擎支持意向锁且设计比较简练,分为两种内部使用的意向锁(Intention Locks),这两种意向锁都是表锁。(意向锁是InnoDB自动加的)             意向共享锁(IS):事务打算给数据行加行共享锁,事务在给一个数据行加共享锁前必须先取得该表的IS锁.             意向独占锁(IX):事务打算给数据行加行排他锁,事务在给一个数据行加排他锁前必须先取得该表的IX锁.         表级意向锁与行级锁的兼容情况如下图:                 锁的查看         在InnoDB1.0版本之前只能通过show engine innodb status(transactions行中查看) 或者 show full processlist来查看当前库中锁的请求。但是在这之后在information_schema架构下新增innodb_trx、innodb_locks和innodb_lock_waits三张表记录当前库中锁的情况。         三个表的字段说明如下图     一致性非锁定读(consistent nonlocking read)         一致性的非锁定读是指InnoDB存储引擎通过行多版本控制(multi_versioning)的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行delete或者update操作,这时读取操作不会因此去等待行上锁的释放。相反地,InnoDB存储引擎会去读取行的一个快照数据(当前行数据的历史版本)。快照数据是指该行的之前版本的数据,该实现是通过undo段来完成。而undo用来在事务回滚数据,因此快照数据本身是没有额外开销。而且,读取快照数据是不需要上锁的。一致性非锁定读是InnoDB存储引擎的默认读取方式(在读取不会占用和等待表上的锁)。但是在不同事务隔离级别下,读取的方式不同,并不是在每个事务隔离级别下都是采用非锁定的一致性读。即使都是使用非锁定的一致性读,但是对于快照数据的定义格式也各不相同。在事务隔离级别READ COMMITTED(RC)和REPEATABLE READ(RR,InnoDB存储引擎的默认事务隔离级别)下,InnoDB存储引擎使用非锁定的一致性读。然而,对于快照数据的定义去不相同。在RC事务隔离级别下,对于快照数据,非一致性读总是读取被锁定行的最新一份快照数据。而在RR事务隔离解绑下,对于快照数据,非一致性读总是读取事务开始时的行数据版本。     一致性锁定读         有上文知道,默认的事务隔离级别(RR)模式下,InnoDB存储引擎的select操作使用一致性非锁定读。但是在某些情况下,用户需要显式地对数据库读操作加锁以保证数据逻辑的一致性。InnoDB存储引擎对于select语句支持两种一致性的锁定读操作:             select ... for update:对读取的行记录加X锁,其他事物不能对该行加任何锁。             select ... lock in share mode:对读取的行记录加S锁,其他事物可以对该行加S锁,但是如果加X锁,则会被阻塞。     自增长与锁         在InnoDB存储引擎的内存结构中,对每个含有自增长值的表都有一个自增长计数器(auto-increment counter)。当对含有自增长的计数器的表进行插入操作是,这个计数器会被初始化,执行如下的语句来得到计数器的值:select max(auto_inc_col) from t for update。插入操作会依据这个自增长的计数器值加1赋予自增长列。这个实现方式称为AUTO-INC Locking,这是一种特殊的表锁机制,为了提高插入的性能,锁不是在一个事务完成之后才释放,而是在完成对自增长值插入的SQL语句后会立即释放。AUTO-INC Locking在一定程度上提高了并发插入的效率,但是还存在一些性能上的问题。首先,对于有自增长值的列的并发插入性能较差,事务必须等待前一个插入的完成(不用等待事务的完成)。其次,对于insert ... select的大数据量的插入会影响插入的性能,因为另一个事务中的插入会被阻塞。从MySQL5.1.22版本开始,InnoDB存储引擎提供了一种轻量级互斥量的自增长实现机制,这种机制大大提高了自增长值插入的性能。通过参数innodb_autoinc_lock_mode来控制自增长的模式(默认为1)。自增长的插入进行分类如图:         innodb_autoinc_lock_mode的参数值及其对自增长的影响如下图:         MyISAM存储引擎是表锁,自增长不用考虑并发插入的问题。需要注意的是:在InnoDB存储引擎中,自增长值的列必须是索引,同时必须是索引的第一个列,如果不是第一个列,MySQL是会抛出异常的。异常如图     外键与锁         外键主要用于完整性的约束检查。在InnoDB存储引擎中,对于一个外键列,如果没有显式地对这个列加索引,InnoDB存储引擎会自动对其加一个索引,避免表锁。对于外键值的插入或者更新,首先需要查询父表中的记录,对于父表的select操作,不是使用的一致性非锁定读的方式,因为这样会发生数据不一致的问题,所以这时使用的是select ... lock in share mode方式,即主动给父表加一个S锁。     锁的问题         dirty read 脏读             脏读就是读取到脏数据(未提交的数据)。一个事务(A)读取到另一个事务(B)中修改后但尚未提交的数据,并在这个数据的基础上操作。这时,如果B事务回滚,那么A事务读到的数据是无效的。不符合一致性。如图             首先事务的隔离级别有默认的RR改为RU,由上述例子可以看出会话B中两次select操作取得了不同的结果,并且这2条记录是会话A中并未提交的数据,这就产生了脏读。由此可以得出结论:脏读发生的条件是事务的隔离级别为RU。         unrepeatable read 不可重复读             事务(A)读取到了另一个事务(B)已经提交的更改数据,不符合隔离性。不可重复读和脏读的区别是:脏读是读到未提交的数据,而不可重复读则读到的是已经提交的数据。首先将事务隔离级别调整为RC,然后操作下边的例子:         phantom read 幻读             事务(A)读取到了另一个事务(B)提交的新增数据,不符合隔离性。     锁的范围(锁的算法):         1.Record Lock :单个记录上的锁,总是会去锁住索引记录,如果InnoDB存储引擎表在建立的时候没有设置任何一个索引,那么这时InnoDB存储引擎会使用隐式的主键来进行锁定。         2.Gap Lock:间隙锁,锁定一个范围,但不包含记录本身。         3.Next-key Lock: 锁定一个范围和本身 Record Lock + Gap Lock,防止幻读。         主键索引和唯一辅助索引 = record lock         非唯一辅助索引 = next-key lock     阻塞         不同锁之间的兼容性关系,在有些时刻一个事务中的锁需要等待另外一个事务中的锁释放它所占用的资源,这就是阻塞。阻塞并不是一件坏事,其是为了确保事务可以并发且正常地运行。在InnoDB存储引擎中,参数innodb_lock_wait_timeout用来动态的控制等待的时间(默认50秒),innodb_rollback_on_timeout用来静态的设定释放在等待超时时对进行的事务进行回滚操作(默认OFF,代表不回滚)。     死锁        死锁是指两个或者两个以上的事务在执行过程中,因争夺资源而造成的一种相互等待的现象。解决死锁最简单的一种方式是超时,即当两个事务相互等待是,当一个等待时间超过设置的某一阀值时,其中一个事务进行回滚,另外一个等待的事务就能继续进行。在InnoDB存储引擎中,参数innodb_lock_wait_timeout用来设置超时时间。但若超时的事务所占权重比较大,如果事务操作更新了很多行,占用了较多的undo log,这时采用FIFO的方式就不合适啦,因为回滚这个事务的时间相对于另一个事务所占用的时间可能会很多。因此,除了超时机制,当前数据库都普遍采用wait-for graph(等待图)的方式来进行死锁检测。要求数据库报错以下两种信息:a.锁的信息链表;b.事务等待链表。通过上述链表可以构造一张图,而在这个图中若存在回路,就代表存在死锁。在wait-for graph中,事务为图中的节点。如图:... 全文

Mysql InnoDB锁 Mysql InnoDB存储引擎锁 Mysql InnoDB Mysql 锁

InnoDB存储引擎之Master Thread

    InnoDB存储引擎的主要工作都是在一个单独的后台线程Master Thread中完成的。     1.InnoDB 1.0.x版本之前的Master Thread        Master Thread具有最高的线程优先级别。其内部由多个循环组成:主循环(loop)、后台循环(backgroup loop)、刷新循环(flush loop)、暂停循环(suspend loop)。Master Thread会根据数据库运行的状态在上述4状态下进行切换。Loop被称为主循环,因为大多数的操作是在这个循环中,其中有两大部分的操作:每秒的操作和每10秒的操作。伪代码如下:... 全文

MySQL InnoDB存储引擎 InnoDB存储引擎Master Thr MySQL InnoDB Master Mysql InnoDB主线程

InnoDB存储引擎之InnoDB关键特性

1.插入缓冲     A.Insert Buffer         听名字会让人理解为插入缓冲是缓冲池中的一部分。其实不是这个样子的,InnoDB缓冲池中有Insert Buffer信息,但是Insert Buffer和数据页一样,也是物理页的一个组成部分。在InnoDB存储引擎中,行记录的插入顺序是按照主键递增的顺序进行插入的。因此插入聚集索引(Primary Key)一般是顺序的,不需要磁盘的随机读取。但是并不是所有的主键都是顺序的。如主键是UUID这类的,那么插入和辅助索引一样都是随机的。所以在建表时主键是关键一般都是自增ID且非空。         对于非聚集索引的插入或者更新操作,不是每一次直接插入到索引页中,而是先判定插入的非聚集索引页是否在缓冲池中,若在则直接插入;如不在则先放入到Inset Buffer中。然后再以一定的频率和情况进行Insert Buffer和辅助索引页子节点的merge操作。这时通常能将多少插入合并到一个操作中(因为在一个索引页中),这就大大提高了对于非聚集索引的性能。但是Inset Buffer的使用需要同时满足一下两个条件:1.索引是辅助索引;2.索引不是唯一的。如果是唯一索引的话,数据库会去查找索引页来判断插入记录的唯一性,这个样子又会有离散读取的情况发生,从而导致Insert Buffer失去意义。可以通过命令show engine innodb status来查看插入缓冲的信息。但是在写密集的情况下,插入缓冲会占用过多的缓冲池,默认最大可以占到这个缓冲池的1/2。这对于其他的操作可能会带来一定的影响。Percona发布一些patch来修正这个情况。可以通过ibuf_pool_size_per_max_size参数来设置。具体的可以到官网进行查找。     B.Change Buffer        InnoDB从1.0.x版本开始引入了Change Buffer。对DML操作-insert、delete、update都进行缓冲。分别是:Insert Buffer、Delete Buffer、Purge Buffer。Change Buffer使用的对象依然是非唯一的辅助索引。对一条记录进行update操作可能分为两个过程:1.将记录标记未已删除;2.真正将记录删除。因此delete Buffer对呀update操作的第一个过程,Purge Buffer对应update操作的第二个过程。可以通过参数innodb_change_buffering来开启各种Buffer的选项。该参数的可选值有:inserts、deletes、purges、all、none。changes表示启用inserts和deletes,all表示启用所有,none表示都不启用。默认all。在InnoDB 1.2.x还可以通过参数innodb_change_buffer_max_size(百分比)来控制最大使用的内存数量。如图... 全文

InnoDB关键特性 InnoDB存储引擎关键特性 MySQL InnoDB存储引擎之Inn MySQL InnoDB关键特性

mysql innodb断电恢复,不支持innodb,表空间丢失

mysql innodb断电恢复,不支持innodb,表空间丢失一、需求在办公网络中有一测试pc,跑mysql服务,周末大厦停电,导致mysql 异常;具体表象为不支持innodbCurrent database: kkyoo_ucenterERROR 1286 (42000): Unknown table engine 'InnoDB'二、解决1、首先发现innodb 不支持mysql> show variables like '%innodb%';+-----------------------+-------+| Variable_name         | Value |... 全文

mysql innodb断电恢复 不支持innodb 表空间丢失

MySQL配置内存使用之innodb数据字典

 innodb有对自己每个表的缓存,被称之为表定义缓存或者数据字典,在当前版的MySQL中是不可配置的。当innodb打开一个表的时候,会将与之对应的对象添加到数据字典中。每一个表占用4KB或更多的内存(尽管在MySQL5.1中会占用更少的内存空间)。当表关闭时,这些与之对应的对象并不会从数据字典中移除。 随着数据字典缓存中对象的不增长,MySQL服务器会出现内存泄露的现象。但这并不是真正意义上的泄露内存;这仅仅是由于innodb没有实现任何类型的缓存过期策略。当拥有成千上万的大表时,这通常是个问题。如果这的确是个问题,你可以选择使用 Percona Server,这个分支有一个通过移除未使用的表对象来限制数据字典大小的选项。同样在MySQL5.6中也有相类似的特性。 另一个性能问题是第一次打开表时会为其计算统计信息,这个动作消耗大量的I/O,是非常昂贵的。相比于MyISAM,innodb不会持久的存储这些表的统计信息;第一次启动时会重新计算,在这之后,不同的时间间隔到期或相应的事件(改变表的内容,对INFORMATION_SCHEMA查询等等)也会触发这个动作。如果有大量的表,服务器会花费数个小时的时间启动和充分热身,在这段时间内,服务器可能不会处理太多的其它操作。要解决这个问题,你可以开启Percona Server的innodb_use_sys_stats_table选项(在MySQL5.6中开启 innodb_analyze_is_persistent选项)来持久存储这些表统计信息。 服务器启动之后,innodb统计信息操作也会对服务器或一些查询产生影响。通过关闭 innodb_stats_on_metadata选项来防止耗时的表统计信息的刷新 。但是查询 INFORMATION_SCHEMA 表中的信息时就会有很大的差异。 如果开启了innodb的 innodb_file_per_table 选项,对innodb能保持打开的.ibd文件的数据会有一个单独的限制。这由innodb存储引擎处理,而不是MySQL服务器,并且由innodb_open_files选项控制.innodb打开文件的方式与MyISAM不同:MyISAM使用表缓存来保存打开表的文件描述符,而在innodb中打开表和打开文件没有直接的关系。innodb为每一个.ibd文件使用一个单一的全局的文件描述符。如果你负担得起,最好将innodb_open_files设置的足够大,这样MySQL可以保持所有的.ibd文件同时处于打开状态。 译自: 高性能MySQL (第三版) ... 全文

Innodb MySQL MySQL数据字典

mysql innodb 性能优化

转自blog.csdn.net/binger819623默认情况下,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来禁止这个限制... 全文

mysql innodb优化 mysql 数据库 休闲 职场

mysql的innodb 调优

innodb_buffer_pool_size如果用Innodb,那么这是一个重要变量。相对于MyISAM来说,Innodb对于buffer size更敏感。MySIAM可能对于大数据量使用默认的key_buffer_size也还好,但Innodb在大数据量时用默认值就感觉在爬了。 Innodb的缓冲池会缓存数据和索引,所以不需要给系统的缓存留空间,如果只用Innodb,可以把这个值设为内存的70%-80%。和 key_buffer相同,如果数据量比较小也不怎么增加,那么不要把这个值设太高也可以提高内存的使用率。innodb_additional_pool_size这个的效果不是很明显,至少是当操作系统能合理分配内存时。但你可能仍需要设成20M或更多一点以看Innodb会分配多少内存做其他用途。... 全文

mysql innodb

Innodb与MySQL各自功能

    摘自官方文档:    主要是Innodb特点及其负责部分:    Storage limits(存储限制):64T    Transactions(是否支持事务):yes    Locking granularity(锁粒度):Row    MVCC(是否支持多版本控制):yes    Geospatial data type support(空间数据类型):yes    Geospatial indexing support(索引空间数据类型):NO    B-tree indexes :yes... 全文

Innodb MySQL

修改mysql默认引擎为innodb

1、停止mysql服务 # /etc/init.d/mysqld stop 2、备份my.cnf cd /etc cp my.cnf my.cnf_bak 3、修改my.cnf [mysqld] 后加入 # vi my.cnf default-storage-engine=InnoDB 4、删除/mysql/data目录下的ib_logfile0,ib_logfile1 否则在启动mysql时会遇到下述错误: [ERROR] Plugin 'InnoDB' init function returned error. [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Unknown/unsupported table type: InnoDB [ERROR] Aborting 5、启动mysql # /etc/init.d/mysqld start Starting MySQL: [ OK ] 6、登录mysql检查修改是否成功 # mysql -u root -p mysql>show variables like'storage_engine'; +----------------+--------+ | Variable_name | Value | +----------------+--------+ | storage_engine | InnoDB | +----------------+--------+ 本文出自 “Darrenpan” 博客,请务必保留此出处http://darren.blog.51cto.com/1081720/1110520... 全文

mysql innodb

MySQL Innodb日志机制深入分析

                            MySQL Innodb日志机制深入分析 1.1. Log & CheckpointInnodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile*里面。Innodb还有另外一个日志Undo log,但Undo log是存放在共享表空间里面的(ibdata*文件)。 由于Log和Checkpoint紧密相关,因此将这两部分合在一起分析。名词解释:LSN,日志序列号,Innodb的日志序列号是一个64位的整型。 ... 全文

mysql Innodb 日志机制

mysql不支持innodb存储引擎

工作中,不免会遇到前辈已经编译安装过的mysql,忽然发现mysql不支持innodb的存储引擎的问题,现在来看一下吧一、先看mysql是否支持innodb存储引擎mysql> show variables like 'ha%';+----------------------+----------+| Variable_name        | Value    |... 全文

mysql 存储引擎 innodb

mysql开启Innodb引擎

1、stop mysql2、编辑my.cnf文件,把skip-innodb注释3、在数据库目录中把ibdata1、ib_logfile0、ib_logfile1 这三个文件删掉4、start mysql ... 全文

mysql 数据库 休闲 Innodb 职场

Mysql Innodb 引擎优化(

作/译者:吴炳锡,来源:http://imysql.cn & http://imysql.cn/blog/3208 转载请注明作/译者和出处,并且不能用于商业用途,违者必究。 介绍:  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=16M2.关于日值方面:innodb_log_file_size作用:指定日值的大小分配原则:几个日值成员大小加起来差不多和你的innodb_buffer_pool_size相等。上限为每个日值上限大小为4G.一般控制在几个LOG文件相加大小在2G以内为佳。具体情况还需要看你的事务大小,数据大小为依据。说明:这个值分配的大小和数据库的写入速度,事务大小,异常重启后的恢复有很大的关系。设置方法:innodb_log_file_size=256Minnodb_log_files_in_group作用:指定你有几个日值组。分配原则: 一般我们可以用2-3个日值组。默认为两个。设置方法:innodb_log_files_in_group=3innodb_log_buffer_size:作用:事务在内存中的缓冲。分配原则:控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在Oracle等数据库了解这个,一般最大指定为3M比较合适。参考:Innodb_os_log_written(show global status 可以拿到)如果这个值增长过快,可以适当的增加innodb_log_buffer_size另外如果你需要处理大理的TEXT,或是BLOB字段,可以考虑增加这个参数的值。设置方法:innodb_log_buffer_size=3Minnodb_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=13. 文件IO分配,空间占用方面innodb_file_per_table作用:使每个Innodb的表,有自已独立的表空间。如删除文件后可以回收那部分空间。分配原则:只有使用不使用。但DB还需要有一个公共的表空间。设置方法:innodb_file_per_table=1innodb_file_io_threads作用:文件读写IO数,这个参数只在Windows上起作用。在LINUX上只会等于4设置方法:innodb_file_io_threads=4innodb_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_DIRECTinnodb_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_linux yejr的那个Mysql调优的PPT。 本文出自 “MySQL中文网”博客 http://www.imysql.cn/... 全文

Innodb Mysql 引擎 数据库 休闲

Linux下重新配置MySQL数据库引擎innodb的过程

有时候,我们因为工作的需要会重新配置MySQL数据库引擎innodb。那么如何在Linux系统下重新配置MySQL数据库引擎innodb呢?本文我们就来介绍这一部分内容,接下来就让我们来一起了解一下吧!1)停止mysql服务。[root@mysql ~]# service mysqld  stop。2)修改mysql的配置文件。[root@mysql ~]# vi  /etc/my.cnf。3)删除datedir文件夹下的包含ib_logfile1和ibdata的文件。4)在根目录下建立mysqldata文件夹。5)启动使设置生效。my.cnf修改内容如下:... 全文

MySQL innodb Linux

如何修改MySQL数据库引擎为INNODB

对于MySQL数据库,如果你要使用事务以及行级锁就必须使用INNODB引擎。如果你要使用全文索引,那必须使用myisam。 INNODB的实用性,安全性,稳定性更高但是效率比MYISAM稍差,但是有的功能是MYISAM没有的。修改MySQL的引擎为INNODB,可以使用外键,事务等功能,性能高。本文主要介绍如何修改MySQL数据库引擎为INNODB,接下来我们开始介绍。首先修改my.ini,在[mysqld]下加上:... 全文

MySQL数据库 INNODB 数据库引擎

InnoDB还是MyISAM 再谈MySQL存储引擎的选择

两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。我作为使用MySQL的用户角度出发,Innodb和MyISAM都是比较喜欢的,但是从我目前运维的数据库平台要达到需求:99.9%的稳定性,方便的扩展性和高可用性来说的话,MyISAM绝对是我的首选。原因如下:1、首先我目前平台上承载的大部分项目是读多写少的项目,而MyISAM的读性能是比Innodb强不少的。... 全文

MyISAM InnoDB 存储引擎 MySQL

MySQL系列:innodb源码分析之文件IO

innodb作为数据库引擎,自然少不了对文件的操作,在innodb中所有需要持久化的信息都需要文件操作,例如:表文件、重做日志文件、事务日志文件、备份归档文件等。innodb对文件IO操作可以是煞费苦心,其主要包括两方面,一个是对异步io的实现,一个是对文件操作管理和io调度的实现。在MySQL-5.6版本的innodb还加入了DIRECT IO实现。做了这么多无非是优化io操作的性能。在innodb的文件IO部分中,主要实现集中在os_file.*和fil0fil.*两个系列的文件当中,其中os_file*是实现基本的文件操作、异步IO和模拟异步IO。fil0fil.*是对文件io做系统的管理和space结构化。下面依次来介绍这两个方面的内容.1.系统文件IO在innodb中,文件的操作是比较关键的,innodb封装了基本的文件操作,例如:文件打开与关闭、文件读写以及文件属性访问等。这些是基本的文件操作函数封装。在linux文件的读写方面,默认是采用pread/pwrite函数进行读写操作,如果系统部支持这两个函数,innodb用lseek和read、write函数联合使用来达到效果. 以下是innodb文件操作函数:    os_file_create_simple                        创建或者打开一个文件    os_file_create                                     创建或者打开一个文件,如果操作失败会重试,直到成功    os_file_close                                       关闭打开的文件    os_file_get_size                                   获得文件的大小    os_file_set_size                                   设置文件的大小并以0填充文件内容    os_file_flush                                        将写的内容fsync到磁盘    os_file_read                                        从文件中读取数据    os_file_write                                       将数据写入文件 innodb除了实现以上基本的操作以外,还实现了文件的异步IO模型,在Windows下采用的IOCP模型来进行处理(具体可以见网上的资料),在linux下是采用aio来实现的,有种情况,一种是通过系统本身的aio机制来实现,还有一种是通过多线程信号模拟来实现aio.这里我们重点来介绍,为了实现aio,innodb定义了slot和slot array,具体数据结构如下:typedef struct os_aio_slot_struct { ibool is_read; /*是否是读操作*/ ulint pos; /*slot array的索引位置*/ ibool reserved; /*这个slot是否被占用了*/ ulint len; /*读写的块长度*/ byte* buf; /*需要操作的数据缓冲区*/ ulint type; /*操作类型:OS_FILE_READ OS_FILE_WRITE*/ ulint offset; /*当前操作文件偏移位置,低32位*/ ulint offset_high; /*当前操作文件偏移位置,高32位*/ os_file_t file; /*文件句柄*/ char* name; /*文件名*/ ibool io_already_done; /*在模拟aio的模式下使用,TODO*/ void* message1; void* message2; #ifdef POSIX_ASYNC_IO struct aiocb control; /*posix 控制块*/ #endif }os_aio_slot_t; typedef struct os_aio_array_struct { os_mutex_t mutex; /*slots array的互斥锁*/ os_event_t not_full; /*可以插入数据的信号,一般在slot数据被aio操作后array_slot有空闲可利用的slot时发送*/ os_event_t is_empty; /*array 被清空的信号,一般在slot数据被aio操作后array_slot里面没有slot时发送这个信号*/ ulint n_slots; /*slots总体单元个数*/ ulint n_segments; /*segment个数,一般一个对应n个slot,n = n_slots/n_segments,一个segment作为aio一次的操作范围*/ ulint n_reserved; /*有效的slots个数*/ os_aio_slot_t* slots; /*slots数组*/ os_event_t* events; /*slots event array,暂时没弄明白做啥用的*/ }os_aio_array_t;内存结构关系图:2.文件管理的内存结构在innodb中定义三种文件类型:表空间文件(ibdata*)、重做日志文件(ib_logfile*)和归档文件(ib_arch_log*)。一般innodb在运行的过程中,会同时打开很多个文件,这就要求对文件进行系统的管理和控制。在innodb中定义了一套基于fil_system_t、fil_space_t和fil_node_t的内存管理结构。每个文件对应的是一个fil_node_t,fil_node是存储的最小单元,多个同一模块的fil_node组成一个fil_space_t,所有的space组成一个fil_system_t,在innodb引擎里,只有一个fil_system_t对象。... 全文

MYSQL innodb IO 磁盘 文件操作

MySQL系列:innodb源码分析之文件IO

innodb作为数据库引擎,自然少不了对文件的操作,在innodb中所有需要持久化的信息都需要文件操作,例如:表文件、重做日志文件、事务日志文件、备份归档文件等。innodb对文件IO操作可以是煞费苦心,其主要包括两方面,一个是对异步io的实现,一个是对文件操作管理和io调度的实现。在MySQL-5.6版本的innodb还加入了DIRECT IO实现。做了这么多无非是优化io操作的性能。在innodb的文件IO部分中,主要实现集中在os_file.*和fil0fil.*两个系列的文件当中,其中os_file*是实现基本的文件操作、异步IO和模拟异步IO。fil0fil.*是对文件io做系统的管理和space结构化。下面依次来介绍这两个方面的内容.1.系统文件IO在innodb中,文件的操作是比较关键的,innodb封装了基本的文件操作,例如:文件打开与关闭、文件读写以及文件属性访问等。这些是基本的文件操作函数封装。在linux文件的读写方面,默认是采用pread/pwrite函数进行读写操作,如果系统部支持这两个函数,innodb用lseek和read、write函数联合使用来达到效果. 以下是innodb文件操作函数:    os_file_create_simple                        创建或者打开一个文件    os_file_create                                     创建或者打开一个文件,如果操作失败会重试,直到成功    os_file_close                                       关闭打开的文件    os_file_get_size                                   获得文件的大小    os_file_set_size                                   设置文件的大小并以0填充文件内容    os_file_flush                                        将写的内容fsync到磁盘    os_file_read                                        从文件中读取数据    os_file_write                                       将数据写入文件 innodb除了实现以上基本的操作以外,还实现了文件的异步IO模型,在Windows下采用的IOCP模型来进行处理(具体可以见网上的资料),在linux下是采用aio来实现的,有种情况,一种是通过系统本身的aio机制来实现,还有一种是通过多线程信号模拟来实现aio.这里我们重点来介绍,为了实现aio,innodb定义了slot和slot array,具体数据结构如下:typedef struct os_aio_slot_struct { ibool is_read; /*是否是读操作*/ ulint pos; /*slot array的索引位置*/ ibool reserved; /*这个slot是否被占用了*/ ulint len; /*读写的块长度*/ byte* buf; /*需要操作的数据缓冲区*/ ulint type; /*操作类型:OS_FILE_READ OS_FILE_WRITE*/ ulint offset; /*当前操作文件偏移位置,低32位*/ ulint offset_high; /*当前操作文件偏移位置,高32位*/ os_file_t file; /*文件句柄*/ char* name; /*文件名*/ ibool io_already_done; /*在模拟aio的模式下使用,TODO*/ void* message1; void* message2; #ifdef POSIX_ASYNC_IO struct aiocb control; /*posix 控制块*/ #endif }os_aio_slot_t; typedef struct os_aio_array_struct { os_mutex_t mutex; /*slots array的互斥锁*/ os_event_t not_full; /*可以插入数据的信号,一般在slot数据被aio操作后array_slot有空闲可利用的slot时发送*/ os_event_t is_empty; /*array 被清空的信号,一般在slot数据被aio操作后array_slot里面没有slot时发送这个信号*/ ulint n_slots; /*slots总体单元个数*/ ulint n_segments; /*segment个数,一般一个对应n个slot,n = n_slots/n_segments,一个segment作为aio一次的操作范围*/ ulint n_reserved; /*有效的slots个数*/ os_aio_slot_t* slots; /*slots数组*/ os_event_t* events; /*slots event array,暂时没弄明白做啥用的*/ }os_aio_array_t;内存结构关系图:2.文件管理的内存结构在innodb中定义三种文件类型:表空间文件(ibdata*)、重做日志文件(ib_logfile*)和归档文件(ib_arch_log*)。一般innodb在运行的过程中,会同时打开很多个文件,这就要求对文件进行系统的管理和控制。在innodb中定义了一套基于fil_system_t、fil_space_t和fil_node_t的内存管理结构。每个文件对应的是一个fil_node_t,fil_node是存储的最小单元,多个同一模块的fil_node组成一个fil_space_t,所有的space组成一个fil_system_t,在innodb引擎里,只有一个fil_system_t对象。... 全文

MYSQL innodb IO 磁盘 文件操作

innodb存储引擎之mysql的debug环境搭建

关键词:innodb 存储引擎 mysql debug环境搭建摘要:个人学习记录,仅供参考。        innodb存储引擎是mysql数据库的默认存储引擎,对mysql性能优化具有决定性地位,并且其许多特性直接决定了mysql的特性路线。最重要的是学习innodb存储引擎对于程序员了解c++算法、学习数据库性能优化具有极高的价值。正文:一个好的环境对于程序员来说是十分重要的。... 全文

innodb 存储引擎 mysql debug环境搭建

1 2 3 4 5