日期:2014-05-16  浏览次数:20949 次

mysql 索引建立规则
索引创建规则:
?1、表的主键、外键必须有索引;
?2、数据量超过300的表应该有索引; 
 3、经常与其他表进行连接的表,在连接字段上应该建立索引
 4、经常出现在Where子句中的字段,特别是大表的字段,应该建立索引;
?5、索引应该建在选择性高的字段上; 
 6、索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建索引;
?7、复合索引的建立需要进行仔细分析;尽量考虑用单字段索引代替: 
 A、正确选择复合索引中的主列字段,一般是选择性较好的字段;
?B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中?单字段查询是否极少甚至没有?如果是,
则可以建立复合索引;否则考虑单字段索引; 
 C、如果复合索引中包含的字段经常单独出现在Where子句中,则分解为多个单字段索引;
?D、如果复合索引所包含的字段超过3个,那么仔细考虑其必要性,考虑减少复合的字段;
?E、如果既有单字段索引,又有这几个字段上的复合索引,一般可以删除复合索引;
?8、频繁进行数据操作的表,不要建立太多的索引;
?9、删除无用的索引,避免对执行计划造成负面影响; 以上是一些普遍的建立索引时的判断依据。
一言以蔽之,索引的建立必须慎重,对每个索引的必要性都应该经过仔细分析,要有建立的依据。
因为太多的索引与不充分、不正确的索引对性能都毫无益处:在表上建立的每个索引都会增加存储开销,
索引对于插入、删除、更新操作也会增加处理上的开销。另外,过多的复合索引,在有单字段索引的情况下,
一般都是没有存在价值的;相反,还会降低数据增加删除时的性能,特别是对频繁更新的表来说,负面影响更大。 

oracle的索引陷阱
一个表中有几百万条数据,对某个字段加了索引,但是查询时性能并没有什么提高,这主要可能是oracle的索引限制造成的。?
oracle的索引有一些索引限制,在这些索引限制发生的情况下,即使已经加了索引,oracle还是会执行一次全表扫描,查询的性能不会比不加索引有所提高,反而可能由于数据库维护索引的系统开销造成性能更差。?
下面是一些常见的索引限制问题。
?
1、使用不等于操作符(<>, !=)
下面这种情况,即使在列dept_id有一个索引,查询语句仍然执行一次全表扫描?
select * from dept where staff_num <> 1000;?
但是开发中的确需要这样的查询,难道没有解决问题的办法了吗??
有!?
通过把用 or 语法替代不等号进行查询,就可以使用索引,以避免全表扫描:上面的语句改成下面这样的,就可以使用索引了。?
select * from dept shere staff_num < 1000 or dept_id > 1000;?
?
2、使用 is null 或 is not null
使用 is null 或is nuo null也会限制索引的使用,因为数据库并没有定义null值。如果被索引的列中有很多null,就不会使用这个索引(除非索引是一个位图索引,关于位图索引,会在以后的blog文章里做详细解释)。在sql语句中使用null会造成很多麻烦。?
解决这个问题的办法就是:建表时把需要索引的列定义为非空(not null)
?
3、使用函数
如果没有使用基于函数的索引,那么where子句中对存在索引的列使用函数时,会使优化器忽略掉这些索引。下面的查询就不会使用索引:?
select * from staff where trunc(birthdate) = '01-MAY-82';?
但是把函数应用在条件上,索引是可以生效的,把上面的语句改成下面的语句,就可以通过索引进行查找。?
select * from staff where birthdate < (to_date('01-MAY-82') + 0.9999);?
?
4、比较不匹配的数据类型
比较不匹配的数据类型也是难于发现的性能问题之一。
下面的例子中,dept_id是一个varchar2型的字段,在这个字段上有索引,但是下面的语句会执行全表扫描。?
select * from dept where dept_id = 900198;?
这是因为oracle会自动把where子句转换成to_number(dept_id)=900198,就是3所说的情况,这样就限制了索引的使用。
把SQL语句改为如下形式就可以使用索引?
select * from dept where dept_id = '900198';

?

?

二,

?各种索引使用场合及建议

?

(1)B*Tree索引。

常规索引,多用于oltp系统,快速定位行,应建立于高cardinality列(即列的唯一值除以行数为一个很大的值,存在很少的相同值)。

?Create index indexname on tablename(columnname[columnname...])

(2)反向索引。

B*Tree的衍生产物,应用于特殊场合,在ops环境加序列增加的列上建立,不适合做区域扫描。

?Create index indexname on tablename(columnname[columnname...]) reverse

(3)降序索引。

B*Tree的衍生产物,应用于有降序排列的搜索语句中,索引中储存了降序排列的索引码,提供了快速的降序搜索。

?Create index indexname on tablename(columnname DESC[columnname...])

(4)位图索引。

位图方式管理的索引,适用于OLAP(在线分析)和DSS(决策处理)系统,应建立于低cardinality列,
适合集中读取,不适合插入和修改,提供比B*Tree索引更节省的空间。

?Create BITMAP index indexname on tablename(columnname[columnname...])

在实际应用中,如果某个字段的值需要频繁更新,那么就不适合在它上面创建位图索引。
在位图索引中,如果你更新或插入其中一条数值为N的记录,
那么相应表中数值为N的记录(可能成百上千条)全部被Oracle锁定,
这就意味着其它用户不能同时更新这些数值为N的记录,其它用户必须要等第一个用户提交后,
才能获得锁,更新或插入数据,bitmap index它主要用于决策支持系统或静态数据。

(5)函数索引。

B*Tree的衍生产物,应用于查询语句条件列上包含函数的情况,
索引中储存了经过函数计算的索引码值。可以在不修改应用程序的基础上能提高查询效率。

索引创建策略?
1.导入数据后再创建索引?
2.不需要为很小的表创建索引?
3.对于取值范围很小的字段(比如性别字段)应当建立位图索引?
4.限制表中的索引的数目?
5.为索引设置合适的PCTFREE值?
6.存储索引的表空间最好单独设定

唯一索引和不唯一索引都只是针对B树索引而言.?
Oracle最多允许包含32个字段的复合索引?
由此估计出一个查询如果使用某个索引会需要读入的数据块块数。
需要读入的数据块越多,则 cost 越大,Oracle 也就越有可能不选择使用 index

?

三,

能用唯一索引,一定用唯一索引?
能加非空,就加非空约束?
一定要统计表的信息,索引的信息,柱状图的信息。?
联合索引的顺序不同,影响索引的选择,尽量将值少的放在前面?
只有做到以上四点,数据库才会正确的选择执行计划。

=================