当中ref是最理想的; 3)possible_keys:查询能够利用的索引名。 4)key:实际使用的索引。 5)key_len:索引中被使用部分的长度(字节)。 6)ref:显示列名字或者"const"(不明确什么意思); 7)rows:显示MySQL觉得在找到正确结果之前必须扫描的行数; 8)extra:MySQL的建议; 17、使用较短的定长列 1)尽可能使用较短的数据类型; 2)尽可能使用定长数据类型; a)用char取代varchar。固定长度的数据处理比变长的快些; b)对于频繁改动的表,磁盘easy形成碎片,从而影响数据库的总体性能; c)万一出现数据表崩溃,使用固定长度数据行的表更easy又一次构造。使用固定长度的数据行。每一个记录的開始位置都是固定记录长度的倍数。能够非常easy被检測到,可是使用可变长度的数据行就不一定了。 d)对于MyISAM类型的数据表,尽管转换成固定长度的数据列能够提高性能。可是占领的空间也大; 18、使用not null和enum 尽量将列定义为not null,这样可使数据的出来更快。所需的空间更少,并且在查询时,MySQL不须要检查是否存在特例,即null值,从而优化查询; 假设一列仅仅含有有限数目的特定值,如性别,是否有效或者入学年份等,在这样的情况下应该考虑将其转换为enum列的值,MySQL处理的更快,由于全部的enum值在系统内都是以标识数值来表示的; 19、使用optimize table 对于常常改动的表,easy产生碎片。使在查询数据库时必须读取很多其它的磁盘块。减少查询性能。
具有可变长的表都存在磁盘碎片问题。这个问题对 blob数据类型更为突出,由于其尺寸变化很大。能够通过使用optimize table来整理碎片,保证数据库性能不下降,优化那些受碎片影响的数据表。 optimize table能够用于MyISAM和BDB类型的数据表。实际上不论什么碎片整理方法都是用mysqldump来转存数据表,然后使用转存后的文件并又一次建数据 表; 20、使用procedure analyse() 能够使用procedure analyse()显示最佳类型的建议,使用非常easy,在select语句后面加上procedure analyse()就能够了。比如: select * from students procedure analyse(); select * from students procedure analyse(16,256); 第二条语句要求procedure analyse()不要建议含有多于16个值,或者含有多于256字节的enum类型,假设没有限制,输出可能会非常长; 21、使用查询缓存 1)查询缓存的工作方式: 第一次运行某条select语句时。server记住该查询的文本内容和查询结果,存储在缓存中。下次碰到这个语句时,直接从缓存中返回结果;当更新数据表后,该数据表的不论什么缓存查询都变成无效的,而且会被丢弃。 2)配置缓存參数: 变量:query_cache _type,查询缓存的操作模式。
有3中模式。0:不缓存。1:缓存查询。除非与 select sql_no_cache开头;2:依据须要仅仅缓存那些以select sql_cache开头的查询。 query_cache_size:设置查询缓存的最大结果集的大小,比这个值大的不会被缓存。 22、调整硬件 1)在机器上装很多其它的内存; 2)添加更快的硬盘以降低I/O等待时间; 寻道时间是决定性能的主要因素。逐字地移动磁头是最慢的。一旦磁头定位。从磁道读则非常快; 3)在不同的物理硬盘设备上又一次分配磁盘活动。 假设可能。应将最繁忙的数据库存放在不同的物理设备上。这跟使用同一物理设备的不同分区是不同的,由于它们将争用同样的物理资源(磁头)。
来源: http://www.bubuko.com/infodetail-2129193.html