MySQL数据库服务器端核心参数详解和推荐配置之三
时间:2016-05-29 12:36 来源:linux.it.net.cn 作者:IT
MySQL手册上也有服务器端参数的解释，以及参数值的相关说明信息，现针对我们大家重点需要注意、需要修改或影响性能的服务器端参数，作其用处的 解释和如何配置参数值的推荐，此事情拖了不少时间，为方便大家帮忙纠错（注：总是断断续续写的，可能存在笔误），先以文章的方式发布到网站，后续确定没问 题，将会通过新浪微博的微盘提供PPT下载，方便学习和参考。
l innodb_flush_log_at_trx_commit AND sync_binlog
innodb_flush_log_at_trx_commit = N：
N=0 – 每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上；
N=1 – 每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上；
N=2 – 每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件，但不一定刷新到磁盘上，而是取决于操作系统的调度；
sync_binlog = N：
N>0 — 每向二进制日志文件写入N条SQL或N个事务后，则把二进制日志文件的数据刷新到磁盘上；
N=0 — 不主动刷新二进制日志文件的数据到磁盘上，而是由操作系统决定；
推荐配置组合：
N=1,1 — 适合数据安全性要求非常高，而且磁盘IO写能力足够支持业务，比如充值消费系统；
N=1,0 — 适合数据安全性要求高，磁盘IO写能力支持业务不富余，允许备库落后或无复制；
N=2,0或2,m(0<m<100) — 适合数据安全性有要求，允许丢失一点事务日志，复制架构的延迟也能接受；
N=0,0 — 磁盘IO写能力有限，无复制或允许复制延迟稍微长点能接受，例如：日志性登记业务；
l innodb_file_per_table
启用单表空间，减少共享表空间维护成本，减少空闲磁盘空间释放的压力。另外，大数据量情况下 的性能，也会有性能上的提升，为此建议大家使用独立表空间 代替 共享表空间的方式；
l key_buffer_size
key_buffer_size只能缓存MyISAM或类MyISAM引擎的索引数据，而innodb_buffer_pool_size不仅能缓存索 引数据，还能缓存元数据，但是对于我们只使用InnoDB引擎的数据库系统而言，此参数值也不能设置过于偏小，因为临时表可能会使用到此键缓存区空间，索 引缓存区推荐：64M；
l query_cache_type and query_cache_size
n query_cache_type=N
N=0 —- 禁用查询缓存的功能；
N=1 —- 启用产讯缓存的功能，缓存所有符合要求的查询结果集，除SELECT SQL_NO_CACHE..， 以及不符合查询缓存设置的结果集外；
N=2 —- 仅仅缓存SELECT SQL_CACHE …子句的查询结果集，除不符合查询缓存设置的结果集外；
n query_cache_size
查询缓存设置多大才是合理？至少需要从四个维度考虑：
① 查询缓存区对DDL和DML语句的性能影响；
② 查询缓存区的内部维护成本；
③ 查询缓存区的命中率及内存使用率等综合考虑
④ 业务类型
文章出处：http://www.mysqlops.com/2011/10/26/mysql-variable-third.html
(责任编辑：IT)
| MySQL手册上也有服务器端参数的解释，以及参数值的相关说明信息，现针对我们大家重点需要注意、需要修改或影响性能的服务器端参数，作其用处的 解释和如何配置参数值的推荐，此事情拖了不少时间，为方便大家帮忙纠错（注：总是断断续续写的，可能存在笔误），先以文章的方式发布到网站，后续确定没问 题，将会通过新浪微博的微盘提供PPT下载，方便学习和参考。 l innodb_flush_log_at_trx_commit AND sync_binlog innodb_flush_log_at_trx_commit = N： N=0 – 每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上； N=1 – 每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上； N=2 – 每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件，但不一定刷新到磁盘上，而是取决于操作系统的调度； sync_binlog = N： N>0 — 每向二进制日志文件写入N条SQL或N个事务后，则把二进制日志文件的数据刷新到磁盘上； N=0 — 不主动刷新二进制日志文件的数据到磁盘上，而是由操作系统决定； 推荐配置组合： N=1,1 — 适合数据安全性要求非常高，而且磁盘IO写能力足够支持业务，比如充值消费系统； N=1,0 — 适合数据安全性要求高，磁盘IO写能力支持业务不富余，允许备库落后或无复制； N=2,0或2,m(0<m<100) — 适合数据安全性有要求，允许丢失一点事务日志，复制架构的延迟也能接受； N=0,0 — 磁盘IO写能力有限，无复制或允许复制延迟稍微长点能接受，例如：日志性登记业务； l innodb_file_per_table 启用单表空间，减少共享表空间维护成本，减少空闲磁盘空间释放的压力。另外，大数据量情况下 的性能，也会有性能上的提升，为此建议大家使用独立表空间 代替 共享表空间的方式； l key_buffer_size key_buffer_size只能缓存MyISAM或类MyISAM引擎的索引数据，而innodb_buffer_pool_size不仅能缓存索 引数据，还能缓存元数据，但是对于我们只使用InnoDB引擎的数据库系统而言，此参数值也不能设置过于偏小，因为临时表可能会使用到此键缓存区空间，索 引缓存区推荐：64M； l query_cache_type and query_cache_size n query_cache_type=N N=0 —- 禁用查询缓存的功能； N=1 —- 启用产讯缓存的功能，缓存所有符合要求的查询结果集，除SELECT SQL_NO_CACHE..， 以及不符合查询缓存设置的结果集外； N=2 —- 仅仅缓存SELECT SQL_CACHE …子句的查询结果集，除不符合查询缓存设置的结果集外； n query_cache_size 查询缓存设置多大才是合理？至少需要从四个维度考虑： ① 查询缓存区对DDL和DML语句的性能影响； ② 查询缓存区的内部维护成本； ③ 查询缓存区的命中率及内存使用率等综合考虑 ④ 业务类型
(责任编辑：IT) |