sql 优化
Posted coolid
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了sql 优化相关的知识,希望对你有一定的参考价值。
readcommitted(mysql默认)
readuncommitted
repeatableread(oracle默认)
serialzable
应该建索引
1、在经常需要搜索的列上,可以加快搜索的速度
2、在作为主键的列上,强制改列的唯一性和组织表中中数据的排列结构
3、在经常用在连接的列上,主要是一些外键,可以加快连接速度
4、在经常需要根据范围进行搜索的列上创建,因为索引已经排序,其指定的范围是连续的
5、在经常需要排序的列上,因为索引已经排序,这样查询可以利用索引的排序,加快排序时间
6、在经常使用where自居的列上,加快条件的判断速度
建立索引,一般按照select的where条件来建立,如 有f1和f2,那么如果我们在f1或f2建立索引是没有用的,只有f1和f2同时都建立索引才有效果
不适合创建索引
1、对于查询中很少使用或者参考的列
降低了系统的维护速度和增大了空间需求
2、对于只有很少数据值的列
由于取值很紹,比如性别,在查询的结果中,结果集的数据行占了表中数据的很大比,即需要在表中搜索的数据行的比列很大,增加索引,并不能明显加快检索速度
3、对于那些定义为text、image、bit数据类型的列
这些数据量要么相当大、要么取值很紹
4、当修改性能远远大于检索性能时,不该创建
修改性能和检索性能时互相矛盾的,因此当修改性能远远大于检索性能时,不该创建索引
sql优化
1、对查询进行优化,应尽量避免全表扫描,首先应考虑在where及 order by 设计的列上建立索引
2、应尽量避免在where子句中对字段镜像 null 值判断,否则将导致引擎放弃索引而全表扫描
3、应尽量避免在where子句中使用!= 或<> 操作符,否则将导致引擎放弃索引而全表扫描
4、应尽量避免在where子句中使用 or 来连接条件,否则将导致引擎放弃索引而全表扫描
5、in 和 not in 也要慎用,否则将导致引擎放弃索引而全表扫描
6、like 左右都匹配如 like ‘%abc%‘ 也将导致全民扫描,否则将导致引擎放弃索引而全表扫描
7、应尽量避免在where子句中对字段进行表达式、函数、算术运算等操作,
如: where num/2 = 100 而应 num = 100*2
where substring(name,1,3)=‘abc‘ 应改为 name like ‘abc%‘
8、在使用索引字段作为条件时,如果该索引是符合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引。否则该索引不会被使用,并且应尽可能的让字段顺序和索引顺序相一致。
9、很多时候用 exists 代替 in 是一个很好的选择
select num from a where num in (select num from b)
用下面的语句替换
select num from a where exists( select 1 from b where num = a.num)
10、并不是所有索引对查询都有效,sql是根据表中数据来进行查询优化的,当索引列有大量数据重复时,sql可能不会去利用索引,如一
表中有字段sex,male、female几乎各一半,那即时建了索引也对查询效率起不了作用。
11、索引并不是越多越好,索引固然可以提高相应的select 的效率,但同时也降低了insert 及update的效率,因为 insert或update 有时可能会重复建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要
12、尽量使用数字型字段,若只含数值信息的字段尽量不要涉及为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会诸葛比较字符串中每一个字符,而对数字类型而言只需要比较一次就够了。
13、尽可能使用varchar代替 char,因为首先变长字段存储空间小。可以洁身存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要更高些
14、任何地方都不使用 select * from t ,用具体的字段列表代替*,不要返回用不到的任何字段。
以上是关于sql 优化的主要内容,如果未能解决你的问题,请参考以下文章