my-innodb-heavy-4G.cnf1 详解

http://bbs.51cto.com/thread-1166608-1.html 在网上找的一篇

下面是自习找资料翻译的 欢迎讨论

1、 back_log = 50

#指定MySQL可能的连接数量。当MySQL主线程在很短的时间内得到非常多的连接请求,该参数就起作用,之后主线程花些时间(尽管很短)检查连接并且启动一个新线程。
  back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。如果系统在一个短时间内有很多连接,则需 要增大该参数的值,该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的限制。试图设定back_log高于 你的操作系统的限制将是无效的。
  当观察MySQL进程列表,发现大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时,就要加大 back_log 的值。back_log默认值为50。

max_connections = 100       
参数用来设置最大连接(用户)数。每个连接MySQL的用户均算作一个连接,max_connections的默认值为100
  
2、 max_connect_errors = 10

#当此值设置为10时,意味着如果某一客户端尝试连接此MySQL服务器,但是失败(如密码错误等等)10次,则MySQL会无条件强制阻止此客户端连接。
如果希望重置此计数器的值,则必须重启MySQL服务器或者执行
命令。
当这一客户端成功连接一次MySQL服务器后,针对此客户端的max_connect_errors会清零。
 影响与错误形式
如果max_connect_errors的设置过小,则网页可能提示无法连接数据库服务器;而通过SSH的mysql命令连接数据库,则会返回
ERROR 1129 (00000): Host ‘gateway’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts’

table_open_cache = 2048
参数设置表高速缓存的数目。每个连接进来,都会至少打开一个表缓存。因此, table_cache 的大小应与 max_connections 的设置有关。例如,对于 200 个并行运行的连接,应该让表的缓存至少有 200 × N ,这里 N 是应用可以执行的查询的一个联接中表的最大数量。此外,还需要为临时表和文件保留一些额外的文件描述符。
当 Mysql 访问一个表时,如果该表在缓存中已经被打开,则可以直接访问缓存;如果还没有被缓存,但是在 Mysql 表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区;如果表缓存满了,则会按照一定的规则将当前未用的表释放,或者临时扩大表缓存来存放,使用表缓存的好处是可以更快速地访问表中的内容。
缓存机制
当 Mysql 访问一个表时,如果该表在缓存中已经被打开,则可以直接访问缓存;如果还没有被缓存,但是在 Mysql 表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区;如果表缓存满了,则会按照一定的规则将当前未用的表释放,或者临时扩大表缓存来存放,使用表缓存的好处是可以更快速地访问表中的内容。
执行

mysql >flush tables;

#命令将会清空当前所有缓存的表。

3、 max_allowed_packet = 16M

#指代mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
这个是定义mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
定义过大,比如max_allowed_packet=8092,有可能服务器端太忙,来不及接收,或者网络太差,会容易造成丢包
定义过小,会因为客户端可能无法快速接收服务器端发过来的包,一般推荐是4096

http://bbs.chinaunix.net/thread-4178672-1-1.html

4、 binlog_cache_size = 1M
 #为每个session 分配的内存,在事务过程中用来存储二进制日志的缓存。提高记录bin-log的效率

max_heap_table_size = 64M
它规定了内部内存临时表的最大值,每个线程都要分配。(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。)如果内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,存储在指定的tmpdir目录下,默认:
mysql> show variables like "tmpdir";

5、read_buffer_size = 2M

#是MySQL读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySQL会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁,并且你认为频繁扫描进行得太慢,可以通过增加该变量值以及内存缓冲区大小提高其性能。
read_rnd_buffer_size = 16M
是MySQL的随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySQL会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。

6、 sort_buffer_size = 8M

#是MySQL执行排序使用的缓冲大小。如果想要增加ORDER BY的速度,首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能,可以尝试增加sort_buffer_size变量的大小。
join_buffer_size = 8M
应用程序经常会出现一些两表(或多表)Join的操作需求,MySQL在完成某些 Join 需求的时候(all/index join),为了减少参与Join的“被驱动表”的读取次数以提高性能,需要使用到 Join Buffer 来协助完成 Join操作。当 Join Buffer 太小,MySQL 不会将该 Buffer 存入磁盘文件,而是先将Join Buffer中的结果集与需要 Join 的表进行 Join 操作,然后清空 Join Buffer 中的数据,继续将剩余的结果集写入此 Buffer 中,如此往复。这势必会造成被驱动表需要被多次读取,成倍增加 IO 访问,降低效率
thread_cache_size = 8
如果我们在MySQL服务器配置文件中设置了thread_cache_size,当客户端断开之后,
服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)。thread_cache_size功能在mysql数据库配置文件中是非常重要的一项功能了,如果对thread_cache_size优化做得好我们可以让服务器跑得非常快,设置不好就会发现很小访问量就非常的卡哦。
7、 thread_concurrency = 8

