Chinaunix首页 | 论坛 | 博客
  • 博客访问: 11564
  • 博文数量: 20
  • 博客积分: 427
  • 博客等级: 下士
  • 技术积分: 115
  • 用 户 组: 普通用户
  • 注册时间: 2012-11-23 10:24
文章分类

全部博文(20)

文章存档

2012年(20)

我的朋友

分类: Mysql/postgreSQL

2012-11-23 10:38:09

###
table_cache 参数设置表高速缓存的数目。每个连接进来,都会至少打开一个表缓存。因此, table_cache 的大小应与 max_connections 的设置有关。例如,对于 200 个并行运行的连接,应该让表的缓存至少有 200 × N ,这里 N 是应用可以执行的查询#的一个联接中表的最大数量。此外,还需要为临时表和文件保留一些额外的文件描述符。

当 Mysql 访问一个表时:
如果该表在缓存中已经被打开,则可以直接访问缓存;
如果还没有被缓存,但是在Mysql表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区;
如果表缓存满了,则会按照一定的规则将当前未用的表释放,或者临时扩大表缓存来存放。

使用表缓存的好处是可以更快速地访问表中的内容。

执行 flush tables 会清空缓存的内容。

一般来说,可以通过查看数据库运行峰值时间的状态值 Open_tables #和 Opened_tables ,判断是否需要增加 table_cache 的值(其中 open_tables 是当前打开的表的数量, Opened_tables 则是已经打开的表的数量):
如果你发现open_tables接近(或者等于)table_cache的时候,并且Opened_tables这个值在不断增长,那么你就需要增加table_cache的值了(上述状态值可以使用SHOW STATUS LIKE ‘Open%tables'获得);
还有就是Table_locks_waited比较高的时候,也需要增加table_cache;
注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败
###
table_cache = 512


###
指定MySQL能有的连接数量。当MySQL主线程在一个很短时间内得到非常多的连接请求时,该参数就会起作用。

主线程花费很短的时间检查连接并且启动一个新线程。back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。如果系统在一个短时间内有很多连接,则需要增大该参数的值。换言之,该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自己的限制。如果试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。

当你观察你的主机进程列表,发现大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时,就要加大 back_log 的值。
###
back_log = 600

###
指定 MySQL 允许的最大连接进程数。如果在访问网站时经常出现 Too Many Connections 的错误提示,则需要增大该参数值。
###
max_connections = 5000

###
可以允许多少个错误连接。对于同一主机,如果有超出该参数值个数的中断错误连接,则该主机将被禁止连接。如需对该主机进行解禁,执行:FLUSH HOST;。
###
#max_connect_errors = 60000
max_connect_errors = 10000000

###
指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。
###
wait_timeout = 10

#避免外部锁定
skip-external-locking

###
设置最大包,限制server接受的数据包大小,避免超长SQL的执行问题。

默认值为16M,当MySQL客户端或mysqld服务器收到大于max_allowed_packet字节的信息包时,将发出“信息包过大”错误,并关闭连接。对于某些客户端,如果通信信息包过大,在执行查询期间,可能会遇到“丢失与MySQL服务器的连接”错误。默认值16M。

增加该变量的值十分安全,这是因为仅当需要时才会分配额外内存。例如,仅当你发出长查询或mysqld必须返回大的结果行时mysqld才会分配更多内存。该变量之所以取较小默认值是一种预防措施,以捕获客户端和服务器之间的错误信息包,并确保不会因偶然使用大的信息包而导致内存溢出。
###
max_allowed_packet = 32M

###
索引缓存大小: 它决定了数据库索引处理的速度,尤其是索引读的速度。

key_buffer_size指定用于索引的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),到你能负担得起那样多。如果你使它太大,系统将开始换页并且真的变慢了。对于内存在4GB左右的服务器该参数可设置为384M或512M。通过检查状态值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 = 384M

# tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小,MySQL产生一个 The table tbl_name is full 形式的错误,如果你做很多高级 GROUP BY 查询,增加 tmp_table_size 值。
tmp_table_size = 246M


###
查询排序时所能使用的缓冲区大小。注意:该参数对应的分配内存是每连接独占!如果有100个连接,那么实际分配的总共排序缓冲区大小为100 × 4 = 400MB。所以,对于内存在4GB左右的服务器推荐设置为4-8M。
###
sort_buffer_size = 4M

###
MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySql会为它分配一段内存缓冲区。如果对表的顺序扫描请求非常频繁,并且你认为频繁扫描进行得太慢,可以通过增加该变量值以及内存缓冲区大小提高其性能。和sort_buffer_size一样,该参数对应的分配内存也是每连接独享!
###
read_buffer_size = 4M

###
MySql的随机读(查询操作)缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySql会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySql会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。
###
read_rnd_buffer_size = 16M


###
联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每连接独享!
###
join_buffer_size = 8M

###
MyISAM表发生变化时重新排序所需的缓冲
###
#myisam_sort_buffer_size = 64M
myisam_sort_buffer_size = 128M

