mysql优化总结

Mysql语句优化

1. 在查询语句前面加入EXPLAIN关键可查看SQL运行情况。
2. 在已知要查询多少行的时候，用LIMIT限制行数，会使得当你查得到的行数与限制行数相符时结束查询。
3. 保证连接的索引是相同的类型。
4. 强制使用某索引FORCE INDEX （）。
   select * from t_screen_mobile force index(screen_mobile_create_time) where create_time>='2011-6-1'
5. EXPLAIN 数据解释
   1. Select_type类型解释
      1. primary: 最外层的 select。
      2. union: 第二层，在select 之后使用了 union。
      3. dependent union: union 语句中的第二个select，依赖于外部子查询
      4. subquery: 子查询中的第一个 select
      5. dependent subquery: 子查询中的第一个 subquery依赖于外部的子查询
      6. derived: 派生表 select（from子句中的子查询）
   2. 查询类型,由快到慢
      1. system:表只有一行记录（等于系统表）。这是 const表连接类型的一个特例。const:表中最多只有一行匹配的记录，它在查询一开始的时候就会被读取出来。由于只有一行记录，在余下的优化程序里该行记录的字段值可以被当作是一个恒定值。const表查询起来非常快，因为只要读取一次！const 用于在和 primary key 或unique 索引中有固定值比较的情形。下面的几个查询中，tbl_name 就是 c表了：
         select * from tbl_name where primary_key=1; select * from tbl_namewhere primary_key_part1=1 and primary_key_part2=2;
      2.  eq_ref:从该表中会有一行记录被读取出来以和从前一个表中读取出来的记录做联合。与const类型不同的是，这是最好的连接类型。它用在索引所有部分都用于做连接并且这个索引是一个primary key 或 unique 类型。eq_ref可以用于在进行"="做比较时检索字段。比较的值可以是固定值或者是表达式，表达示中可以使用表里的字段，它们在读表之前已经准备好了。以下的几个例子中，mysql使用了eq_ref 连接来处理 ref_table：
         select * from ref_table,other_table where ref_table.key_column=other_table.column;
         select * fromref_table,other_table where ref_table.key_column_part1=other_table.column and ref_table.key_column_part2=1;
      3.  ref: 该表中所有符合检索值的记录都会被取出来和从上一个表中取出来的记录作联合。ref用于连接程序使用键的最左前缀或者是该键不是 primary key 或 unique索引（换句话说，就是连接程序无法根据键值只取得一条记录）的情况。当根据键值只查询到少数几条匹配的记录时，这就是一个不错的连接类型。 ref还可以用于检索字段使用 =操作符来比较的时候。以下的几个例子中，mysql将使用 ref 来处理ref_table：
         select * from ref_table where key_column=expr;
         select * fromref_table,other_table where ref_table.key_column=other_table.column;
         select * fromref_table,other_table where ref_table.key_column_part1=other_table.column andref_table.key_column_part2=1;
      4.  ref_or_null: 这种连接类型类似 ref，不同的是mysql会在检索的时候额外的搜索包含null 值的记录。这种连接类型的优化是从mysql4.1.1开始的，它经常用于子查询。在以下的例子中，mysql使用ref_or_null 类型来处理 ref_table：
         select * from ref_table where key_column=expr or key_column is null;
      5.  unique_subquery: 这种类型用例如一下形式的 in 子查询来替换 ref：
         value in (select primary_key from single_table where some_expr)。
      6. unique_subquery: 只是用来完全替换子查询的索引查找函数效率更高了。
      7. index_subquery: 这种连接类型类似 unique_subquery。它用子查询来代替in，不过它用于在子查询中没有唯一索引的情况下，例如以下形式： value in (select key_column from single_table where some_expr)。
      8. range: 只有在给定范围的记录才会被取出来，利用索引来取得一条记录。key字段表示使用了哪个索引。key_len字段包括了使用的键的最长部分。这种类型时 ref 字段值是 null。range用于将某个字段和一个定植用以下任何操作符比较时 =, <>, >,>=, <, <=, is null, <=>, between, 或 in：
         select * from tbl_name where key_column = 10;
         select * fromtbl_name where key_column between 10 and 20;
          select * from tbl_namewhere key_column in (10,20,30);
         select * from tbl_name wherekey_part1= 10 and key_part2 in (10,20,30);
      9.  index: 连接类型跟 all 一样，不同的是它只扫描索引树。它通常会比 all快点，因为索引文件通常比数据文件小。mysql在查询的字段知识单独的索引的一部分的情况下使用这种连接类型。
      10. all: 将对该表做全部扫描以和从前一个表中取得的记录作联合。这时候如果第一个表没有被标识为const的话就不大好了，在其他情况下通常是非常糟糕的。正常地，可以通过增加索引使得能从表中更快的取得记录以避免all。
   3. possible_keys字段
      possible_keys字段是指 mysql在搜索表记录时可能使用哪个索引。注意，这个字段完全独立于explain 显示的表顺序。这就意味着 possible_keys里面所包含的索引可能在实际的使用中没用到。如果这个字段的值是null，就表示没有索引被用到。这种情况下，就可以检查 where子句中哪些字段那些字段适合增加索引以提高查询的性能。就这样，创建一下索引，然后再用explain 检查一下。详细的查看章节"14.2.2 alter tablesyntax"。想看表都有什么索引，可以通过 show index from tbl_name来看。
   4. key字段显示了mysql实际上要用的索引。当没有任何索引被用到的时候，这个字段的值就是null。想要让mysql强行使用或者忽略在 possible_keys字段中的索引列表，可以在查询语句中使用关键字force index, use index,或 ignore index。如果是 myisam 和 bdb 类型表，可以使用 analyzetable 来帮助分析使用使用哪个索引更好。如果是 myisam类型表，运行命令 myisamchk --analyze也是一样的效果。详细的可以查看章节"14.5.2.1 analyze tablesyntax"和"5.7.2 table maintenance and crash recovery"。
   5. key_len 字段显示了mysql使用索引的长度。当 key 字段的值为 null时，索引的长度就是 null。注意，key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。
   6. ref 字段显示了哪些字段或者常量被用来和 key配合从表中查询记录出来。
   7. rows 字段显示了mysql认为在查询中应该检索的记录数。
   8. extra本字段显示了查询中mysql的附加信息。以下是这个字段的几个不同值的解释：
      1.  distinct:mysql当找到当前记录的匹配联合结果的第一条记录之后，就不再搜索其他记录了。
      2. not exists:mysql在查询时做一个 left join优化时，当它在当前表中找到了和前一条记录符合 left join条件后，就不再搜索更多的记录了。下面是一个这种类型的查询例子：
         select * from t1 left join t2 on t1.id=t2.id where t2.id isnull;假使 t2.id 定义为 not null。这种情况下，mysql将会扫描表 t1并且用 t1.id 的值在 t2 中查找记录。当在 t2中找到一条匹配的记录时，这就意味着 t2.id 肯定不会都是null，就不会再在 t2 中查找相同 id值的其他记录了。也可以这么说，对于 t1 中的每个记录，mysql只需要在t2 中做一次查找，而不管在 t2 中实际有多少匹配的记录。
         range checked for each record (index map: #)
         mysql没找到合适的可用的索引。取代的办法是，对于前一个表的每一个行连接，它会做一个检验以决定该使用哪个索引（如果有的话），并且使用这个索引来从表里取得记录。这个过程不会很快，但总比没有任何索引时做表连接来得快。
      3. using filesort: mysql需要额外的做一遍从而以排好的顺序取得记录。排序程序根据连接的类型遍历所有的记录，并且将所有符合 where条件的记录的要排序的键和指向记录的指针存储起来。这些键已经排完序了，对应的记录也会按照排好的顺序取出来。详情请看"7.2.9how mysql optimizes order by"。
         using index字段的信息直接从索引树中的信息取得，而不再去扫描实际的记录。这种策略用于查询时的字段是一个独立索引的一部分。
      4.  using temporary: mysql需要创建临时表存储结果以完成查询。这种情况通常发生在查询时包含了groupby 和 order by 子句，它以不同的方式列出了各个字段。
      5. using where
         where子句将用来限制哪些记录匹配了下一个表或者发送给客户端。除非你特别地想要取得或者检查表种的所有记录，否则的话当查询的extra 字段值不是 using where 并且表连接类型是 all 或 index时可能表示有问题。
6. 查询语句优化
   1. 使用索引来更快地遍历表。
      　　缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
      1. 有大量重复值、且经常有范围查询（ > ,< ，> =,< =）和order by、group by发生的列，可考虑建立群集索引；
      2. 经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
      3. 组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索引会导致系统低效。用户在表中每加进一个索引，维护索引集合就要做相应的更新工作。
   2. 在海量查询时尽量少用格式转换。
   3. ORDER BY和GROPU BY使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。
   4. 任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
   5. IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
   6. 只要能满足你的需求，应尽可能使用更小的数据类型：例如使用MEDIUMINT代替INT
   7. 尽量把所有的列设置为NOT NULL，如果你要保存NULL，手动去设置它，而不是把它设为默认值。
   8. 尽量少用VARCHAR、TEXT、BLOB类型
   9. 如果你的数据只有你所知的少量的几个。最好使用ENUM类型
   10. 不要以数字格式声名字符，不要以字符格式声名数字，否则，索引无效
   11. 正如graymice所讲的那样，建立索引。
       　　以下是我做的一个实验，可以发现索引能极大地提高查询的效率：
       我有一个会员信息表users，里边有37365条用户记录：
       在不加索引的时候进行查询：
       sql语句A:
       select * from users where username like '%许%';
       在Mysql-Front中的8次查询时长为：1.40,0.54,0.54,0.54,0.53,0.55,0.54 共找到960条记录
       sql语句B:
       select * from users where username like '许%';
       在Mysql-Front中的8次查询时长为：0.53,0.53,0.53,0.54,0.53,0.53,0.54,0.54 共找到836条记录
       sql语句C:
       select * from users where username like '%许';
       在Mysql-Front中的8次查询时长为：0.51,0.51,0.52,0.52,0.51,0.51,0.52,0.51 共找到7条记录
       为username列添加索引:
       create index usernameindex on users(username(6));
       再次查询：
       sql语句A:
       select * from users where username like '%许%';
       在Mysql-Front中的8次查询时长为：0.35,0.34,0.34,0.35,0.34,0.34,0.35,0.34 共找到960条记录
       sql语句B:
       select * from users where username like '许%';
       在Mysql-Front中的8次查询时长为：0.06,0.07,0.07,0.07,0.07,0.07,0.06,0.06 共找到836条记录
       sql语句C:
       select * from users where username like '%许';
       在Mysql-Front中的8次查询时长为：0.32,0.31,0.31,0.32,0.31,0.32,0.31,0.31 共找到7条记录
       
       　　在实验过程中，我没有另开任何程序，以上的数据说明在单表查询中，建立索引的可以极大地提高查询速度。
       
       　　另外要说的是如果建立了索引，对于like '许%'类型的查询，速度提升是最明显的。因此，我们在写sql语句的时候也尽量采用这种方式查询。
       
       　　对于多表查询我们的优化原则是：
       　　尽量将索引建立在：left join on/right join on ...　＋条件，的条件语句中所涉及的字段上。
       
       　　多表查询比单表查询更能体现索引的优势。
7. 操作符优化
   1. IN 操作符

用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的，从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：

ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。

推荐方案：在业务密集的SQL当中尽量不采用IN操作符，用EXISTS 方案代替。

1. 1. NOT IN操作符 

此操作是强列不推荐使用的，因为它不能应用表的索引。

推荐方案：用NOT EXISTS 方案代替

1. 1. IS NULL 或IS NOT NULL操作（判断字段是否为空）

判断字段是否为空一般是不会应用索引的，因为索引是不索引空值的。

推荐方案：用其它相同功能的操作运算代替，如：a is not null 改为 a>0 或a>’’等。不允许字段为空，而用一个缺省值代替空值，如申请中状态字段不允许为空，缺省为申请。

1. 1. > 及 < 操作符（大于或小于操作符） 

大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。

1. 1. LIKE操作符 

LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE ‘%5400%’ 这种查询不会引用索引，而LIKE ‘X5400%’则会引用范围索引。

一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描，如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。

1. 1. UNION操作符 

UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如：
select * from gc_dfys
union
select * from ls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。

推荐方案：采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。

select * from gc_dfys
union all
select * from ls_jg_dfys

1. SQL书写的影响

同一功能同一性能不同写法SQL的影响。

如一个SQL在A程序员写的为  Select * from zl_yhjbqk

B程序员写的为 Select * from dlyx.zl_yhjbqk（带表所有者的前缀）

C程序员写的为 Select * from DLYX.ZLYHJBQK（大写表名）

D程序员写的为 Select *  from DLYX.ZLYHJBQK（中间多了空格）

以上四个SQL在ORACLE分析整理之后产生的结果及执行的时间是一样的，但是从ORACLE共享内存SGA的原理，可以得出ORACLE对每个SQL 都会对其进行一次分析，并且占用共享内存，如果将SQL的字符串及格式写得完全相同，则ORACLE只会分析一次，共享内存也只会留下一次的分析结果，这不仅可以减少分析SQL的时间，而且可以减少共享内存重复的信息，ORACLE也可以准确统计SQL的执行频率。

1. WHERE后面的条件顺序影响 

WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响。如：
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。

1. 查询表顺序的影响 

在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下，ORACLE会按表出现的顺序进行链接，由此可见表的顺序不对时会产生十分耗服物器资源的数据交叉。数据小的表放在后面 

1. SQL语句索引的利用
   1. 采用函数处理的字段不能利用索引，如：

substr(hbs_bh,1,4)=’5400’，优化处理：hbs_bh like ‘5400%’

trunc(sk_rq)=trunc(sysdate)， 优化处理：sk_rq>=trunc(sysdate) and sk_rq

进行了显式或隐式的运算的字段不能进行索引，如：ss_df+20>50，优化处理：ss_df>30

‘X’ || hbs_bh>’X5400021452’，优化处理：hbs_bh>’5400021542’

sk_rq+5=sysdate，优化处理：sk_rq=sysdate-5

hbs_bh=5401002554，优化处理：hbs_bh=’ 5401002554’，注：此条件对hbs_bh 进行隐式的to_number转换，因为hbs_bh字段是字符型。

1. 1. 条件内包括了多个本表的字段运算时不能进行索引，如：ys_df>cx_df，无法进行优化
      qc_bh || kh_bh=’5400250000’，优化处理：qc_bh=’5400’ and kh_bh=’250000’
2. 索引
   1. 索引的建立原则：
      　　如果一列的中数据的前缀重复值很少，我们最好就只索引这个前缀。Mysql支持这种索引。我在上面用到的索引方法就是对username最左边的6个字符进行索引。索引越短，占用的 磁盘空间越少，在检索过程中花的时间也越少。这方法可以对最多左255个字符进行索引。
      
      　　在很多场合，我们可以给建立多列数据建立索引。
      　　索引应该建立在查询条件中进行比较的字段上，而不是建立在我们要找出来并且显示的字段上
      　　一往情深问到的问题:IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
      
      这句话怎么理解决，请举个例子
      例子如下:
      如果在fields1和fields2上同时建立了索引，fields1为主索引
      以下sql会用到索引
      select * from tablename1 where fields1='value1' and fields2='value2'
      以下sql不会用到索引
      select * from tablename1 where fields1='value1' or fields2='value2'
      　　索引带来查询上的速度的大大提升,但索引也占用了额外的硬盘空间(当然现在一般硬盘空间不成问题),而且往表中插入新记录时索引也要随着更新这也需要一定时间.
      　　有些表如果经常insert,而较少select,就不用加索引了.不然每次写入数据都要重新改写索引,花费时间; 这个视实际情况而定,通常情况下索引是必需的.
      
      　　我在对查询效率有怀疑的时候,一般是直接用Mysql的Explain来跟踪查询情况.
      　　你用Mysql-Front是通过时长来比较,我觉得如果从查询时扫描字段的次数来比较更精确一些. 
      | Com_select　　　　 | 222693559 |
      +---------------+-----------+

计算表扫描率：

表扫描率 ＝ Handler_read_rnd_next / Com_select

如果表扫描率超过4000，说明进行了太多表扫描，很有可能索引没有建好，增加read_buffer_size值会有一些好处，但最好不要超过8MB。

 

select * from yanxue8_visit limit 10000,10       select * from yanxue8_visit limit 0,10    

　　就不是一个数量级别的。

　　网上也很多关于limit的五条优化准则，都是翻译自MySQL手册，虽然正确但不实用。今天发现一篇文章写了些关于limit优化的，很不错。

　　文中不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据。根据他的数据，明显要好于直接使用limit。这里我具体使用数据分两种情况进行测试。(测试环境win2033+p4双核 (3GHZ) +4G内存MySQLlimit查询)//河北折扣网

1、offset比较小的时候

 

1.select * from yanxue8_visit limit 10,10   

　　多次运行，时间保持在0.0004-0.0005之间

 

Select * From yanxue8_visit Where vid ＞=(      Select vid From yanxue8_visit Order By vid limit 10,1  ) limit 10   

　　多次运行，时间保持在0.0005-0.0006之间，主要是0.0006

　　结论：偏移offset较小的时候，直接使用MySQL limit较优。这个显然是子查询的原因。

2、offset大的时候

select * from yanxue8_visit limit 10000,10   

　　多次运行，时间保持在0.0187左右

Select * From yanxue8_visit Where vid ＞=(      Select vid From yanxue8_visit Order By vid limit 10000,1  ) limit 10    

　　多次运行，时间保持在0.0061左右，只有前者的1/3。可以预计offset越大，后者越优。

1. 1. 创建索引
      1. 普通索引
         这是最基本的索引，它没有任何限制。它有以下几种创建方式：
         创建索引

CREATE INDEX indexName ON mytable(username(length)); 

如果是CHAR，VARCHAR类型，length可以小于字段实际长度;如果是BLOB和TEXT类型，必须指定 length，下同。

1. 1. 1. MySQL索引类型：唯一索引
         它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：
         创建索引

CREATE UNIQUE INDEX indexName ON mytable(username(length)) 

1. 1. 1. 组合索引
         为了形象地对比单列索引和组合索引，为表添加多个字段：
          CREATE TABLE mytable( ID INT NOT NULL, username 
         VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL ); 
   2. 使用索引的注意事项

使用索引时，有以下一些技巧和注意事项：

1. 1. 1. 索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

1. 1. 1. 使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

1. 1. 1. 索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

1. 1. 1. like语句操作

一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

1. 1. 1. 不要在列上进行运算

select * from users where YEAR(adddate)<2007; 

将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成

select * from users where adddate<‘2007-01-01’;  

1. 1. 1. 不使用NOT IN和<>操作

 

Mysql数据库设置优化

 

1. 连接数

经常会遇见”MySQL: ERROR 1040: Too many connections”的情况，一种是访问量确实很高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力，另外一种情况是MySQL配置文件中max_connections值过小：

mysql> show variables like ‘max_connections‘;
+-----------------+-------+
| Variable_name　　　 | Value |
+-----------------+-------+
| max_connections | 256　　 |
+-----------------+-------+

这台MySQL服务器最大连接数是256，然后查询一下服务器响应的最大连接数：

mysql> show global status like ‘Max_used_connections‘;

MySQL服务器过去的最大连接数是245，没有达到服务器连接数上限256，应该没有出现1040错误，比较理想的设置是

Max_used_connections / max_connections * 100% ≈ 85%

最大连接数占上限连接数的85％左右，如果发现比例在10%以下，MySQL服务器连接数上限设置的过高了。

1. Key_buffer_size

key_buffer_size是对MyISAM表性能影响最大的一个参数，下面一台以MyISAM为主要存储引擎服务器的配置：

mysql> show variables like ‘key_buffer_size‘;+-----------------+------------+
| Variable_name　　　 | Value　　　　　　 |
+-----------------+------------+
| key_buffer_size | 536870912 |
+-----------------+------------+

分配了512MB内存给key_buffer_size，我们再看一下key_buffer_size的使用情况：

mysql> show global status like ‘key_read%‘;
+------------------------+-------------+
| Variable_name　　　　　　　　　　 | Value　　　　　　　 |
+------------------------+-------------+
| Key_read_requests　　　　　　 | 27813678764 |
| Key_reads　　　　　　　　　　　　　　 | 6798830　　　　　 |
+------------------------+-------------+

　　一共有27813678764个索引读取请求，有6798830个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率：

key_cache_miss_rate ＝ Key_reads / Key_read_requests * 100%

比如上面的数据，key_cache_miss_rate为0.0244%，4000个索引读取请求才有一个直接读硬盘，已经很BT了，key_cache_miss_rate在0.1%以下都很好（每1000个请求有一个直接读硬盘），如果key_cache_miss_rate在0.01%以下的话，key_buffer_size分配的过多，可以适当减少。

MySQL服务器还提供了key_blocks_*参数：

mysql> show global status like ‘key_blocks_u%‘;
+------------------------+-------------+
| Variable_name　　　　　　　　　　 | Value　　　　　　　 |
+------------------------+-------------+
| Key_blocks_unused　　　　　　 | 0　　　　　　　　　　　 |
| Key_blocks_used　　　　　　　　 | 413543　　　　　　 |
+------------------------+-------------+

Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

1. 临时表

mysql> show global status like ‘created_tmp%‘;
+-------------------------+---------+
| Variable_name　　　　　　　　　　　 | Value　　　 |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197　　　 |
| Created_tmp_files　　　　　　　 | 58　　　　　　 |
| Created_tmp_tables　　　　　　 | 1771587 |
+-------------------------+---------+

每次创建临时表，Created_tmp_tables增加，如果是在磁盘上创建临时表，Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数，比较理想的配置是：

Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝ 1.20%，应该相当好了。我们再看一下MySQL服务器对临时表的配置：

mysql> show variables where Variable_name in (‘tmp_table_size‘, ‘max_heap_table_size‘);
+---------------------+-----------+
| Variable_name　　　　　　　 | Value　　　　　 |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size　　　　　　 | 536870912 |
+---------------------+-----------+

只有256MB以下的临时表才能全部放内存，超过的就会用到硬盘临时表。

1. Open Table情况

mysql> show global status like ‘open%tables%‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables　　　 | 919　　　 |
| Opened_tables | 1951　 |
+---------------+-------+

Open_tables表示打开表的数量，Opened_tables表示打开过的表数量，如果Opened_tables数量过大，说明配置中table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小，我们查询一下服务器table_cache值：

mysql> show variables like ‘table_cache‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| table_cache　　　 | 2048　 |
+---------------+-------+

比较合适的值为：

Open_tables / Opened_tables * 100% >= 85%

Open_tables / table_cache * 100% <= 95%

1. 进程使用情况

mysql> show global status like ‘Thread%‘;
+-------------------+-------+
| Variable_name　　　　　 | Value |
+-------------------+-------+
| Threads_cached　　　　 | 46　　　　 |
| Threads_connected | 2　　　　　 |
| Threads_created　　　 | 570　　　 |
| Threads_running　　　 | 1　　　　　 |
+-------------------+-------+

如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁（前提是缓存数未达上限）。Threads_created表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，查询服务器thread_cache_size配置：

mysql> show variables like ‘thread_cache_size‘;
+-------------------+-------+
| Variable_name　　　　　 | Value |
+-------------------+-------+
| thread_cache_size | 64　　　　 |
+-------------------+-------+

示例中的服务器还是挺健康的。

1. 查询缓存(query cache)

mysql> show global status like ‘qcache%‘;
+-------------------------+-----------+
| Variable_name　　　　　　　　　　　 | Value　　　　　 |
+-------------------------+-----------+
| Qcache_free_blocks　　　　　　 | 22756　　　　　 |
| Qcache_free_memory　　　　　　 | 76764704　 |
| Qcache_hits　　　　　　　　　　　　　 | 213028692 |
| Qcache_inserts　　　　　　　　　　 | 208894227 |
| Qcache_lowmem_prunes　　　　 | 4010916　　　 |
| Qcache_not_cached　　　　　　　 | 13385031　 |
| Qcache_queries_in_cache | 43560　　　　　 |
| Qcache_total_blocks　　　　　 | 111212　　　　 |
+-------------------------+-----------+

MySQL查询缓存变量解释：

Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。

Qcache_free_memory：缓存中的空闲内存。

Qcache_hits：每次查询在缓存中命中时就增大

Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。

Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks和free_memory可以告诉您属于哪种情况）

Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。

Qcache_queries_in_cache：当前缓存的查询（和响应）的数量。

Qcache_total_blocks：缓存中块的数量。

我们再查询一下服务器关于query_cache的配置：

mysql> show variables like ‘query_cache%‘;
+------------------------------+-----------+
| Variable_name　　　　　　　　　　　　　　　　 | Value　　　　　 |
+------------------------------+-----------+
| query_cache_limit　　　　　　　　　　　　 | 2097152　　　 |
| query_cache_min_res_unit　　　　　 | 4096　　　　　　 |
| query_cache_size　　　　　　　　　　　　　 | 203423744 |
| query_cache_type　　　　　　　　　　　　　 | ON　　　　　　　　 |
| query_cache_wlock_invalidate | OFF　　　　　　　 |
+------------------------------+-----------+

各字段的解释：

query_cache_limit：超过此大小的查询将不缓存

query_cache_min_res_unit：缓存块的最小大小

query_cache_size：查询缓存大小

query_cache_type：缓存类型，决定缓存什么样的查询，示例中表示不缓存 select sql_no_cache 查询

query_cache_wlock_invalidate：当有其他客户端正在对MyISAM表进行写操作时，如果查询在query cache中，是否返回cache结果还是等写操作完成再读表获取结果。

query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小；查询缓存利用率在80％以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小，要不就是碎片太多。

查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%

示例服务器 查询缓存碎片率 ＝ 20.46％，查询缓存利用率 ＝ 62.26％，查询缓存命中率 ＝ 1.94％，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。

1. 排序使用情况

mysql> show global status like ‘sort%‘;
+-------------------+------------+
| Variable_name　　　　　 | Value　　　　　　 |
+-------------------+------------+
| Sort_merge_passes | 29　　　　　　　　　 |
| Sort_range　　　　　　　　 | 37432840　　　 |
| Sort_rows　　　　　　　　　 | 9178691532 |
| Sort_scan　　　　　　　　　 | 1860569　　　　 |
+-------------------+------------+

Sort_merge_passes 包括两步。MySQL 首先会尝试在内存中做排序，使用的内存大小由系统变量 Sort_buffer_size 决定，如果它的大小不够把所有的记录都读到内存中，MySQL 就会把每次在内存中排序的结果存到临时文件中，等 MySQL 找到所有记录之后，再把临时文件中的记录做一次排序。这再次排序就会增加 Sort_merge_passes。实际上，MySQL 会用另一个临时文件来存再次排序的结果，所以通常会看到 Sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件，所以速度可能会比较慢，增加 Sort_buffer_size 会减少 Sort_merge_passes 和 创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度，见 How fast can you sort data with MySQL?（引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html，貌似被墙）

另外，增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作也有一点的好处

九、文件打开数(open_files)

mysql> show global status like ‘open_files‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files　　　　 | 1410　 |
+---------------+-------+

mysql> show variables like ‘open_files_limit‘;
+------------------+-------+
| Variable_name　　　　 | Value |
+------------------+-------+
| open_files_limit | 4590　 |
+------------------+-------+

比较合适的设置：Open_files / open_files_limit * 100% <= 75％

1. 表锁情况

mysql> show global status like ‘table_locks%‘;
+-----------------------+-----------+
| Variable_name　　　　　　　　　 | Value　　　　　 |
+-----------------------+-----------+
| Table_locks_immediate | 490206328 |
| Table_locks_waited　　　　 | 2084912　　　 |
+-----------------------+-----------+

Table_locks_immediate表示立即释放表锁数，Table_locks_waited表示需要等待的表锁数，如果Table_locks_immediate / Table_locks_waited > 5000，最好采用InnoDB引擎，因为InnoDB是行锁而MyISAM是表锁，对于高并发写入的应用InnoDB效果会好些。示例中的服务器Table_locks_immediate / Table_locks_waited ＝ 235，MyISAM就足够了。

1. 表扫描情况

mysql> show global status like ‘handler_read%‘;
+-----------------------+-------------+
| Variable_name　　　　　　　　　 | Value　　　　　　　 |
+-----------------------+-------------+
| Handler_read_first　　　　 | 5803750　　　　　 |
| Handler_read_key　　　　　　 | 6049319850　 |
| Handler_read_next　　　　　 | 94440908210 |
| Handler_read_prev　　　　　 | 34822001724 |
| Handler_read_rnd　　　　　　 | 405482605　　　 |
| Handler_read_rnd_next | 18912877839 |
+-----------------------+-------------+

 

mysql> show global status like ‘com_select‘;
+---------------+-----------+
| Variable_name | Value　　　　　 |
+---------------+-----------+

 

 

1. 内在设置

SHOW VARIABLES LIKE '%have_query_cache%'是否支持查询缓存区 “YES”表是支持查询缓存区

SHOW VARIABLES LIKE '%Qcache_free_blocks%'表示未使用的块 这个值比较大，那意味着，内存碎片比较多

SHOW VARIABLES LIKE '%query_cache_limit%'可缓存的Select查询结果的最大值 1048576 byte /1024 = 1024kB 即最大可缓存的select查询结果必须小于1024KB

SHOW VARIABLES LIKE '%Qcache_free_memory%'表示查询缓存区现在还有多少的可用内存

SHOW VARIABLES LIKE '%query_cache_min_res_unit%' 每次给query cache结果分配内存的大小 默认是 4096 byte 也即 4kB

SHOW VARIABLES LIKE '%Qcache_hits%' 表示查询缓存区的命中个数，也就是直接从查询缓存区作出响应处理的查询个数

SHOW VARIABLES LIKE '%Qcache_total_blocks%'  表示所有的块

SHOW VARIABLES LIKE '%Qcache_inserts%' 表示查询缓存区此前总过缓存过多少条查询命令的结果

SHOW VARIABLES LIKE '%Qcache_lowmem_prunes%' 表示查询缓存区已满而从其中溢出和删除的查询结果的个数

SHOW VARIABLES LIKE '%Qcache_not_cached%'表示没有进入查询缓存区的查询命令个数

SHOW VARIABLES LIKE '%Qcache_queries_in_cache%' 查询缓存区当前缓存着多少条查询命令的结果

 

如果Qcache_lowmem_prunes 值比较大，表示查询缓存区大小设置太小，需要增大。

如果Qcache_free_blocks 较多，表示内存碎片较多，需要清理，flush query cache

根据我看的 《High Performance MySQL》中所述，关于query_cache_min_res_unit大小的调优

，书中给出了一个计算公式，可以供调优设置参考：

query_cache_min_res_unit = (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

 

还要注意一点的是，FLUSH QUERY CACHE 命令可以用来整理查询缓存区的碎片，改善内存使用状况，

但不会清理查询缓存区的内容，这个要和RESET QUERY CACHE相区别，不要混淆，后者才是清除查询缓存区中

的所有的内容。

 

引擎对比

 

1. Memory引擎：

    Memory存储引擎是专为非交易型应用，高速存取数据，数据100%的存在内存中永远不会写入磁盘。因此适用于临时的，需要频繁读写，对性能速度要求严格的应用中。

 

1. Merge引擎：

    MERGE存储引擎将两个或两个以上的共同结构的MyISAM表行程一个单表。不支持事务，能有效地管理大型数据集。

 

1. MyISAM引擎：

    MyISAM引擎是MySQL数据库默认的引擎，快速的载入数据和读取数据，不支持事务和灾难自动恢复数据。

 

1. NDB/MySQL Cluster引擎：

    NDB/Cluster存储引擎是专为交易型应用，而且高可用性和系统崩溃恢复支持要求极为严格的应用设计的。无共享存储格式，内部采用了同步复制技术，以提供高达99.999%的可用性，数据主要存放在内存中，提供快速反应时间为查询和数据处理行动。

 

1. IBMDB2I引擎：

   该引擎允许用户创建一个类似IBM i5平台的DB2格式表，允许通过操作MySQL环境，进入DB2数据进行数据操作。数据可以很容易的从MySQL数据库格式转换成DB2数据格式，方便应用从MySQL访问DB2。

 

1. InnoDB存储引擎：

    InnoDB存储引擎是由Innobase开发公司所拥有，目前隶属于甲骨文公司。InnoDB存储引擎是用来处理交易型应用的，拥有自动崩溃恢复功能，保持数据的完整性，高并发控制和良好响应时间。InnoDB是完全开源的自由软件，其提供GPL许可同意任何人对其进行修改和重新分配。2008年4月，一种新的插件版本的InnoDB存储引擎正式发布，该版本具有新的数据压缩行的格式和更快的创建索引能力。

 

1. Maria引擎：

    Maria引擎最初是要替代MyISAM引擎的下一代引擎，它与MyISAM功能一致，但是多提供故障自动恢复数据的功能，在未来的计划中它还要实现事务的支持和数据仓库功能。

 

1. PBXT引擎：

    改引擎全称PrimeBase XT（PBXT），是由SNAP Innovation GmbH公司开发的。是专门为交易型应用设计的，支持崩溃自动恢复，大表处理良好，完美支持变长列大小（包括BLOB字段），单个文件存放单表结构，对表结构管理更加灵活可靠，PBXT目前计划在2009年6月RC。

 

1. ScaleDB引擎：

    SaleDB存储引擎是由ScaleDB公司开发的，其目的是为提供事务应用的程序处理大数据量，同时对高可用性和可扩展性要求高的环境设计的。ScaleDB是基于共享磁盘格式数据库集群架构，使多个节点群集操作在单一的物理位置上的数据。ScaleDB适用于大型Web应用程序，它拥有适当的云计算能力，因为服务器动态可以添加和删除群集节点。SaleDB不是开源的引擎，目前仍旧是测试版。

 

1. XtraDB引擎：

    XtraDB是由Percona是克隆的InnoDB存储引擎，但它自身也包括额外的功能，如支持多个回滚片段，附加性能诊断功能和提升执行速度功能，等等。

 

1. Calpont引擎：

    Calpont是一个多线程，扩展的，分布式的存储引擎，专门为分析数据仓库设计。Calpont可以部署在单台服务器上或部署在多机的网络体系结构中，使其良好的向外扩展的能力，与能够真正具有运行大规模并行处理（MPP系统）的能力。Calpont采用列导向存储架构，大大降低的I/O解析查询。

 

1. InfoBright-BrightHouse引擎：

    BrightHouse存储引擎是由Infobright公司开发的，BrightHouse存储引擎是专为大规模的数据仓库，传统的存档/历史系统设计的。可支持高达约30TB数据在一个数据库内的数据量级。BrightHouse采用列导向数据库的数据结构和压缩，平均压缩比10:1（包括所有额外的结构压缩），Infobright提供开源的社区版和专业的企业版。

 

1. Kickfire引擎：

    Kickfire存储引擎是有Kickfire公司开发的，是为支持数据仓库高达约3TB（与目前的1.0产品）的环境设计的。Kickfire是一个基于专有设备的解决方案，不是开源的产品。该解决方案的主要区别是利用SQL芯片加速SQL执行速度，就像显卡利用图形驱动设备显示一样。Kickfire还利用以列为导向的数据库存储结构和数据的压缩，使数据平均压缩比2-3:1.Kickfire根据数据环境不同提供和众多解决方案。

 

1. TokuDB引擎：

    TokuDB的Fractal Tree索引技术能针对大表提供高性能的插入/更新/删除操作，实习快速查询。TokuDB具有良好的可扩展性。TokuDB上应用在压缩数据，减少磁盘空间等应用上。