#是一个编程术语,表示“线程并发”,简单地说就是一个程序创建多个线程,并行执行一些任务。

query_cache_size = 64M
查询缓存保存查询返回的完整结果。当查询命中该缓存,会立刻返回结果,跳过了解析,优化和执行阶段。
查询缓存会跟踪查询中涉及的每个表,如果这写表发生变化,那么和这个表相关的所有缓存都将失效。
但是随着服务器功能的强大,查询缓存也可能成为整个服务器的资源竞争单点。
缓存存放在一个引用表中,通过一个哈希值引用,这个哈希值包括查询本身,数据库,客户端协议的版本等,任何字符上的不同,例如空格,注释都会导致缓存不命中。
当查询中有一些不确定的数据时,是不会缓存的,比方说now(),current_date(),自定义函数,存储函数,用户变量,字查询等。所以这样的查询也就不会命中缓存,但是还会去检测缓存的,因为查询缓存在解析SQL之前,所以MySQL并不知道查询中是否包含该类函数,只是不缓存,自然不会命中。

8、 query_cache_limit = 2M

#指定单个查询能够使用的缓冲区大小,缺省为1M

ft_min_word_len = 4
从 Mysql 4.0 开始就支持全文索引功能,但是 Mysql 默认的最小索引长度是 4。如果是英文默认值是比较合理的,但是中文绝大部分词都是2个字符,这就导致小于4个字的词都不能被索引,全文索引功能就形同虚设了
一般的数据 库搜索 都是用的SQL 的 like 语句,like 语句是不能利用索引的,每次查询都是从第一条遍历至最后一条,查询效率极其低下。一般数据超过10万或者在线人数过多,like查询都会导致数据库 崩溃。这也就是为什么很多程序 都只提供标题搜索的原因了,因为如果搜索内容,那就更慢了,几万数据就跑不动了。

Mysql 全文索引是专门为了解决模糊查询提供的,可以对整篇文章 预先按照词进行索引,搜索效率高,能够支持百万级的数据检索。

9、 default-storage-engine = MYISAM
#默认的MyISAM存储引擎

10、 thread_stack = 192K
#每个连接被创建的时候,mysql分配给它的内存.这个值一般认为默认就可以应用于大部分场景了,除非必要非则不要动它.
transaction_isolation = REPEATABLE-READ

11、 tmp_table_size = 64M
#它规定了内部内存临时表的最大值,每个线程都要分配。(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。)如果内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,存储在指定的tmpdir目录下

log-bin=mysql-bin
mysql-bin.000001、mysql-bin.000002等文件是数据库的操作日志,例如UPDATE一个表,或者DELETE一些数据,即使该语句没有匹配的数据,这个命令也会存储到日志文件中,还包括每个语句执行的时间,也会记录进去的。

binlog_format=mixed
mysql复制主要有三种方式:基于SQL语句的复制(statement-based replication, SBR),基于行的复制(row-based replication, RBR),混合模式复制(mixed-based replication, MBR)。对应的,binlog的格式也有三种:STATEMENT,ROW,MIXED。
① STATEMENT模式(SBR)

每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化,减少了binlog日志量,节约IO,提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数, last_insert_id(),以及user-defined functions(udf)等会出现问题)

② ROW模式(RBR)

不记录每条sql语句的上下文信息,仅需记录哪条数据被修改了,修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志,尤其是alter table的时候会让日志暴涨。

③ MIXED模式(MBR)

以上两种模式的混合使用,一般的复制使用STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,MySQL会根据执行的SQL语句选择日志保存方式
MIXED说明

对于执行的SQL语句中包含now()这样的时间函数,会在日志中产生对应的unix_timestamp()*1000的时间字符串,slave在完成同步时,取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步,而对于上面指定的一些类似于UDF函数,导致Slave无法知晓的情况,则会采用ROW格式存储这些Binlog,以保证产生的Binlog可以供Slave完成数据同步。
http://www.111cn.net/database/mysql/71702.htm
12、 slow_query_log

