MySQL数据库优化经验详谈(服务器普通配置)第1/3页

安装好mysql后,配制文件应该在/usr/local/mysql/share/mysql目录中,配制文件有几个,有my- huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境,当然需要有不同的配制文件了。

一般的情况下,my-medium.cnf这个配制文件就能满足我们的大多需要;一般我们会把配置文件拷贝到/etc/my.cnf 只需要修改这个配置文件就可以了,使用mysqladmin variables extended-status –u root –p 可以看到目前的参数,有3个配置参数是最重要的,即:





key_buffer_size
query_cache_size
table_cache

key_buffer_size只对MyISAM表起作用。

key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。一般我们设为16M,实际上稍微大一点的站点 这个数字是远远不够的,通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%'获得)。 或者如果你装了phpmyadmin 可以通过服务器运行状态看到,笔者推荐用phpmyadmin管理mysql,以下的状态值都是本人通过phpmyadmin获得的实例分析:

这个服务器已经运行了20天





key_buffer_size – 128M
key_read_requests – 650759289
key_reads - 79112

比例接近1:8000 健康状况非常好

另外一个估计key_buffer_size的办法:把你网站数据库的每个表的索引所占空间大小加起来看看以此服务器为例:比较大的几个表索引加起来大概125M 这个数字会随着表变大而变大。

从4.0.1开始,MySQL提供了查询缓冲机制。使用查询缓冲,MySQL将SELECT语句和查询结果存放在缓冲区中,今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。根据MySQL用户手册,使用查询缓冲最多可以达到238%的效率。

通过调节以下几个参数可以知道query_cache_size设置得是否合理





Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocks

Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况,同时Qcache_hits的值非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小Qcache_hits的值不大,则表明你的查询重复率很低,这种情况下使用查询缓冲反而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多query_cache_type指定是否使用查询缓冲

我设置:





query_cache_size = 32M
query_cache_type= 1

得到如下状态值:





Qcache queries in cache 12737 表明目前缓存的条数
Qcache inserts 20649006
Qcache hits 79060095  看来重复查询率还挺高的
Qcache lowmem prunes 617913 有这么多次出现缓存过低的情况
Qcache not cached 189896   
Qcache free memory 18573912  目前剩余缓存空间
Qcache free blocks 5328 这个数字似乎有点大 碎片不少
Qcache total blocks 30953

如果内存允许32M应该要往上加点

