MySQL优化全攻略-相关数据库命令

接下来我们要讨论的是数据库性能优化的另一方面,即运用数据库服务器内建的工具辅助性能分析和优化。  
   ▲ SHOW  
   执行下面这个命令可以了解服务器的运行状态:  
mysql >show status; 
   该命令将显示出一长列状态变量及其对应的值,其中包括:被中止访问的用户数量,被中止的连接数量,尝试连接的次数,并发连接数量最大值,以及其他许多有用的信息。这些信息对于确定系统问题和效率低下的原因是十分有用的。  
   SHOW命令除了能够显示出MySQL服务器整体状态信息之外,它还能够显示出有关日志文件、指定数据库、表、索引、进程和许可权限表的宝贵信息。请访问http://www.mysql.com/doc/S/H/SHOW.html了解更多信息。  
   ▲ EXPLAIN  
   EXPLAIN能够分析SELECT命令的处理过程。这不仅对于决定是否要为表加上索引很有用,而且对于了解MySQL处理复杂连接的过程也很有用。  
   下面这个例子显示了如何用EXPLAIN提供的信息逐步地优化连接查询。(本例来自MySQL文档,见http://www.mysql.com/doc/E/X/EXPLAIN.html。原文写到这里似乎有点潦草了事,特加上此例。)  
   假定用EXPLAIN分析的SELECT命令如下所示:  
EXPLAIN SELECT tt.TicketNumber, tt.TimeIn, 
      tt.ProjectReference, tt.EstimatedShipDate, 
      tt.ActualShipDate, tt.ClientID, 
      tt.ServiceCodes, tt.RepetitiveID, 
      tt.CurrentProcess, tt.CurrentDPPerson, 
      tt.RecordVolume, tt.DPPrinted, et.COUNTRY, 
      et_1.COUNTRY, do.CUSTNAME 
    FROM tt, et, et AS et_1, do 
    WHERE tt.SubmitTime IS NULL 
      AND tt.ActualPC = et.EMPLOYID 
      AND tt.AssignedPC = et_1.EMPLOYID 
      AND tt.ClientID = do.CUSTNMBR;

   SELECT命令中出现的表定义如下:  
   ※表定义  
表 列 列类型  
tt ActualPC CHAR(10)  
tt AssignedPC CHAR(10)  
tt ClientID CHAR(10)  
et EMPLOYID CHAR(15)  
do CUSTNMBR CHAR(15)

  ※索引  
表 索引  
tt ActualPC  
tt AssignedPC  
tt ClientID  
et EMPLOYID (主键)  
do CUSTNMBR (主键)  
   ※tt.ActualPC值分布不均匀  
   在进行任何优化之前,EXPLAIN对SELECT执行分析的结果如下:  
table type possible_keys        key key_len ref rows Extra 
et  ALL PRIMARY           NULL NULL  NULL 74 
do  ALL PRIMARY           NULL NULL  NULL 2135 
et_1 ALL PRIMARY           NULL NULL  NULL 74 
tt  ALL AssignedPC,ClientID,ActualPC NULL NULL  NULL 3872 
   range checked for each record (key map: 35)

   每一个表的type都是ALL,它表明MySQL为每一个表进行了完全连接!这个操作是相当耗时的,因为待处理行的数量达到每一个表行数的乘积!即,这里的总处理行数为74 * 2135 * 74 * 3872 = 45,268,558,720。  
   这里的问题之一在于,如果数据库列的声明不同,MySQL(还)不能有效地运用列的索引。在这个问题上,VARCHAR和CHAR是一样的,除非它们声明的长度不同。由于tt.ActualPC声明为CHAR(10),而et.EMPLOYID声明为CHAR(15),因此这里存在列长度不匹配问题。  
   为了解决这两个列的长度不匹配问题,用ALTER TABLE命令把ActualPC列从10个字符扩展到15字符,如下所示:  
mysql > ALTER TABLE tt MODIFY ActualPC VARCHAR(15);

   现在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了,执行EXPLAIN进行分析得到的结果如下所示:  
table type  possible_keys  key   key_len ref     rows  Extra 
tt  ALL  AssignedPC,ClientID,ActualPC NULL NULL NULL 3872  where used 
do  ALL  PRIMARY     NULL  NULL  NULL    2135 
   range checked for each record (key map: 1) 
et_1 ALL  PRIMARY     NULL  NULL  NULL    74 
   range checked for each record (key map: 1) 
et  eq_ref PRIMARY     PRIMARY 15   tt.ActualPC 1

   这还算不上完美,但已经好多了(行数的乘积现在少了一个系数74)。现在这个SQL命令执行大概需要数秒钟时间。  
   为了避免tt.AssignedPC = et_1.EMPLOYID以及tt.ClientID = do.CUSTNMBR比较中的列长度不匹配,我们可以进行如下改动:  
mysql > ALTER TABLE tt MODIFY AssignedPC VARCHAR(15), 
           MODIFY ClientID  VARCHAR(15);

   现在EXPLAIN显示的结果如下:  
table type  possible_keys  key   key_len ref      rows   Extra 
et  ALL  PRIMARY     NULL  NULL  NULL      74 
tt  ref  AssignedPC,ClientID,ActualPC ActualPC 15 et.EMPLOYID 52 where used 
et_1 eq_ref PRIMARY     PRIMARY 15   tt.AssignedPC 1 
do  eq_ref PRIMARY     PRIMARY 15   tt.ClientID  1

   这个结果已经比较令人满意了。 
   余下的问题在于,默认情况下,MySQL假定tt.ActualPC列的值均匀分布,而事实上tt表的情况并非如此。幸而,我们可以很容易地让MySQL知道这一点:  
shell > myisamchk --analyze PATH_TO_MYSQL_DATABASE/tt 
shell > mysqladmin refresh

   现在这个连接操作已经非常理想,EXPLAIN分析的结果如下:  
table type  possible_keys  key   key_len ref      rows  Extra 
tt  ALL  AssignedPC,ClientID,ActualPC NULL NULL NULL  3872  where used 
et  eq_ref PRIMARY     PRIMARY 15   tt.ActualPC  1 
et_1 eq_ref PRIMARY     PRIMARY 15   tt.AssignedPC 1 
do  eq_ref PRIMARY     PRIMARY 15   tt.ClientID  1

   ▲ OPTIMIZE  
   OPTIMIZE能够恢复和整理磁盘空间以及数据碎片,一旦对包含变长行的表进行了大量的更新或者删除,进行这个操作就非常有必要了。OPTIMIZE当前只能用于MyISAM和BDB表。  
   结束语:从编译数据库服务器开始、贯穿整个管理过程,能够改善MySQL性能的因素实在非常多,本文只涉及了其中很小的一部分。尽管如此,我们希望本文讨论的内容能够对你有所帮助。  
//copy者注: 
  时间不够,所以格式上有点问题~~,请大家看详细的英文原文:http://www.devshed.com/Server_Side/MySQL/Optimize/ 
或者看看chinabyte的文章好了: 
http://www.chinabyte.com/builder/detail.shtm?buiid=1012&parid=1 
哈哈~从这点能不能看出来我是全心全意为大家服务的

(0)

相关推荐

  • my.ini优化mysql数据库性能的十个参数(推荐)

    今天刚好需要配置mysql 5.5.45,因为数据库量挺大的,所以必须优化,要不mysql真的不快. (1).max_connections: 允许的同时客户的数量.增加该值增加 mysqld 要求的文件描述符的数量.这个数字应该增加,否则,你将经常看到 too many connections 错误. 默认数值是100,我把它改为1024 . (2).record_buffer: 每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区.如果你做很多顺序扫描,你可能想要增加该值.默认

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

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

  • 计算机二级考试MySQL常考点 8种MySQL数据库设计优化方法

    MySQL数据库设计的8种优化方法,具体内容如下 1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快.因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小.例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了.同样的,如果可以的话,我们应该使用MEDIUMINT而不是B

  • mysql中优化和修复数据库工具mysqlcheck详细介绍

    一.mysqlcheck简介 mysqlcheck客户端可以检查和修复MyISAM表.它还可以优化和分析表. mysqlcheck的功能类似myisamchk,但其工作不同.主要差别是当mysqld服务器在运行时必须使用mysqlcheck,而myisamchk应用于服务器没有运行时.使用mysqlcheck的好处是不需要停止服务器来检查或修复表.使用myisamchk修复失败是不可逆的. Mysqlcheck为用户提供了一种方便的使用SQL语句CHECK TABLE.REPAIR TABLE.

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

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

  • mysql数据库查询优化 mysql效率第1/3页

    提高MySQL 查询效率的三个技巧小结MySQL由于它本身的小巧和操作的高效, 在数据库应用中越来越多的被采用.我在开发一个P2P应用的时候曾经使用MySQL来保存P2P节点,由于P2P的应用中,结点数动辄上万个,而且节点变化频繁,因此一定要保持查询和插入的高效.以下是我在使用过程中做的提高效率的三个有效的尝试. l        使用statement进行绑定查询 使用statement可以提前构建查询语法树,在查询时不再需要构建语法树就直接查询.因此可以很好的提高查询的效率. 这个方法适合于

  • mysql 数据库中my.ini的优化 2G内存针对站多 抗压型的设置

    物理内存越大,设置就越大.默认为2402,调到512-1024最佳 innodb_additional_mem_pool_size=4M 默认为2M innodb_flush_log_at_trx_commit=1 (设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1) innodb_log_buffer_size=2M 默认为1M innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,建议用默认一般为8 key_buff

  • 优化Mysql数据库的8个方法

    1.创建索引对于查询占主要的应用来说,索引显得尤为重要.很多时候性能问题很简单的就是因为我们忘了添加索引而造成的,或者说没有添加更为有效的索引导致.如果不加索引的话,那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描,如果一张表的数据量很大而符合条件的结果又很少,那么不加索引会引起致命的性能下降.但是也不是什么情况都非得建索引不可,比如性别可能就只有两个值,建索引不仅没什么优势,还会影响到更新速度,这被称为过度索引.2.复合索引比如有一条语句是这样的:select * from users

  • 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 联合索引与Where子句的优化 提高数据库运行效率

    网站系统上线至今,数据量已经不知不觉上到500M,近8W记录了.涉及数据库操作的基本都是变得很慢了,用的人都会觉得躁火~~然后把这个情况在群里一贴,包括机器配置什么的一说,马上就有群友发话了,而且帮我确定了不是机器配置的问题,"深圳-枪手"热心人他的机器512内存过百W的数据里也跑得飞快,甚至跟那些几W块的机器一样牛(吹过头了),呵呵~~~ 在群友的分析指点下,尝试把排序.条件等一个一个去除来做测试,结果发现问题就出在排序部分,去除排序的时候,执行时间由原来的48秒变成0.3x秒,这是

随机推荐