#顾名思义,慢查询日志中记录的是执行时间较长的query,也就是我们常说的slow query,通过设--log-slow-queries[=file_name]来打开该功能并设置记录位置和文件名,默认文件名为hostname-slow.log,默认目录也是数据目录。
    慢查询日志采用的是简单的文本格式,可以通过各种文本编辑器查看其中的内容。其中记录了语句执行的时刻,执行所消耗的时间,执行用户,连接主机等相关信息。MySQL还提供了专门用来分析满查询日志的工具程序mysqlslowdump,用来帮助数据库管理人员解决可能存在的性能问题。
http://www.cnblogs.com/Richardzhu/p/3230221.html

13、 long_query_time = 2

#MySQL慢查询支持毫秒的设置MySQL慢查询本身不支持ms级别(需要打补丁),但是对MySQL5.21+的版本,long_query_time最小值为0(5.2.1之前版本最小为1s),单位是s,如果指定ms,其ms部分会被忽略;其实这已经是变相支持毫秒级别了,比如查询时间大于100ms将被记
http://www.dedecms.com/knowledge/data-base/mysql/2012/0819/7319.html

14、 server-id = 1
#1、 mysql同步的数据中是包含server-id的,用于标识该语句最初是从哪个server写入的,因此server-id一定要有的

#2、 每一个同步中的slave在master上都对应一个master线程,该线程就是通过slave的server-id来标识的;每个slave在master端最多有一个master线程,如果两个slave的server-id 相同,则后一个连接成功时,前一个将被踢掉。 这里至少有这么一种考虑
      slave主动连接master之后,如果slave上面执行了slave stop;则连接断开,但是master上对应的线程并没有退出;当slave start之后,master不能再创建一个线程而保留原来的线程,那样同步就可能有问题;

#3、 在mysql做主主同步时,多个主需要构成一个环状,但是同步的时候有要保证一条数据不会陷入死循环,这里就是靠server-id来实现的
14、 key_buffer_size = 32M

#key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads /key_read_requests应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得)。

key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。
http://blog.chinaunix.net/uid-24145780-id-125159.html

15、 bulk_insert_buffer_size = 64M

#和key_buffer_size一样,这个参数同样也仅作用于使用 MyISAM存储引擎,用来缓存批量插入数据的时候临时缓存写入数据。当我们使用如下几种数据写入语句的时候,会使用这个内存区域来缓存批量结构的数据以帮助批量写入数据文件:
http://www.jb51.net/article/48422.htm

16、 myisam_sort_buffer_size = 128M
#当对MyISAM表执行repair table或创建索引时,用以缓存排序索引;设置太小时可能会遇到” myisam_sort_buffer_size is too small”

17、 myisam_max_sort_file_size = 10G

#当对MyISAM表重建索引时(repair/alter table/load data infile),允许使用的临时文件最大值;如果超过此限制索引创建则改用key cache,此时show processlist会显示该线程处于”repair with keycache”而非”repair by sorting”,前者逐条创建索引记录;另外,当指定的tmpdir目录空间不足时也会导致类似情形;

18、 myisam_repair_threads = 1

# 如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们.
# 这对于拥有多个CPU以及大量内存情况的用户,是一个很好的选择.
myisam_recover
#自动检查和修复没有适当关闭的 MyISAM 表
19、 innodb_additional_mem_pool_size = 16M

#这个参数用来设置 InnoDB 存储的数据目录信息和其它内部数据结构的内存池大小,类似于Oracle的library cache。这不是一个强制参数,可以被突破。
innodb_buffer_pool_size = 2G
当我们使用InnoDB存储引擎的时候,innodb_buffer_pool_size 参数可能是影响我们性能的最为关键的一个参数了,他用来设置用于缓存 InnoDB 索引及数据块的内存区域大小,类似于 MyISAM 存储引擎的 key_buffer_size 参数,当然,可能更像是 Oracle 的 db_cache_size。简单来说,当我们操作一个 InnoDB 表的时候,返回的所有数据或者去数据过程中用到的任何一个索引块,都会在这个内存区域中走一遭。