###
指定MySQL查询缓冲区的大小。重点优化参数(主库 增删改-MyISAM)!!!!!!!!

可以通过在MySQL控制台执行以下命令观察:
# > SHOW VARIABLES LIKE ‘%query_cache%';
# > SHOW STATUS LIKE ‘Qcache%';
如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况;
如果Qcache_hits的值非常大,则表明查询缓冲使用非常频繁,如果该值较小反而会影响效率,那么可以考虑不用查询缓冲;
Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多。

对于使用MySQL的用户,对于这个变量大家一定不会陌生。前几年的MyISAM引擎优化中,这个参数也是一个重要的优化参数。但随着发展,这个参数也爆露出来一些问题。机器的内存越来越大,人们也都习惯性的把以前有用的参数分配的值越来越大。这个参数加大后也引发了一系列问题!!!

我们首先分析一下query_cache_size的工作原理:一个SELECT查询在DB中工作后,DB会把该语句缓存下来,当同样的一个SQL再次来到DB里调用时,DB在该表没发生变化的情况下把结果从缓存中返回给Client。这里有一个关建点,就是DB在利用Query_cache工作时,要求该语句涉及的表在这段时间内没有发生变更。那如果该表在发生变更时,Query_cache里的数据又怎么处理呢?首先要把Query_cache和该表相关的语句全部置为失效,然后再写入更新。那么如果Query_cache非常大,该表的查询结构又比较多,查询语句失效就会很慢,导致该表上的更新或是Insert就会很慢,这样看到的就是Update或是Insert怎么这么慢了。

所以在数据库写入量或是更新量也比较大的系统,该参数不适合分配过大。而且在高并发,写入量大的系统,建系把该功能禁掉。!!!!!!!!!!!!!!!!
###
#query_cache_size = 64M
query_cache_size = 8M

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

###
默认是4KB,设置值大对大数据查询有好处,但如果你的查询都是小数据查询,就容易造成内存碎片和浪费

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit(如果你的查询都是小数据量的话)。

查询缓存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小,要不就是碎片太多。

