1 目的:
通过根据服务器目前状况, 修改 Mysql 的系统参数, 达到合理利用服务器现有资源, 最大合理的提高 MySQL 性能
2 服务器参数:
32G 内存 4 个 CPU, 每个 CPU 8 核
3MySQL 目前安装状况
MySQL 目前安装, 用的是 MySQL 默认的最大支持配置拷贝的是 my-huge.cnf. 编码已修改为 UTF-8. 具体修改及安装 MySQL, 可以参考 <<Linux 系统上安装 MySQL 5.5>> 帮助文档
4 修改 MySQL 配置
打开 MySQL 配置文件 my.cnf
vi /etc/my.cnf |
4.1 MySQL 非缓存参数变量介绍及修改
4.1.1 修改 back_log 参数值: 由默认的 50 修改为 500.(每个连接 256kb, 占用: 125M)
back_log=500
back_log 值指出在 MySQL 暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。也就是说,如果 MySql 的连接数据达到 max_connections 时,新来的请求将会被存在堆栈中,以等待某一连接释放资源,该堆栈的数量即 back_log,如果等待连接的数量超过 back_log,将不被授予连接资源。将会报:unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时. back_log 值不能超过 TCP/IP 连接的侦听队列的大小。若超过则无效,查看当前系统的 TCP/IP 连接的侦听队列的大小命令:cat /proc/sys/net/ipv4/tcp_max_syn_backlog 目前系统为 1024。对于 Linux 系统推荐设置为小于 512 的整数。 修改系统内核参数,)http://www.51testing.com/html/64/n-810764.html 查看 mysql 当前系统默认 back_log 值,命令: show variables like 'back_log'; 查看当前数量 |
4.1.2 修改 wait_timeout 参数值, 由默认的 8 小时, 修改为 30 分钟 (本次不用)
wait_timeout=1800(单位为妙)
我对 wait-timeout 这个参数的理解:MySQL 客户端的数据库连接闲置最大时间值。 说得比较通俗一点,就是当你的 MySQL 连接闲置超过一定时间后将会被强行关闭。MySQL 默认的 wait-timeout 值为 8 个小时,可以通过命令 show variables like 'wait_timeout'查看结果值;。 设置这个值是非常有意义的,比如你的网站有大量的 MySQL 链接请求(每个 MySQL 连接都是要内存资源开销的 & nbsp;),由于你的程序的原因有大量的连接请求空闲啥事也不干,白白占用内存资源,或者导致 MySQL 超过最大连接数从来无法新建连接导致 "Too many connections" 的错误。在设置之前你可以查看一下你的 MYSQL 的状态(可用 show processlist),如果经常发现 MYSQL 中有大量的 Sleep 进程,则需要 & nbsp; 修改 wait-timeout 值了。 interactive_timeout:服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在 mysql_real_connect() 中使用 CLIENT_INTERACTIVE 选项的客户端。 wait_timeout: 服务器关闭非交互连接之前等待活动的秒数。在线程启动时,根据全局 wait_timeout 值或全局 & nbsp;interactive_timeout 值初始化会话 wait_timeout 值,取决于客户端类型 (由 mysql_real_connect() 的连接选项 CLIENT_INTERACTIVE 定义). 这两个参数必须配合使用。否则单独设置 wait_timeout 无效 |
4.1.3 修改 max_connections 参数值, 由默认的 151, 修改为 3000(750M)
max_connections=3000
max_connections 是指 MySql 的最大连接数,如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于 MySql 会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。可以过'conn%'通配符查看当前状态的连接数量,以定夺该值的大小。 MySQL 服务器允许的最大连接数 16384; 查看系统当前最大连接数: show variables like 'max_connections'; |
4.1..4 修改 max_user_connections 值, 由默认的 0, 修改为 800
max_user_connections=800
max_user_connections 是指每个数据库用户的最大连接 针对某一个账号的所有客户端并行连接到 MYSQL 服务的最大并行连接数。简单说是指同一个账号能够同时连接到 mysql 服务的最大连接数。设置为 0 表示不限制。 目前默认值为:0 不受限制。 这儿顺便介绍下 Max_used_connections: 它是指从这次 mysql 服务启动到现在,同一时刻并行连接数的最大值。它不是指当前的连接情况,而是一个比较值。如果在过去某一个时刻,MYSQL 服务同时有 1000 个请求连接过来,而之后再也没有出现这么大的并发请求时,则 Max_used_connections=1000. 请注意与 show variables 里的 max_user_connections 的区别。默认为 0 表示无限大。 查看 max_user_connections 值 show variables like 'max_user_connections'; |
4.1.5 修改 thread_concurrency 值, 由目前默认的 8, 修改为 64
thread_concurrency=64
thread_concurrency 的值的正确与否, 对 mysql 的性能影响很大, 在多个 cpu(或多核) 的情况下,错误设置了 thread_concurrency 的值, 会导致 mysql 不能充分利用多 cpu(或多核), 出现同一时刻只能一个 cpu(或核) 在工作的情况。 thread_concurrency 应设为 CPU 核数的 2 倍. 比如有一个双核的 CPU, 那 thread_concurrency 的应该为 4; 2 个双核的 cpu, thread_concurrency 的值应为 8. 比如:根据上面介绍我们目前系统的配置,可知道为 4 个 CPU, 每个 CPU 为 8 核,按照上面的计算规则,这儿应为: 4*8*2=64 查看系统当前 thread_concurrency 默认配置命令: show variables like 'thread_concurrency'; |
4.1.6 添加 skip-name-resolve, 默认被注释掉, 没有该参数
skip-name-resolve
skip-name-resolve:禁止 MySQL 对外部连接进行 DNS 解析,使用这一选项可以消除 MySQL 进行 DNS 解析的时间。但需要注意,如果开启该选项,则所有远程主机连接授权都要使用 IP 地址方式,否则 MySQL 将无法正常处理连接请求! |
4.1.7 skip-networking, 默认被注释掉没有该参数 (本次无用)
skip-networking 建议被注释掉, 不要开启
开启该选项可以彻底关闭 MySQL 的 TCP/IP 连接方式,如果 web 服务器是以远程连接的方式访问 MySQL 数据库服务器则不要开启该选项!否则将无法正常连接! |
4.1.8 default-storage-engine(设置 MySQL 的默认存储引擎)
default-storage-engine= InnoDB(设置 InnoDB 类型, 另外还可以设置 MyISAM 类型)
设置创建数据库及表默认存储类型 show table status like 'tablename'显示表的当前存储状态值 查看 MySQL 有哪些存储状态及默认存储状态 show engines; 创建表并指定存储类型 CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB; 修改表存储类型: Alter table tableName engine =engineName 备注:设置完后把以下几个开启: # Uncomment the following if you are using InnoDB tables innodb_data_home_dir = /var/lib/mysql #innodb_data_file_path = ibdata1:1024M;ibdata2:10M:autoextend(要注释掉,否则会创建一个新的把原来的替换的。) innodb_log_group_home_dir = /var/lib/mysql # You can set .._buffer_pool_size up to 50 - 80 % # of RAM but beware of setting memory usage too high innodb_buffer_pool_size = 1000M innodb_additional_mem_pool_size = 20M # Set .._log_file_size to 25 % of buffer pool size innodb_log_file_size = 500M innodb_log_buffer_size = 20M innodb_flush_log_at_trx_commit = 0 innodb_lock_wait_timeout = 50 设置完后一定记得把 MySQL 安装目录地址(我们目前是默认安装所以地址 / var/lib/mysql/)下的 ib_logfile0 和 ib_logfile1 删除掉。否则重启 MySQL 起动失败。 |
4.2 MySQL 缓存变量介绍及修改
数据库属于 IO 密集型的应用程序,其主职责就是数据的管理及存储工作。而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个 & nbsp;IO 是在毫秒级别,二者相差 3 个数量级。所以,要优化数据库,首先第一步需要优化的就是 IO,尽可能将磁盘 IO 转化为内存 IO。本文先从 MySQL 数据库 & nbsp;IO 相关参数 (缓存参数) 的角度来看看可以通过哪些参数进行 IO 优化 |
4.2.1 全局缓存
启动 MySQL 时就要分配并且总是存在的全局缓存。目前有:key_buffer_size(默认值:402653184, 即 384M)、innodb_buffer_pool_size(默认值:134217728 即:128M)、innodb_additional_mem_pool_size(默认值:8388608 即:8M)、innodb_log_buffer_size(默认值:8388608 即:8M)、query_cache_size(默认值:33554432 即:32M) 等五个。总共:560M. 这些变量值都可以通过命令如:show variables like '变量名'; 查看到。 |
4.2.1.1:key_buffer_size, 本系统目前为 384M, 可修改为 400M
key_buffer_size=400M
key_buffer_size 是用于索引块的缓冲区大小,增加它可得到更好处理的索引 (对所有读和多重写),对 MyISAM(MySQL 表存储的一种类型,可以百度等查看详情) 表性能影响最大的一个参数。如果你使它太大,系统将开始换页并且真的变慢了。严格说是它决定了数据库索引处理的速度,尤其是索引读的速度。对于内存在 4GB 左右的服务器该参数可设置为 256M 或 384M. 怎么才能知道 key_buffer_size 的设置是否合理呢,一般可以检查状态值 Key_read_requests 和 Key_reads ,比例 key_reads / key_read_requests 应该尽可能的低,比如 1:100,1:1000 ,1:10000。其值可以用以下命令查得:show status like 'key_read%'; 比如查看系统当前 key_read 和 key_read_request 值为: +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Key_read_requests | 28535 | | Key_reads | 269 | +-------------------+-------+ 可知道有 28535 个请求,有 269 个请求在内存中没有找到直接从硬盘读取索引. 未命中缓存的概率为:0.94%=269/28535*100%. 一般未命中概率在 0.1 之下比较好。目前已远远大于 0.1,证明效果不好。若命中率在 0.01 以下,则建议适当的修改 key_buffer_size 值。 http://dbahacker.com/mysql/innodb-myisam-compare(
) http://kb.cnblogs.com/page/99810/(查看存储引擎介绍) MyISAM、InnoDB、MyISAM Merge 引擎、InnoDB、memory(heap)、archive |
4.2.1.2:innodb_buffer_pool_size(默认 128M)
innodb_buffer_pool_size=1024M(1G)
innodb_buffer_pool_size: 主要针对 InnoDB 表性能影响最大的一个参数。功能与 Key_buffer_size 一样。InnoDB 占用的内存,除 innodb_buffer_pool_size 用于存储页面缓存数据外,另外正常情况下还有大约 8% 的开销,主要用在每个缓存页帧的描述、adaptive hash 等数据结构,如果不是安全关闭,启动时还要恢复的话,还要另开大约 12% 的内存用于恢复,两者相加就有差不多 21% 的开销。假设:12G 的 innodb_buffer_pool_size,最多的时候 InnoDB 就可能占用到 14.5G 的内存。若系统只有 16G,而且只运行 MySQL,且 MySQL 只用 InnoDB, 那么为 MySQL 开 12G,是最大限度地利用内存了。 另外 InnoDB 和 & nbsp;MyISAM 存储引擎不同, MyISAM 的 & nbsp;key_buffer_size 只能缓存索引键,而 & nbsp;innodb_buffer_pool_size 却可以缓存数据块和索引键。适当的增加这个参数的大小,可以有效的减少 & nbsp;InnoDB 类型的表的磁盘 & nbsp;I/O 。 当我们操作一个 & nbsp;InnoDB 表的时候,返回的所有数据或者去数据过程中用到的任何一个索引块,都会在这个内存区域中走一遭。 可以通过 & nbsp;(Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率,并根据命中率来调整 & nbsp;innodb_buffer_pool_size 参数大小进行优化。值可以用以下命令查得:show status like 'Innodb_buffer_pool_read%'; 比如查看当前系统中系统中 | Innodb_buffer_pool_read_requests | 1283826 | | Innodb_buffer_pool_reads | 519 | +---------------------------------------+---------+ 其命中率 99.959%=(1283826-519)/1283826*100% 命中率越高越好。 |
4.2.1.3:innodb_additional_mem_pool_size(默认 8M)
innodb_additional_mem_pool_size=20M
innodb_additional_mem_pool_size 设置了 InnoDB 存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小,所以当我们一个 MySQL Instance 中的数据库对象非常多的时候,是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。 这个参数大小是否足够还是比较容易知道的,因为当过小的时候,MySQL 会记录 Warning 信息到数据库的 error log 中,这时候你就知道该调整这个参数大小了。 查看当前系统 mysql 的 error 日志 & nbsp; cat /var/lib/mysql / 机器名. error 发现有很多 waring 警告。所以要调大为 20M. 根据 MySQL 手册,对于 2G 内存的机器,推荐值是 20M。 32G 内存的 & nbsp;100M |
4.2.1.4:innodb_log_buffer_size(默认 8M)
innodb_log_buffer_size=20M
innodb_log_buffer_size 这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer,InnoDB 在写事务日志的时候,为了提高性能,也是先将信息写入 Innofb Log Buffer 中,当满足 innodb_flush_log_trx_commit 参数所设置的相应条件 (或者日志缓冲区写满) 之后,才会将日志写到文件 & nbsp;(或者同步到磁盘) 中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。 InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 & nbsp;1M 至 & nbsp;8M。大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交 (commit)。 因此,如果有大的事务处理,设置大的日志缓冲可以减少磁盘 I/O。 在 & nbsp; my.cnf 中以数字格式设置。 默认是 8MB,系的如频繁的系统可适当增大至 4MB~8MB。当然如上面介绍所说,这个参数实际上还和另外的 flush 参数相关。一般来说不建议超过 32MB 注:innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响, 默认值为 1。该参数可以设置为 0,1,2,解释如下: 0:log buffer 中的数据将以每秒一次的频率写入到 log file 中,且同时会进行文件系统到磁盘的同步操作,但是每个事务的 commit 并不会触发任何 log buffer 到 log file 的刷新或者文件系统到磁盘的刷新操作; 1:在每次事务提交的时候将 log buffer 中的数据都会写入到 log file,同时也会触发文件系统到磁盘的同步; 2:事务提交会触发 log buffer 到 log file 的刷新,但并不会触发磁盘文件系统到磁盘的同步。此外,每秒会有一次文件系统到磁盘同步操作。 实际测试发现,该值对插入数据的速度影响非常大,设置为 2 时插入 10000 条记录只需要 2 秒,设置为 0 时只需要 1 秒,而设置为 1 时则需要 229 秒。因此,MySQL 手册也建议尽量将插入操作合并成一个事务,这样可以大幅提高速度。根据 MySQL 手册,在存在丢失最近部分事务的危险的前提下,可以把该值设为 0。 |
4.5.1.5:query_cache_size(默认 32M)
query_cache_size=40M
query_cache_size: 主要用来缓存 MySQL 中的 ResultSet,也就是一条 SQL 语句执行的结果集,所以仅仅只能针对 select 语句。当我们打开了 & nbsp;Query Cache 功能,MySQL 在接受到一条 select 语句的请求后,如果该语句满足 Query Cache 的要求 (未显式说明不允许使用 Query Cache,或者已经显式申明需要使用 Query Cache),MySQL 会直接根据预先设定好的 HASH 算法将接受到的 select 语句以字符串方式进行 hash,然后到 Query Cache 中直接查找是否已经缓存。也就是说,如果已经在缓存中,该 select 请求就会直接将数据返回,从而省略了后面所有的步骤 (如 SQL 语句的解析,优化器优化以及向存储引擎请求数据等),极大的提高性能。根据 MySQL 用户手册,使用查询缓冲最多可以达到 238% 的效率。 当然,Query Cache 也有一个致命的缺陷,那就是当某个表的数据有任何任何变化,都会导致所有引用了该表的 select 语句在 Query Cache 中的缓存数据失效。所以,当我们的数据变化非常频繁的情况下,使用 Query Cache 可能会得不偿失 Query Cache 的使用需要多个参数配合,其中最为关键的是 query_cache_size 和 query_cache_type,前者设置用于缓存 & nbsp;ResultSet 的内存大小,后者设置在何场景下使用 Query Cache。在以往的经验来看,如果不是用来缓存基本不变的数据的 MySQL 数据库,query_cache_size 一般 256MB 是一个比较合适的大小。当然,这可以通过计算 Query Cache 的命中率 (Qcache_hits/(Qcache_hits+Qcache_inserts)*100)) 来进行调整。 query_cache_type 可以设置为 0(OFF),1(ON) 或者 2(DEMOND),分别表示完全不使用 query cache,除显式要求不使用 query cache(使用 sql_no_cache) 之外的所有的 select 都使用 query cache,只有显示要求才使用 query cache(使用 sql_cache)。如果 Qcache_lowmem_prunes 的值非常大,则表明经常出现缓冲. 如果 Qcache_hits 的值也非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小; 根据命中率 (Qcache_hits/(Qcache_hits+Qcache_inserts)*100)) 进行调整,一般不建议太大,256MB 可能已经差不多了,大型的配置型静态数据可适当调大. 可以通过命令:show status like 'Qcache_%'; 查看目前系统 Query catch 使用大小 | Qcache_hits | 1892463 | | Qcache_inserts | 35627 命中率 98.17%=1892463/(1892463 +35627)*100 |
4.2.2 局部缓存
除了全局缓冲,MySql 还会为每个连接发放连接缓冲。个连接到 MySQL 服务器的线程都需要有自己的缓冲。大概需要立刻分配 256K,甚至在线程空闲时,它们使用默认的线程堆栈,网络缓存等。事务开始之后,则需要增加更多的空间。运行较小的查询可能仅给指定的线程增加少量的内存消耗,然而如果对数据表做复杂的操作例如扫描、排序或者需要临时表,则需分配大约 read_buffer_size, sort_buffer_size,read_rnd_buffer_size,tmp_table_size 大小的内存空间. 不过它们只是在需要的时候才分配,并且在那些操作做完之后就释放了。有的是立刻分配成单独的组块。tmp_table_size 可能高达 MySQL 所能分配给这个操作的最大内存空间了 。注意,这里需要考虑的不只有一点——可能会分配多个同一种类型的缓存,例如用来处理子查询。一些特殊的查询的内存使用量可能更大——如果在 MyISAM 表上做成批的插入 时需要分配 & nbsp;bulk_insert_buffer_size 大小的内存;执行 & nbsp;ALTER TABLE, OPTIMIZE TABLE, REPAIR TABLE 命令时需要分配 & nbsp;myisam_sort_buffer_size 大小的内存。 |
4.2.2.1:read_buffer_size(默认值: 2097144 即 2M)
read_buffer_size=4M
read_buffer_size 是 MySql 读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySql 会为它分配一段内存缓冲区。read_buffer_size 变量控制这一 缓冲区的大小。如果对表的顺序扫描请求非常频繁,并且你认为频繁扫描进行得太慢,可以通过增加该变量值以及内存缓冲区大小提高其性能. |
4.2.2.2:sort_buffer_size(默认值: 2097144 即 2M)
sort_buffer_size=4M
sort_buffer_size 是 MySql 执行排序使用的缓冲大小。如果想要增加 ORDER BY 的速度,首先看是否可以让 MySQL 使用索引而不是额外的排序阶段。如果不能,可以尝试增加 sort_buffer_size 变量的大小 |
4.2.2.3: read_rnd_buffer_size(默认值: 8388608 即 8M)
read_rnd_buffer_size=8M
read_rnd_buffer_size 是 MySql 的随机读缓冲区大小。当按任意顺序读取行时 (例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySql 会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但 MySql 会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开 销过大。 |
4.2.2.4: tmp_table_size(默认值: 8388608 即: 16M)
tmp_table_size=16M
tmp_table_size 是 MySql 的 heap (堆积)表缓冲大小。所有联合在一个 DML 指令内完成,并且大多数联合甚至可以不用临时表即可以完成。大多数临时表是基于内 存的 (HEAP) 表。具有大的记录长度的临时表 & nbsp;(所有列的长度的和) 或包含 BLOB 列的表存储在硬盘上。如果某个内部 heap(堆积)表大小超过 tmp_table_size,MySQL 可以根据需要自 动将内存中的 heap 表改为基于硬盘的 MyISAM 表。还可以通过设置 tmp_table_size 选项来增加临时表的大小。也就是说,如果调高该值,MySql 同时将增加 heap 表的大小,可达到提高 联接查询速度的效果。 |
4.2.2.5:record_buffer:(默认值:)
record_buffer 每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。默认数值是 131072 (128K) |
4.2.3 其它缓存:
4.2.3.1:table_cache(默认值: 512)
TABLE_CACHE(5.1.3 及以后版本又名 TABLE_OPEN_CACHE) table_cache 指定表高速缓存的大小。每当 MySQL 访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的状态值 Open_tables 和 Opened_tables,可以决定是否需要增加 table_cache 的值。如果你发现 open_tables 等于 table_cache,并且 opened_tables 在不断增长,那么你就需要增加 table_cache 的值了(上述状态值可以使用 SHOW STATUS LIKE 'Open%tables'获得)。注意,不能盲目地把 table_cache 设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败。 SHOW STATUS LIKE 'Open%tables'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Open_tables | 356 | | Opened_tables | 0 | +---------------+-------+ 2 rows in set (0.00 sec) open_tables 表示当前打开的表缓存数,如果执行 flush tables 操作,则此系统会关闭一些当前没有使用的表缓存而使得此状态值减小; opend_tables 表示曾经打开的表缓存数,会一直进行累加,如果执行 flush tables 操作,值不会减小。 在 mysql 默认安装情况下,table_cache 的值在 2G 内存以下的机器中的值默认时 256 到 512,如果机器有 4G 内存, 则默认这个值 & nbsp; 是 2048,但这决意味着机器内存越大,这个值应该越大,因为 table_cache 加大后,使得 mysql 对 SQL 响应的速度更快了,不可避免的会产生 & nbsp; 更多的死锁(dead lock),这样反而使得数据库整个一套操作慢了下来,严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断,找到最适合你维护的库的 & nbsp;table_cache 值。 由于 MySQL 是多线程的机制, 为了提高性能, 每个线程都是独自打开自己需要的表的文件描 & nbsp; 述符, 而不是通过共享已经打开的. 针对不同存储引擎处理的方法当然也不一样 在 myisam 表引擎中, 数据文件的描述符 & nbsp;(descriptor) 是不共享的, 但是索引文件的描述符却是所有线程共享的. Innodb 中和使用表空间类型有关, 假如是共享表空间那么实际就一个数 & nbsp; 据文件, 当然占用的数据文件描述符就会比独立表空间少. mysql 手册上给的建议大小 & nbsp; 是: table_cache=max_connections*n n 表示查询语句中最大表数, 还需要为临时表和文件保留一些额外的文件描述符。 这个数据遭到很多质疑, table_cache 够用就好, 检查 & nbsp;Opened_tables 值, 如果这个值很大, 或增长很快那么你就得考虑加大 table_cache 了. table_cache:所有线程打开的表的数目。增大该值可以增加 mysqld 需要的文件描述符的数量。默认值是 64. |
4.2.3.2 thread_cache_size (服务器线程缓存)
thread_cache_size=64
默认的 thread_cache_size=8,但是看到好多配置的样例里的值一般是 32,64,甚至是 128,感觉这个参数对优化应该有帮助,于是查了下: 根据调查发现以上服务器线程缓存 thread_cache_size 没有进行设置,或者设置过小, 这个值表示可以重新利用保存在缓存中线程的数量, 当断开连接时如果缓存中还有空间, 那么客户端的线程将被放到缓存中, 如果线程重新被请求,那么请求将从缓存中读取, 如果缓存中是空的或者是新的请求,那么这个线程将被重新创建, 如果有很多新的线程,增加这个值可以改善系统性能. 通过比较 & nbsp;Connections 和 & nbsp;Threads_created 状态的变量,可以看到这个变量的作用。(–> 表示要调整的值) 根据物理内存设置规则如下: 1G —> 8 2G —> 16 3G —> 32 >3G —> 64 mysql> show status like 'thread%'; +——————-+——-+ | Variable_name | Value | +——————-+——-+ | Threads_cached | 0 | <—当前被缓存的空闲线程的数量 | Threads_connected | 1 | <—正在使用(处于连接状态)的线程 | Threads_created | 1498 | <—服务启动以来,创建了多少个线程 | Threads_running | 1 | <—正在忙的线程(正在查询数据,传输数据等等操作) +——————-+——-+ 查看开机起来数据库被连接了多少次? mysql> show status like '%connection%'; +———————-+——-+ | Variable_name | Value | +———————-+——-+ | Connections | 1504 | –> 服务启动以来,历史连接数 | Max_used_connections | 2 | +———————-+——-+ 通过连接线程池的命中率来判断设置值是否合适?命中率超过 90% 以上, 设定合理。 (Connections - Threads_created) / Connections * 100 % |
来源: http://blog.csdn.net/nightelve/article/details/17393631