标签：
在日常的的开发过程中接触到了SQLServer和MySQL数据库的操作性问题，可能是以前接触的都是SQL Server，才开始接触MySQL，总感觉使用MySQL没有使用SQLserver那么顺手，一些关键的系统函数，比如说开窗、行转列、列转行、自增字段等一系列的问题，虽然最后都找到了替代的方案，但是解决性能问题还是颇费了一些功夫的。对比了一下SQL Server、MySQL在Windows环境下、MySQL在linux环境下的性能，同样的一个存储过程，在存储过程中建立了八个临时表，并循环向每个临时表里插入了十万条数据，字段大概有十二个左右，最后查询出数据，在SQL Server下用了6秒时间，在Linux下的MySQL中用了3秒多的时间，而在Windows环境下的MySQL改为了一千条数据耗费了六十多秒的时间。总的来说性能上的差别还是很大的，下面就来谈谈Linux下的MySQL的配置文件。
设置慢查询时间的长度，以及慢查询日志存放的位置:
long_query_time=1
slow_query_log_file = /var/log/mysql/mysql-slow.log
避免Mysql的外部锁定，减少出错几率，增强稳定性:
skip-external-locking
禁止MySql对外部连接进行DNS解析，使用这一选项可以消除MySQL进行NDS解析的时间。但##需要注意的是：如果开启该选项，则所有远程主机连接授权都要使用IP地址方式了，否则MYSQL将无法正常处理连接请求。
skip-name-resolve
back_log参数的值指出在MySQL暂时停止响应新请求之前，短时间内的多少个请求可以被存,在对堆栈中，如果系统短时间内有很多连接，则需>要增大该参数的值，该参数值指定到来的TCP/IP连接的监听队列的大小。不同的操作系统在这个队列的大小有自己的限制，将back_log设定得高于操作系统的限制将是无效的，其默认值为50，对于LINUX系统而言，推荐设置为小于512的整数:
back_log=1200 binlog_cache_size=64M
索引缓冲区大小，增加它可得到更好的索引处理性能，对于内存在4GB左右的服务器，该参数可设置为256M或384M。如果该参数值设置的过大>反而会使服务器的整体效率降低:
key_buffer_size=512M
设定在网络传输中一次消息传输量的最大值，系统默认值为1MB，最大值是1GB，必须设定为1024的倍数，单位为字节:
max_allowed_packet=64M
设置MySQL每个线程的堆栈大小，默认值足够大，可满足普通操作。可设置范围为128KB至4GB，默认192K:
thread_stack=64M sort_buffer_size=64M
max_connect_errors = 6000 open_files_limit = 65535
table_open_cache=256 max_heap_table_size=16M
设置Thread Cache池中可以缓存的连接池线程最大数量，可设置为0-16384,默认为0。1GB内存我们配置为8，2GB内存我们配置为16，4GB或4GB以上内在我们配置为64:
thread_cache_size=128
指定Mysql查询缓冲区的大小，可以通过在Mysql控制台观察，如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况，如果 Qcache_hits的值非常大，则表明查询缓冲使用的非常频繁 :
query_cache_size=64M
query_cache_limit=64M
设置内在临时表最大值，如果超过该值，则会将临时表写入磁盘，其范围为1KB至4GB:
tmp_table_size=64M
指定MYSQL允许的最大连接进程数，如果在访问程序时经常出现TOO MANY CONNECTIONS的错误提示，则需要增大该参数值:
max_connections=1500
max_user_connections=1500
指定一个请求的最大连接时间，对于4GB左右内在的服务器来说，可以将其设置为5－10:
wait_timeout=100
该参数取值为服务器逻辑CPU数量*2，比如，服务器有两个物理CPU，每个物理CPU支持HT超线程，所以实际取值4*2=8，这也是目前双四核主流 服务器的配置:
join_buffer_size = 64M
开启该选项可以彻底关闭MYSQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MYSQL的数据库服务器，则不要开启该选项，否则>将无法正常连接。 skip-networking 抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush） 硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的>，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安>全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系#统 挂了时才可能丢数据:
innodb_flush_log_at_trx_commit=2
这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写>入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文>件（或者同步到磁盘）中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间:
innodb_log_buffer_size=64M
innodb_buffer_pool_size=64M
innodb_log_file_size=1G
innodb_file_per_table=1
innodb_read_io_threads=10
innodb_write_io_threads=10
innodb_flush_method=O_DIRECT
innodb_io_capacity=1000
innodb_io_capacity_max=1000
innodb_lru_scan_depth=500
innodb_thread_concurrency=0
innodb_autoinc_lock_mode=2
innodb_log_files_in_group=3
innodb_max_dirty_pages_pct=90
innodb_lock_wait_timeout=100
bulk_insert_buffer_size = 16M
innodb_thread_concurrency = 8
innodb_purge_threads = 1
tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误，如果你做很多 #高级 GROUP BY 查询，增加 tmp_table_size 值:
tmp_table_size=512M
随机读取数据缓冲区使用内存(read_rnd_buffer_size)：和顺序读取相对应，当 MySQL 进行非顺序读取（随机读取）数据块的时候，会利用>这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。总的来说，就是当数据块的读取需要满足>一定的顺序的情况下，MySQL 就需要产生随机读取，进而使用到 read_rnd_buffer_size 参数所设置的内存缓冲区:
read_rnd_buffer_size=128M
你最好在定义数据库命名规则的时候就全部采用小写字母加下划线的组合，而不使用任何的大写字母:
lower_case_table_names=1
设置校验模式 :
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
默认配置没开查询缓存:
explicit_defaults_for_timestamp
需要记录进制日志的数据库.如果有多个数据库可用逗号分隔,或者使用多个binlog-do-db选项:
binlog-do-db=showeedb
不需要记录进制日志的数据库.如果有多个数据库可用逗号分隔,或者使用多个binlog-do-db选项 :
binlog-ignore-db=mysql
需要进行同步的数据库.如果有多个数据库可用逗号分隔,或者使用多个replicate-do-db选项:
replicate-do-db=showeedb
不需要同步的数据库.如果有多个数据库可用逗号分隔,或者使用多个replicate-ignore-db选项:
replicate-ignore-db=mysql,test
同步参数:
server-id=1
log_bin=/var/log/mysql/mysql-bin
保证slave挂在任何一台master上都会接收到另一个master的写入信息:
log-slave-updates
sync_binlog=1
auto_increment_offset=1
auto_increment_increment=2
过滤掉一些没什么大问题的错误:
slave-skip-errors=all
标签：
原文地址：http://www.cnblogs.com/wustjz/p/4771914.html