查询缓存命中率 = (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%
###
query_cache_min_res_unit = 2k

default-storage-engine = MyISAM


###
服务器线程缓存.

这个值表示可以重新利用的保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求,那么请求将从缓存中读取,如果缓存中是空的或者是新的请求,那么这个线程将被重新创建。

如果有很多新的线程,增加这个值可以改善系统性能.通过比较 Connections 和 Threads_created 状态的变量,可以看到这个变量的作用

###
thread_cache_size = 64

###
最大并发线程数。属需要重点优化参数!!!!!

设置thread_concurrency的值的正确与否, 对mysql的性能影响很大, 在多个cpu(或多核)的情况下,错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工作的情况。

取值为服务器逻辑CPU数量×2,如果CPU支持H.T超线程,再×2。例如,服务器有2颗物理CPU,而每颗物理CPU又支持H.T超线程,所以实际取值为4 × 2 = 8
###
thread_concurrency = 8

#限定用于每个数据库线程的栈大小。默认设置足以满足大多数应用
thread_stack = 192K

###
开启该选项可以彻底关闭MySQL的TCP/IP连接方式,如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项!否则将无法正常连接!
###
skip-networking

#基于SQL语句的复制(statement-based replication, SBR),基于行的复制(row-based replication, RBR),混合模式复制(mixed-based replication, MBR)。相应地,binlog的格式也有三种:STATEMENT,ROW,MIXED。

binlog_format = MIXED


#独享表空间(关闭)

innodb_file_per_table = 0

# InnoDB 有其内置的死锁检测机制,能导致未完成的事务回滚。但是,如果结合InnoDB使用MyISAM的lock tables 语句或第三方事务引擎,则InnoDB无法识别死锁。为消除这种可能性,可以将innodb_lock_wait_timeout设置为一个整数值,指示 MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)

innodb_lock_wait_timeout = 120

# 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关闭的时间。

innodb_max_dirty_pages_pct = 90


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

innodb_log_files_in_group = 3


#此参数确定数据日志文件的大小,以M为单位,更大的设置可以提高性能,但也会增加恢复故障数据库所需的时间

innodb_log_file_size = 128M


#此参数确定些日志文件所用的内存大小,以M为单位。缓冲区更大能提高性能,但意外的故障将会丢失数据.MySQL开发人员建议设置为1-8M之间

innodb_log_buffer_size = 16M


#如果将此参数设置为1,将在每次提交事务后将日志写入磁盘。为提供性能,可以设置为0或2,但要承担在发生故障时丢失数据的风险。设置为0表示事务日志写入日志文件,而日志文件每秒刷新到磁盘一次。设置为2表示事务日志将在提交时写入日志,但日志文件每次刷新到磁盘一次。

innodb_flush_log_at_trx_commit = 2


# 在InnoDb核心内的允许线程数量. 最优值依赖于应用程序,硬件以及操作系统的调度方式. 过高的值可能导致线程的互斥颠簸.

innodb_thread_concurrency = 8


#文件IO的线程数,一般为 4,但是在 Windows 下,可以设置得较大。

innodb_file_io_threads = 4

###
这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更为敏感。MyISAM可以在默认的 key_buffer_size 设置下运行的可以,然而Innodb在默认的 innodb_buffer_pool_size 设置下却跟蜗牛似的。由于Innodb把数据和索引都缓存起来,无需留给操作系统太多的内存,因此如果只需要用Innodb的话则可以设置它高达 70-80% 的可用内存。一些应用于 key_buffer 的规则有 — 如果你的数据量不大,并且不会暴增,那么无需把 innodb_buffer_pool_size 设置的太大了
###
innodb_buffer_pool_size = 512M

#这个参数用来设置 InnoDB 存储的数据目录信息和其它内部数据结构的内存池大小,类似于Oracle的library cache。这不是一个强制参数,可以被突破。

innodb_additional_mem_pool_size = 16M


###
用来容纳InnoDB为数据表的表空间: 可能涉及一个以上的文件; 每一个表空间文件的最大长度都必须以字节(B)、兆字节(MB)或千兆字节(GB)为单位给出; 表空间文件的名字必须以分号隔开; 最后一个表空间文件还可以带一个autoextend属性和一个最大长度(max:n)。例如,ibdata1:1G; ibdata2:1G:autoextend:max:2G的意思是: 表空间文件ibdata1的最大长度是1GB,ibdata2的最大长度也是1G,但允许它扩充到2GB。
###

innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend

###
设定默认的事务隔离级别.可用的级别如下:

1.READ UNCOMMITTED-读未提交
2.READ COMMITTE-读已提交
3.REPEATABLE READ -可重复读
4.SERIALIZABLE -串行
###
transaction_isolation = READ-COMMITTED


#配置从库上的更新操作是否写二进制文件,如果这台从库,还要做其他从库的主库,那么就需要打这个参数,以便从库的从库能够进行日志同步。这个参数要和—logs-bin一起使用

log-slave-updates

log-bin = /data/mysql/3306/binlog/binlog


#自动检查和修复没有适当关闭的 MyISAM 表

myisam_recover


# 如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们.
# 这对于拥有多个CPU以及大量内存情况的用户,是一个很好的选择.

myisam_repair_threads = 1

# MySQL重建索引时所允许的最大临时文件的大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE).
# 如果文件大小比此值更大,索引会通过键值缓冲创建(更慢)

myisam_max_sort_file_size = 10G


#批量插入数据缓存大小,可以有效提高插入效率,默认为8M

bulk_insert_buffer_size = 64M


###
开启慢查询日志( slow query log )

慢查询日志对于跟踪有问题的查询非常有用。它记录所有查过long_query_time的查询,如果需要,还可以记录不使用索引的记录。

下面是一个慢查询日志的例子:
开启慢查询日志,需要设置参数log_slow_queries、long_query_times、log-queries-not-using-indexes。
log_slow_queries指定日志文件,如果不提供文件名,MySQL将自己产生缺省文件名。long_query_times指定慢查询的阈值,缺省是10秒。log-queries-not-using-indexes是4.1.0以后引入的参数,它指示记录不使用索引的查询。设置 long_query_time=10
###
long_query_time = 10
log-slow-queries =
log-queries-not-using-indexes

另外附上使用show status命令查看mysql状态相关的值及其含义:
aborted_clients 客户端非法中断连接次数
aborted_connects 连接mysql失败次数
com_xxx xxx命令执行次数,有很多条
connections 连接mysql的数量
Created_tmp_disk_tables 在磁盘上创建的临时表
Created_tmp_tables 在内存里创建的临时表
Created_tmp_files 临时文件数
Key_read_requests The number of requests to read a key block from the cache
Key_reads The number of physical reads of a key block from disk
Max_used_connections 同时使用的连接数
Open_tables 开放的表
Open_files 开放的文件
Opened_tables 打开的表
Questions 提交到server的查询数
Sort_merge_passes 如果这个值很大,应该增加my.cnf中的sort_buffer值
Uptime 服务器已经工作的秒数


提升性能的建议:
1.如果 opened_tables 太大,应该把my.cnf中的table_cache变大

2.如果 Key_reads 太大,则应该把my.cnf中key_buffer_size变大.可以用Key_reads/Key_read_requests计算出cache失败率

3.如果 Handler_read_rnd 太大,则你写的SQL语句里很多查询都是要扫描整个表,而没有发挥索引的键的作用

4.如果 Threads_created 太大,就要增加my.cnf中 thread_cache_size 的值.可以用 Threads_created/Connections 计算cache命中率

5.如果 Created_tmp_disk_tables 太大,就要增加my.cnf中tmp_table_size的值,用基于内存的临时表代替基于磁盘的

阅读(258) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~