table_cache指定表高速缓存的大小。每当MySQL访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables,可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache,并且opened_tables在不断增长,那么你就需要增加table_cache的值了(上述状态值可以使用SHOW STATUS LIKE ‘Open%tables'获得)。注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败。

对于有1G内存的机器,推荐值是128-256。

笔者设置table_cache = 256

得到以下状态:





Open tables 256
Opened tables 9046

虽然open_tables已经等于table_cache,但是相对于服务器运行时间来说,已经运行了20天,opened_tables的值也非常低。因此,增加table_cache的值应该用处不大。如果运行了6个小时就出现上述值 那就要考虑增大table_cache。

当前1/3页 123下一页阅读全文

(0)

相关推荐

  • mysql数据库优化必会的几个参数中文解释

    第一步: 1:磁盘寻道能力,以高速硬盘(7200转/秒),理论上每秒寻道7200次.这是没有办法改变的,优化的方法是----用多个硬盘,或者把数据分散存储. 2:硬盘的读写速度,这个速度非常的快,这个更容易解决--可以从多个硬盘上并行读写. 3:cpu.cpu处理内存中的数据,当有相对内存较小的表时,这是最常见的限制因素. 4:内存的限制.当cpu需要超出适合cpu缓存的数据时,缓存的带宽就成了内存的一个瓶颈---不过现在内存大的惊人,一般不会出现这个问题. 第二步: (本人使用的是学校网站的l

  • mysql数据库常见的优化操作总结(经验分享)

    前言 对于一个以数据为中心的应用,数据库的好坏直接影响到程序的性能,因此数据库性能至关重要.所以mysql数据库的优化操作大家都要有所了解,本文就主要总结了mysql数据库中常见的优化操作,下面话不多说了,来看看详细的介绍吧. 一.Index索引 将Index放第一位,不用说,这种优化方式我们一直都在悄悄使用,那便是主键索引.有时候我们可能并不在意,如果定义适合的索引,数据库查询性能(速度)将提高几倍甚至几十倍. 普通索引 作用是提高查询速度. 建表,创建索引 CREATE TABLE tbl_

  • MySQL数据库优化技术之配置技巧总结

    本文实例讲述了MySQL数据库优化技术的配置方法.分享给大家供大家参考,具体如下: (一)减少数据库访问 对于可以静态化的页面,尽可能静态化 对一个动态页面中可以静态的局部,采用静态化 部分数据可以生成XML,或者文本文件形式保存 使用数据缓存技术,例如: MemCached (二)优化的检测方法 1.用户体验检测 2.Mysql状态检测 在Mysql命令行里面使用show status命令,得到当前mysql状态. 主要关注下列属性: key_read_requests (索引读的请求数)(k

  • MySQL数据库优化推荐的编译安装参数小结

    MySQL编译参数多而复杂,让新手感到很头大,如果是正式生成环境安装MySQL,没有充足的时间去研究每一个参数代表的意义,个人建议使用余洪春前辈整理的编译参数,便捷高效! MySQL的线上安装建议采取编译安装的方法,这样性能上有较大提升,,源码包的编译参数会默认以Debgu模式生成二进制代码,而Debug模式给MySQL带来的性能损失是比较大的,所以当我们编译准备安装的产品代码时,一定不要忘记使用"-without-debug"参数禁用Debug模式. 而如果把-with-mysqld

  • mysql数据库优化总结(心得)

     1. 优化你的MySQL查询缓存在MySQL服务器上进行查询,可以启用高速查询缓存.让数据库引擎在后台悄悄的处理是提高性能的最有效方法之一.当同一个查询被执行多次时,如果结果是从缓存中提取,那是相当快的.但主要的问题是,它是那么容易被隐藏起来以至于我们大多数程序员会忽略它.在有些处理任务中,我们实际上是可以阻止查询缓存工作的. 复制代码 代码如下: // query cache does NOT work$r = mysql_query("SELECT username FROM user W

  • MySQL数据库优化详解

    mysql表复制 复制表结构+复制表数据 mysql> create table t3 like t1; mysql> insert into t3 select * from t1; mysql索引 ALTER TABLE用来创建普通索引.UNIQUE索引或PRIMARY KEY索引 ALTER TABLE table_name ADD INDEX index_name (column_list) ALTER TABLE table_name ADD UNIQUE (column_list)

  • 运维角度浅谈MySQL数据库优化(李振良)

    一个成熟的数据库架构并不是一开始设计就具备高可用.高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善.这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 1.数据库表设计 项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验.影响的因素很多,比如慢查询.低效的查询语句.没有适当建立索引.数据库堵塞(死锁)等.当然,有测试工程师的团队

  • MySQL 数据库优化的具体方法说明

    以下的文章主要描述的是MySQL数据库简单实用优化的具体方法的实现,中包括如何定期的表进行分析与检查, 以及如何正确对表进行定期的优化,以下就是具体方案的描述,希望在你今后的学习中会有所帮助. 1.定期分析表和检查表 分析表的语法如下: 复制代码 代码如下: ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tb1_name[, tbl_name]... 以上语句用于分析和存储表的关键字分布,分析的结果将可以使得系统得到准确的统计信息,使得SQL能够生成正确的

  • mysql数据库优化需要遵守的原则

    这是我在网上看到的一篇不错的mysql数据库优化文章,内容说的很全! 1.使用索引来更快地遍历表 缺省情况下建立的索引是非群集索引,但有时它并不是最佳的.在非群集索引下,数据在物理上随机存放在数据页上.合理的索引设计要建立在对各种查询的分析和预测上.一般来说: a.有大量重复值.且经常有范围查询( > ,< ,> =,< =)和order by.group by发生的列,可考虑建立群集索引; b.经常同时存取多列,且每列都含有重复值可考虑建立组合索引; c.组合索引要尽量使关键查询

  • mysql 单机数据库优化的一些实践

    数据库优化有很多可以讲,按照支撑的数据量来分可以分为两个阶段:单机数据库和分库分表,前者一般可以支撑500W或者10G以内的数据,超过这个值则需要考虑分库分表.另外,一般大企业面试往往会从单机数据库问起,一步一步问到分库分表,中间会穿插很多数据库优化的问题.本文试图描述单机数据库优化的一些实践,数据库基于mysql,如有不合理的地方,欢迎指正. 1.表结构优化 在开始做一个应用的时候,数据库的表结构设计往往会影响应用后期的性能,特别是用户量上来了以后的性能.因此,表结构优化是一个很重要的步骤.

随机推荐