和key_buffer_size 对于 MyISAM 引擎一样,innodb_buffer_pool_size 设置了 InnoDB 存储引擎需求最大的一块内存区域的大小,直接关系到 InnoDB存储引擎的性能,所以如果我们有足够的内存,尽可将该参数设置到足够打,将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中,直至全部。

我们可以通过 (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率,并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。
innodb_data_file_path = ibdata1:10M:autoextend
#表空间文件 重要数据
20、 innodb_write_io_threads = 8
#其它对IO有影响的参数(以5.6为准)
innodb_adaptive_flushing 默认即可
innodb_change_buffer_max_size 如果是日值类服务,可以考虑把这个增值调到 50
innodb_change_buffering 默认即可
innodb_flush_neighors 默认是开的, 这个一定要开着,充分利用顺序IO去写数据。
innodb_lru_scan_depth: 默认即可 这个参数比较专业。
innodb_max_purge_lag 默认没启用,如果写入和读取都量大,可以保证读取优先,可以考虑使用这个功能。
innodb_random_read_ahead 默认没开启,属于一个比较活跃的参数,如果要用一定要多测试一下。 对用passport类应用可以考虑使用
innodb_read_ahead_threshold 默认开启:56 预读机制可以根据业务处理,如果是passprot可以考虑关闭。如果使用innodb_random_read_ahead,建议关闭这个功能
innodb_read_io_threads 默认为:4 可以考虑8
innodb_write_io_threads 默认为:4 可以考虑8
sync_binlog 默认即可: 0
innodb_rollback_segments 默认即可: 128

另外5.6的undo log也可以独立配置了,建议单独配置出来。
http://www.mysqlsupport.cn/innodb-io-optimize-conf

21、 innodb_read_io_threads = 8
#文件IO的线程数,一般为 4,但是在 Windows 下,可以设置得较大。
22、 innodb_thread_concurrency = 16
#服务器有几个CPU就设置为几,建议用默认设置,一般为8.
23 、innodb_flush_log_at_trx_commit = 1
# 如果将此参数设置为1,将在每次提交事务后将日志写入磁盘。为提供性能,可以设置为0或2,但要承担在发生故障时丢失数据的风险。设置为0表示事务日志写入日志文件,而日志文件每秒刷新到磁盘一次。设置为2表示事务日志将在提交时写入日志,但日志文件每次刷新到磁盘一次。
24、 innodb_log_buffer_size = 8M
#这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer,InnoDB 在写事务日志的时候,为了提高性能,也是先将信息写入 Innofb Log Buffer 中,当满足 innodb_flush_log_trx_commit 参数所设置的相应条件(或者日志缓冲区写满)之后,才会将日志写到文件(或者同步到磁盘)中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。
注:innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0,1,2,解释如下:

0:log buffer中的数据将以每秒一次的频率写入到log file中,且同时会进行文件系统到磁盘的同步操作,但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作;
1:在每次事务提交的时候将log buffer 中的数据都会写入到log file,同时也会触发文件系统到磁盘的同步;
2:事务提交会触发log buffer 到log file的刷新,但并不会触发磁盘文件系统到磁盘的同步。此外,每秒会有一次文件系统到磁盘同步操作。

此外,MySQL文档中还提到,这几种设置中的每秒同步一次的机制,可能并不会完全确保非常准确的每秒就一定会发生同步,还取决于进程调度的问题。实际上,InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制,可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。
25、 innodb_log_file_size = 256M
#此参数确定数据日志文件的大小,以M为单位,更大的设置可以提高性能,但也会增加恢复故障数据库所需的时间
26、 innodb_log_files_in_group = 3

#为提高性能,MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3M
27、 innodb_max_dirty_pages_pct = 90

# Buffer_Pool中Dirty_Page所占的数量,直接影响InnoDB的关闭时间。参数innodb_max_dirty_pages_pct 可以直接控制了Dirty_Page在Buffer_Pool中所占的比率,而且幸运的是innodb_max_dirty_pages_pct是可以动态改变的。所以,在关闭InnoDB之前先将innodb_max_dirty_pages_pct调小,强制数据块Flush一段时间,则能够大大缩短 MySQL关闭的时间。
http://www.taobaodba.com/html/221_innodb_max_dirty_pages_pct_checkpoint.html

28、 innodb_lock_wait_timeout = 120
# InnoDB 有其内置的死锁检测机制,能导致未完成的事务回滚。但是,如果结合InnoDB使用MyISAM的lock tables 语句或第三方事务引擎,则InnoDB无法识别死锁。为消除这种可能性,可以将innodb_lock_wait_timeout设置为一个整数值,指示 MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)
[mysqldump]
Quick 
 = 16M
指代mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
这个是定义mysql服务器端和客户端在一次传送数据包的过程当中数据包的大小
定义过大,比如max_allowed_packet=8092,有可能服务器端太忙,来不及接收,或者网络太差,会容易造成丢包
定义过小,会因为客户端可能无法快速接收服务器端发过来的包,一般推荐是4096
 [mysql]
no-auto-rehash
是自动补全的意思,就像我们在linux命令行里输入命令的时候,使用tab键的功能是一样的

[myisamchk]
29、 key_buffer_size = 512M

#如果key_buffer_size设置太大,系统就会频繁的换页,降低系统性能。因为MySQL使用操作系统的缓存来缓存数据,所以我们得为系统留够足够的内存;在很多情况下数据要比索引大得多
http://www.cnblogs.com/sunss/archive/2011/03/11/1981373.html

30、 sort_buffer_size = 512M
#1 Sort_Buffer_Size 是一个connection级参数,在每个connection第一次需要使用这个buffer的时候,一次性分配设置的内存。
#2 Sort_Buffer_Size 并不是越大越好,由于是connection级的参数,过大的设置+高并发可能会耗尽系统内存资源。
#3 文档说“On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation”
http://bbs.chinaunix.net/thread-1805254-1-1.html

31、 read_buffer = 8M
#主要用于表顺序扫描的缓存,这个缓存的作用是不是多次查询同一张表不用去磁盘取数据,直接从缓存中读取(这里有个疑问,如果数据发生了修改了缓存就会失效?),还是仅仅只是作为一次全表扫描的缓存,查询完缓存空间直接释放了,不会用于下一次查询。
http://bbs.csdn.net/topics/390415865?page=1

32、 write_buffer = 8M
#cache和write buffer都是内置于CPU内部的一小段高速存储器,cache中保存着最近一段时间被CPU使用过的内存数据,而write buffer则是用来应对内存的写操作的,将原本要写向内存的数据暂写到write buffer中,等到CPU空闲的时候,数据才会慢慢地被搬移到内存里。
http://blog.chinaunix.net/uid-20662820-id-3917558.html

[mysqlhotcopy]
interactive-timeout
interactive_timeout是MySQL在等待一个活动连接关闭连接前等待的秒数
http://blog.itpub.net/26855487/viewspace-751504

[mysqld_safe]
open-files-limit = 8192
MySQL的变量open_files_limit,table_open_cache和max_connections是相互关联的。如果对有些变量进行了设置,有的变量没有设置,mysql会根据一定的计算公式进行计算得出其他的,当然有些时候会触发mysql的一些警告来。具体的计算流程及如何得出最终的文件描述符有些许复杂
http://www.sudops.com/mysql-open-file-limit-max_connections-table-open-cache.html

时间: 2024-11-07 06:59:26

my-innodb-heavy-4G.cnf1 详解的相关文章

mysql-5.7 innodb 的并行任务调度详解

一.innodb并行任务调度是什么: 这里要"考古"一下了,不然问题说不清楚.上大学的时候老师和我们说最初的计算机只有一个核心,并且一次也只能做一件事, 如果你有两件事要用到计算机,在第一件事没有做完之前,后面那件事只能等着.后来呀,计算机就进化了一把,计算机不再 是把一件是做完之后,再去做第二件事,而是一件事只做一段非常短的时间,并不关心这件事有没有做完,它就会去做第二件 事,同样第二件事也只做一段非常短的时间,就回过头去做第一件事: 虽然事实上两件事是交错着做的,由于第一件事都只做

MySQL InnoDB后台线程threads详解

master thread 核心的后台线程,主要负责将缓冲池中的数据异步刷新到磁盘,保证数据的一致性,包括脏页的刷新.合并插入缓冲.undo页的回收等.Master thread在主循环中,分两大部分操作,每秒钟的操作和每10秒钟的操作:每秒一次的操作包括:1.日志缓冲刷新到磁盘,即使这个事务还没有提交(总是),这点解释了为什么再大的事务commit时都很快:2.合并插入缓冲(可能),合并插入并不是每秒都发生,InnoDB会判断当前一秒内发生的IO次数是否小于5,如果是,则系统认为当前的IO压力

【mysql】mysql innodb 配置详解

MySQL innodb 配置详解 innodb_buffer_pool_size:这是InnoDB最重要的设置,对InnoDB性能有决定性的影响.默认的设置只有8M,所以默认的数据库设置下面InnoDB性能很差.在只有InnoDB存储引擎的数据库服务器上面,可以设置60-80%的内存.更精确一点,在内存容量允许的情况下面设置比InnoDB tablespaces大10%的内存大小. innodb_data_file_path:指定表数据和索引存储的空间,可以是一个或者多个文件.最后一个数据文件

Mysql加锁过程详解(9)-innodb下的记录锁,间隙锁,next-key锁

Mysql加锁过程详解(1)-基本知识 Mysql加锁过程详解(2)-关于mysql 幻读理解 Mysql加锁过程详解(3)-关于mysql 幻读理解 Mysql加锁过程详解(4)-select for update/lock in share mode 对事务并发性影响 Mysql加锁过程详解(5)-innodb 多版本并发控制原理详解 Mysql加锁过程详解(6)-数据库隔离级别(1) Mysql加锁过程详解(6)-数据库隔离级别(2)-通过例子理解事务的4种隔离级别 Mysql加锁过程详解

详解为什么32位系统只能用4G内存.

本文转自:https://www.cnblogs.com/nvd11/archive/2013/04/02/2996784.html,感谢作者的干货 既然是详解, 就从最基础的讲起了. 1. Bit(位)              Bit计算机是计算机最小的存储单位,  大家都知道计算机实质上都是用二进制数0或者1来存储数据的,  所以Bit实际上可以看成存放1个二进制数字的1个位置.             也就是说bit只有2种值, 0 或者 1, 所以1个bit能存放1个布尔类型的值(bo

重新学习MySQL数据库7:详解MyIsam与InnoDB引擎的锁实现

重新学习Mysql数据库7:详解MyIsam与InnoDB引擎的锁实现 说到锁机制之前,先来看看Mysql的存储引擎,毕竟不同的引擎的锁机制也随着不同. 三类常见引擎: MyIsam :不支持事务,不支持外键,所以访问速度快.锁机制是表锁,支持全文索引 InnoDB :支持事务.支持外键,所以对比MyISAM,InnoDB的处理效率差一些,并要占更多的磁盘空间保留数据和索引.锁机制是行锁,不支持全文索引(5.6以上支持) Memory:数据是存放在内存中的,默认哈希索引,非常适合存储临时数据,服

详解 MySql InnoDB 中的三种行锁(记录锁、间隙锁与临键锁)

详解 MySql InnoDB 中的三种行锁(记录锁.间隙锁与临键锁) 前言 InnoDB 通过 MVCC 和 NEXT-KEY Locks,解决了在可重复读的事务隔离级别下出现幻读的问题.MVCC 我先挖个坑,日后再细讲,这篇文章我们主要来谈谈那些可爱的锁. 什么是幻读? 幻读是在可重复读的事务隔离级别下会出现的一种问题,简单来说,可重复读保证了当前事务不会读取到其他事务已提交的 UPDATE 操作.但同时,也会导致当前事务无法感知到来自其他事务中的 INSERT 或 DELETE 操作,这就

MySQL-5.5.32 配置文件优化详解

MySQL-5.5.32 配置文件优化详解============================== [TOC] # 一.配置文件说明 > MySQL-5.5.32是Mysql5.5系列中最后一个版本,也是最后一个有配置文件的版本,为什么这么说呢,用过5.6的博友都知道,在mysql5.6中已经不提供配置文件选择,只有一个默认的配置文件,好了,我们今天说的是5.5.32这个版,就不和大家说5.6了,下面我们来具体说一下,mysql5.5.32中,提供可选的几个配置文件, * my-small.

my.ini配置详解

Mysql my.ini 配置文件详解 #BEGIN CONFIG INFO #DESCR: 4GB RAM, 只使用InnoDB, ACID, 少量的连接, 队列负载大 #TYPE: SYSTEM #END CONFIG INFO # # 此mysql配置文件例子针对4G内存 # 主要使用INNODB #处理复杂队列并且连接数量较少的mysql服务器 # # 将此文件复制到/etc/my.cnf 作为全局设置, # mysql-data-dir/my.cnf 作为服务器指定设置 # (@[em