sql优化

使用explain（）查看性能

使用like进行模糊查询

◆where username like ‘ %column % ’'
◆关键词% column%，由于 column前面用到了“%”，因此该查询必然走全表扫描
◆like 'a%' 会用到索引

索引问题
◆首先应考虑在 where 及 order by 涉及的列上建立索引
不要在建立的索引的数据列上进行下列操作:

◆避免对索引字段进行计算操作

◆避免在索引字段上使用not，<>，!=

◆避免在索引列上使用IS NULL和IS NOT NULL

◆避免在索引列上出现数据类型转换

◆避免在索引字段上使用函数

◆避免建立索引的列中使用空值

在WHERE 语句中，尽量避免对索引字段进行计算操作
避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描

避免在WHERE子句中使用in，not  in，or 或者having

可以使用 exist 和not exist代替 in和not in，Having可以用where代替

避免在 where 子句中使用 != 或 <> 操作符
避免在 where 子句中使用 or 来连接条件
left join > not exists > not in
left join on where
如：

select id from t where num=10 or Name = 'admin'

可以这样查询：

select id from t where num = 10
union all
select id from t where Name = 'admin'

不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算

count(column) 是表示结果集中有多少个column字段不为空的记录
count(*) 是表示整个结果集有多少条记录

用Where子句替换HAVING子句： 
避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销. (非oracle中)on、where、having这三个都可以加条件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，where也应该比having快点的，因为它过滤数据后才进行sum，在两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们的结果是一样的，只是where可以使用rushmore技术，而having就不能，在速度上后者要慢如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不确定的，根据上篇写的工作流程，where的作用时间是在计算之前就完成的，而having就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。在多表联接查询时，on比where更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由where进行过滤，然后再计算，计算完后再由having进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里 

减少对表的查询： 
在含有子查询的SQL语句中,要特别注意减少对表的查询.例子： 
    SELECT  TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT 
TAB_NAME,DB_VER FROM  TAB_COLUMNS  WHERE  VERSION = 604) 

使用表的别名(Alias)

尽量多使用COMMIT： 
只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也会因为COMMIT所释放的资源而减少

复合索引
索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找