S Q L 优化

在应用的的开发过程中，由于初期数据量小，开发人员写SQL语句时更重视功能上的实现，但是当应用系统正式上线后，随着生产数据量的急剧增长，很多SQL语句开始逐渐显露出性能问题，对生产的影响也越来越大，此时这些有问题的SQL语句就成为整个系统性能的瓶颈，因此我们必须要对它们进行优化。

优化SQL语句的一般步骤

• 通过show status命令了解各种SQL的执行频率

MySQL客户端连接成功后，通过show [session|global]status命令可以提供服务器状态信息，

session:当前连接的统计；

global:自数据库上次启动至今的统计结果;

执行 show  global status like 'Com_%';                         //列出自数据库上次启动至今的统计结果。

如上说明：

上面这些参数对于所有存储引擎的表操作都会进行累计。下面这几个参数只是针对InnoDB存储引擎的，累加的算法也略有不同。

• Innodb_rows_read：select查询返回的行数。
• Innodb_rows_inserted：执行INSERT操作插入的行数。
• Innodb_rows_updated：执行UPDATE操作更新的行数。
• Innodb_rows_deleted：执行DELETE操作删除的行数。

通过以上几个参数，可以很容易地了解当前数据库的应用是以插入更新为主还是以查询操作为主，以及各种类型的SQL大致的执行比例是多少。对于更新操作的计数，是对执行次数的计数，不论ᨀ交还是回滚都会进行累加。

对于事务型的应用，通过Com_commit和Com_rollback可以了解事务ᨀ交和回滚的情况，对于回滚操作非常频繁的数据库，可能意味着应用编写存在问题。

•      使用explain来分析:

可以通过EXPLAIN或者DESC命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序，

     explain select * from dvbprogram group by name;

     Type:System>const>eq_ref>all(是性能最差的)

经过以上步骤，基本就可以确认问题出现的原因。此时用户可以根据情况采取相应的措施，进行优化ᨀ高执行的效率。

在上面的例子中，已经可以确认是对dvbprogram 表的全表扫᧿导致效率的不理想，那么对dvbprogram 表的name字段创建索引，具体如下：

当表引擎为：INNDB时

explain select * from dvbprogram  where name='test'; 

扫描的行数就变成了1行；

可见索引的使用可以大大ᨀ高数据库的访问速度，尤其在表很庞大的时候这种优势更为明显。