位图索引的基本信息
一.什么是位图索引而位图索引主要针对大量相同值的列而创建(例如：类别，操作员，部门ID,库房ID等),索引块的一个索引行中存储键值和起止Rowid,以及这些键值的位置编码,位置编码中的每一位表示键值对应的数据行的有无.一个块可能指向的是几十甚至成百上千行数据的位置.这种方式存储数据,相对于B*Tree索引,占用的空间非常小,创建和使用非常快.当根据键值查询时,可以根据起始Rowid和位图状态,快速定位数据.当根据键值做and,or或 in(x,y,..)查询时,直接用索引的位图进行或运算,快速得出结果行数据.当select count(XX) 时,可以直接访问索引就快速得出统计数据.创建语法很简单,就是在普通索引创建的语法中index前加关键字bitmap即可,例如:create bitmap index H病人挂号记录_ix_执行人 on H病人挂号记录(执行人);
[create_time]2016-05-28 07:20:30[/create_time]2016-06-10 16:52:37[finished_time]1[reply_count]0[alue_good]强少3325[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.a136ba35.ZzyIT1VWHdOynCUw7XEy4A.jpg?time=3631&tieba_portrait_time=3631[avatar]TA获得超过133个赞[slogan]这个人很懒，什么都没留下![intro]87[view_count]位图、灰度、双色调、索引色的含义
位图-即黑白模式图像，转换成位图后，图片只有黑白两色，且只有一个通道（它的特点，用于早期的报版印刷，“黑白报纸”）
灰度-单通道模式，从白-灰-黑共256级灰阶变化（用于普通灰度印刷）
双色调-单通道模式，（它通过自定义四种油墨的配比产生一种专色油墨，用双色调来实现专色印刷可以降低成本）
索引色-单通道256彩色模式（网页上常用索引，但不全用索引，当有小图片、小LOGO、小按纽、带动画、带透明这些要求时才用索引，真彩照片如果用索引，品质非但不好，容量还很大，索引色保存下来是GIF格式，GIF是支持动画的）
8位RGB-俗称“24位真彩图像”8位指的是每通道8位位深，RGB不是三通道么，3*8=24位，
每一个通道的灰阶有256级，例如红色就有256级红，所以RGB重现256*256*256=1678万种颜色
16位-指的是从每通道的8位，一下跳到了16位，不说得那么细，至少你可以知道，颜色的级别更多了，重现的颜色会更广。
32位-同理，32位一般用在电影，电影的胶片是32位的，所以这就是为什么电影质感，比某些电视好看很多的原因。
[create_time]2022-12-25 20:33:52[/create_time]2023-01-05 22:34:49[finished_time]1[reply_count]0[alue_good]禄梅敖仪[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.32e86cd0.90KlIF46TciFklDe-uEGBw.jpg?time=10649&tieba_portrait_time=10649[avatar]TA获得超过3.7万个赞[slogan]这个人很懒，什么都没留下![intro]14[view_count]
如何提高Oracle位图索引的使用效果
位图索引是Oralce数据库索引中的异类，其在某些比较特殊的场合中有突出的表现。一般来说，位图索引的效果直接跟列的基数相关。为此在谈到如何提高位图索引的使用效果时，也往往跟这个列的基数相关。为此必须对这个列的基数有一个清晰的认识。
一、什么时候改采用位图索引
基数是指某个列可能拥有的不重复数值的个数。比如说在一个中华人民共和国公民的信息表中，包含着十几亿条的记录。但是在这些记录中，有几个比较特殊的列，其指包含几个有限的重复数值。如性别这一字段，其就只有男与女两个可能值;如在民族一列内也只有56个不重复的值;如在出身地一列内，中国只有34个省市自治区。
有时候用户可能需要根据这些列来查询相关的数据。如公司搞活动的时候，可能需要确认一下活动有没有涉及到宗教的禁忌，如可能涉及到回族的禁忌的话，那么就需要查询一下员工信息系统，看看公司有没有回族的员工。如公司可能在三八妇女节的时候，会给女员工提供一定的福利，为此也需要在数据库中拉出女员工的名单，此时也就是根据性别这个字段来查询数据。等等。如果用户查询的列的基数非常的小，只是有限的几个固定值，如性别、民族、行政区等等。要为这些基数值比较小的列建立索引时，就需要建立位图索引。如果一定要说一个具体的标准的话，那么笔者认为如果基数值在整个表记录的2%以内或者字段内容的重复值在100次以上，则通过位图索引可以起到不错的效果。
大部分情况下都是通过基数值来确定是否需要使用位图索引。但是还有一种比较特殊的情况，可能这个列的基数值非常的大，也就是说这个列中的值重复性不是很高。但是只要起满足一定的条件，那么在这个字段上创建位图索引，也可以起到不错的效果。一般来说，如果字段往往在Where查询条件语句中被用到，并且采用的运算符为AND
或者OR 的逻辑运算符号的话，那么其效果也比建议其他索引要好的多。
二、把需要建立位图索引的列设置为固定长度的数据类型。
在Oracle数据库中，数据类型从大的来说，包括固定长度的数据类型与可变长度的数据类型。如就拿字符型数据来说，就有固定长度的字符串类型(char)与可变长度的字符串类型(VARCHAR2
)。这两个数据类型都是字符串数据类型，它们的差别主要在于字符串长度的控制上。CHAR存储固定长度的字符串。如果实际存储的字符串没有达到其规定的最大值的话，则数据库系统会自动在后面加上空格。而VARCHAR2则主要用来存储可变长度的字符数据类型。如存储固定长度的CHAR字符串类型不同，如果在这个列中存储的数据没有达到规定的最大值，
则数据库系统不会在最后加入空格，以实际的字符串存储。如果从数据库的体积上来看，肯定是可变长的数据类型比较好。
但是如果从位图索引的效果上来看，则最好把建立位图索引的列设置为固定长度的数据类型。因为位图索引使用固定长度的数据类型要比可变长度的数据类型在性能上要更加的优越。也就是说，如果要在某个字符类型的列上建立位图索引，那么最好把这个列的数据类型设置为char(即使其实际存储的长度不同)，而不是设置额外NVCHAR2。因为相对于性能的提升来说，这点空间的损失仍然是值得的。
另外我们也可以通过其他一些手段来保证列中存储内存长度的一致。如拿中国的行政区为例，大部分行政区就是3个字，如浙江省;但是长度比较长的有8个字符，如新疆维吾尔自治区。如果记录比较多的话，累积下来确实会造成比较大的浪费。在这种情况下，数据库管理在设计的时候，可以采用一些折中的处理方式。如利用简称来代表各个省份的名字。还有一种就是在存储的时候利用数字来表示省份，然后再在另外一张表中建立数字与省份之间的对应关系。笔者建议采用的是后面一种方式。
总之如果要为某个列建立位图索引的话，则数据库管理员最好能够想方设法让这个字段采用固定长度的数据类型，有时候即使牺牲一点存储空间也是在所不辞。
三、位图索引的使用限制。
虽然说位图索引在基数比较小的列或者使用到逻辑运算符时能够显著的提高数据库的查询性能，但是其在使用的时候仍然有不少的限制。数据库管理员需要了解这些限制，如此的话在数据库设计时才不会竹篮子打水一场空。
如把某个字段设置为位图索引的话，最好采用固定长度的数据类型。同时这个长度有最大的限制。在最新的Oracle数据库版本中，这个位图索引的最大长度不能够超过30。不知道以后的版本中会不会放宽这个长度上的限制。如位图索引不能够被声明为唯一索引;如位图索引不包含认为列数据，并且不能够用于任何类型的完整性检查;如当执行ALTER
TABLE语句并修改包含有位图索引的列时，这会使位图索引失效。
最重大的一个限制是基于规则的优化器不会考虑位图索引。Oracle数据库系统在执行一个SQL之前，首先要分析一下语句的执行计划，然后再按执行计划去执行。分析语句的执行计划的工作是由优化器来完成的。Oracle的优化器共有两种的优化方式，即基于规则的优化方式和基于成本的优化方式。基于规则的优化方式是指优化器在分析SQL语句时，所遵循的是Oracle内部预定的一些规则。基于成本的优化方式是看语句的执行成本。这里的成本主要指Cpu和内存。优化器在判断是否用这种方式时，主要参照的是表及索引的统计信息。统计信息给出表的大小、有少行、每行的长度等信息。然后数据库系统会根据这些信息来确定是否需要采用这个优化方式。另外还有根据这两个优化模式衍生出来的优化器。
总之数据库管理理员需要明确的一点就是，如果要采用位图索引的话，则最好把数据库的优化器选择为基于成本的优化器模式。因为如果数据库采用的是基于规则的优化器模式的话，则会忽略位图索引。那么此时数据库管理员所建立的位图索引将一无用处。这一点大部分数据库管理员可能并不清楚，一定要引以为鉴。
四、同一个查询中合并多个位图索引。
通常情况下在同一个查询中合并多个位图索引后，可以使得数据库的查询性能得到显著的提高。也就是说，如在员工信息表中有性别、婚姻状态、职称等字段。这些字段都是基数比较低的字段，可以用来创建位图索引。如果现在用户在查询的时候，需要根据上面这三个字段来查询员工的信息，如需要查找性别为女、婚姻状态为已婚、职称为经理层以上的员工信息，为他们举行一个家庭派对的活动。此时在查询条件中就需要用到这个三个位图索引字段。数据库在执行查询计划的时候，如果Where字句中包含了这些位图索引字段的话，择优化器会依次使用3个单独的位图索引。每个位图记录指针，用于指示表中哪些行包含位图中的已知值。有了这些重要信息之后，数据库会执行一个位图AND操作并将从所有的四个位图中返回哪些行。然后再把这些值转换为ROWID值，并且查询继续完成剩余的处理工作(根据ROWID的值查询其他的信息)。
也就是说，如果在一个查询条件语句中，采用了多个位图索引来进行查询的话，其查询的效果是1+1〉2的效果。为此在应用程序设计中，可以把一些位图索引的字段作为查询条件都放置在查询窗口中，以明示的方式让用户选择查询条件。这对于提高应用程序的查询性能具有很大的帮助。
在Oracle数据库中一个表中最大可以支持30个位图索引。当然实际工作中往往用不了这么多。因为通常情况下只有在基数值比较小的列上利用这个位图索引才能够起到比较好的效果。相反如果在一些基数值比较大的列上采用位图索引的话，反而会起到相反的效果。而在一张表中基数列小的值不会很大。所以说数据库管理员更加需要关注这些基数列比较小的值。如果用户有对这些基数值小的列进行查询的习惯，那么数据库管理员就不能够有任何吝啬，要马上把这些列设置为位图索引。并且在查询设计的时候，最好能够在同一个查询中合并多个位图索引，以提高查询的性能。
[create_time]2018-01-01 16:21:58[/create_time]2018-01-16 16:12:03[finished_time]1[reply_count]1[alue_good]j88r[uname]https://himg.bdimg.com/sys/portrait/item/public.1.44399bcc.SfLqVBDJ_7E32jgAgL98gQ.jpg[avatar]知道合伙人软件行家[slogan]从事多年系统运维，喜欢编写各种小程序和脚本。[intro]189[view_count]
比较b-tree索引和bit-wise索引技术的区别，各自适用的场合
一.B-Tree索引:
1. 选项择索引字段的原则:
l 在WHERE子句中最频繁使用的字段
l 联接语句中的联接字段
l 选择高选择性的字段(如果很少的字段拥有相同值,即有很多独特值,则选择性很好)
l ORACLE在UNIQUE和主键字段上自动建立索引
l 在选择性很差的字段上建索引只有在这个字段的值分布非常倾斜的情况下下才有益(在这种情况下,某一,两个字段值比其它字值少出现很多)
l 不要在很少独特值的字段上建B-TREE索引,在这种情况下,你可以考虑在这些字段上建位图索引.在联机事务处理环境下,所由并发性非常高,索引经常被修改,所以不应该建位图索引
l 不要在经常被修改的字段上建索引.当有UPDATE,DELETE,INSETT操作时,ORACLE除了要更新表的数据外,同时也要更新索引,而且就象更新数据一样,或产生还原和重做条目
l 不要在有用到函数的字段上建索引,ORACLE在这种情况,优化器不会用到索引,除非你建立函数索引
l 可以考虑在外键字段上建索引,这些索引允许当在主表上UPDATE,DELETE操作时,不需要共享子表的锁,这非常适用于在父表和子表上有很多并发的INSERT,UPDATE和DELETE操作的情况
l 当建立索引后,请比较一下索引后所获得的查询性能的提高和UPDATE,DELETE,INSERT操作性能上的损失,比较得失后,再最后决定是否需建立这个索引
2. 选择建立复合索引
复合索引的优点:
l 改善选择性:复合索引比单个字段的索引更具选择性
l 减少I/O:如果要查询的字段刚好全部包含在复合索引的字段里,则ORACLE只须访问索引,无须访问表
什么情况下优化器会用到复合索引呢?
(a)当SQL语句的WHERE子句中有用到复合索引的领导字段时,ORACLE优化器会考虑用到复合索引来访问.
(b)当某几个字段在SQL语句的WHERE子句中经常通过AND操作符联合在一些使用作为过滤谓词,并且这几个字段合在一起时选择性比各自单个字段的选择性要更好时,可能考虑用这几个字段来建立复合索引.
(c)当有几个查询语句都是查询同样的几个字段值时,则可以考虑在这几个字段上建立复合索引.
复合索引字段排序的原则:
l 确保在WHERE子句中使用到的字段是复合索引的领导字段
l 如果某个字段在WHERE子句中最频繁使用,则在建立复合索引时,考虑把这个字段排在第一位(在CREATE INDEX语句中)
l 如果所有的字段在WHERE子句中使用频率相同,则将最具选择性的字段排在最前面,将最不具选择性的字段排在最后面
l 如果所有的字段在WHERE子句中使用频率相同,如果数据在物理上是按某一个字段排序的,则考虑将这个字段放在复合索引的第一位
B-Tree 索引是 MySQL 数据库中使用最为频繁的索引类型，除了 Archive 存储引擎之外的其他所有的存储引擎都支持 B-Tree 索引。
不仅仅在 MySQL 中是如此，实际上在其他的很多数据库管理系统中B-Tree 索引也同样是作为最主要的索引类型，这主要是因为 B-Tree 索引的存储结构在数据库的数据检索中有非常优异的表现。
一般来说， MySQL 中的 B-Tree 索引的物理文件大多都是以 Balance Tree 的结构来存储的，也就 是所有实际需要的数据都存放于 Tree 的 Leaf Node ，而且到任何一个 Leaf Node 的最短路径的长度都是完全相同的，所以我们大家都称之为 B-Tree 索引当然，可能各种数据库（或 MySQL 的各种存储引擎）在存放自己的 B-Tree 索引的时候会对存储结构稍作改造。如 Innodb 存储引擎的 B-Tree 索引实际使用的存储结构实际上是 B+Tree ，也就是在 B-Tree 数据结构的基础上做了很小的改造，在每一个
Leaf Node 上面出了存放索引键的相关信息之外，还存储了指向与该 Leaf Node 相邻的后一个 LeafNode 的指针信息，这主要是为了加快检索多个相邻 Leaf Node 的效率考虑。
二、bit-wise原理
bit-wise原理，表存在两个列AA和BB。我们现在要在AA上建bit-wise索引。
1.生成索引
计算bit vector的数量
针对AA列，我们用32bit整数(实际上只需3bit来表达，为了描述更通用的情况，所以用了32bit)来表达AA列上的值，我们需要32个bit vector。
2.生成bit-wise索引
bit vector中的位图的数量与表中记录的数量一样。
3.单值查找
假设我们执行条件为where AA=1的查询。1的二进制表示是{0…0,1}，分别与bit-vector执行and运算，结果见图3。通过结果bit-vector即可获取目标记录，通过bit-vector进行集合运算也是非常方便的，比如count运算。
在 Innodb 存储引擎中，存在两种不同形式的索引，一种是 Cluster 形式的主键索引（ Primary Key ），另外一种则是和其他存储引擎（如 MyISAM 存储引擎）存放形式基本相同的普通 B-Tree 索引，这种索引在 Innodb 存储引擎中被称为 Secondary Index 。下面我们通过图示来针对这两种索引的存放形式做一个比较。
[create_time]2016-05-27 11:35:43[/create_time]2016-05-08 11:44:41[finished_time]4[reply_count]0[alue_good]百度网友0244dbf9[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.8261a413.ywQ_-nwHhUykZX1q4T6y7A.jpg?time=4023&tieba_portrait_time=4023[avatar]TA获得超过1652个赞[slogan]这个人很懒，什么都没留下![intro]400[view_count]
数据库建立索引怎么利用索引查询？
1.合理使用索引\x0d\x0a索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。\x0d\x0a索引的使用要恰到好处，其使用原则如下：\x0d\x0a在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。\x0d\x0a在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。\x0d\x0a在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。\x0d\x0a如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。\x0d\x0a使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而 使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量 数据后，删除并重建索引可以提高查询速度。\x0d\x0a(1)在下面两条select语句中:\x0d\x0aSELECT * FROM table1 WHERE field1=0; \x0d\x0aSELECT * FROM table1 WHERE field1>=0 AND field1=0,则第一条select语句要比第二条select语句效率高的多，因为第二条select语句的第一个条件耗费了大量的系统资源。\x0d\x0a第一个原则：在where子句中应把最具限制性的条件放在最前面。\x0d\x0a(2)在下面的select语句中:\x0d\x0aSELECT * FROM tab WHERE a=? AND b=? AND c=?;\x0d\x0a若有索引index(a,b,c)，则where子句中字段的顺序应和索引中字段顺序一致。\x0d\x0a第二个原则：where子句中字段的顺序应和索引中字段顺序一致。\x0d\x0a—————————————————————————— \x0d\x0a以下假设在field1上有唯一索引I1，在field2上有非唯一索引I2。 \x0d\x0a—————————————————————————— \x0d\x0a(3) SELECT field3,field4 FROM tb WHERE field1='sdf' 快 \x0d\x0aSELECT * FROM tb WHERE field1='sdf' 慢[/cci]\x0d\x0a因为后者在索引扫描后要多一步ROWID表访问。\x0d\x0a(4) SELECT field3,field4 FROM tb WHERE field1>='sdf' 快 \x0d\x0aSELECT field3,field4 FROM tb WHERE field1>'sdf' 慢\x0d\x0a因为前者可以迅速定位索引。\x0d\x0a(5) SELECT field3,field4 FROM tb WHERE field2 LIKE 'R%' 快 \x0d\x0aSELECT field3,field4 FROM tb WHERE field2 LIKE '%R' 慢，\x0d\x0a因为后者不使用索引。\x0d\x0a(6) 使用函数如： \x0d\x0aSELECT field3,field4 FROM tb WHERE upper(field2)='RMN'不使用索引。\x0d\x0a如果一个表有两万条记录，建议不使用函数；如果一个表有五万条以上记录，严格禁止使用函数！两万条记录以下没有限制。\x0d\x0a(7) 空值不在索引中存储，所以 \x0d\x0aSELECT field3,field4 FROM tb WHERE field2 IS[NOT] NULL不使用索引。\x0d\x0a(8) 不等式如 \x0d\x0aSELECT field3,field4 FROM tb WHERE field2!='TOM'不使用索引。 \x0d\x0a相似地， \x0d\x0aSELECT field3,field4 FROM tb WHERE field2 NOT IN('M','P')不使用索引。\x0d\x0a(9) 多列索引，只有当查询中索引首列被用于条件时，索引才能被使用。\x0d\x0a(10) MAX，MIN等函数，使用索引。 \x0d\x0aSELECT max(field2) FROM tb 所以，如果需要对字段取max，min，sum等，应该加索引。\x0d\x0a一次只使用一个聚集函数，如： \x0d\x0aSELECT “min”=min(field1), “max”=max(field1) FROM tb \x0d\x0a不如：SELECT “min”=(SELECT min(field1) FROM tb) , “max”=(SELECT max(field1) FROM tb)\x0d\x0a(11) 重复值过多的索引不会被查询优化器使用。而且因为建了索引，修改该字段值时还要修改索引，所以更新该字段的操作比没有索引更慢。\x0d\x0a(12) 索引值过大（如在一个char(40)的字段上建索引），会造成大量的I/O开销（甚至会超过表扫描的I/O开销）。因此，尽量使用整数索引。 Sp_estspace可以计算表和索引的开销。\x0d\x0a(13) 对于多列索引，ORDER BY的顺序必须和索引的字段顺序一致。\x0d\x0a(14) 在sybase中，如果ORDER BY的字段组成一个簇索引，那么无须做ORDER BY。记录的排列顺序是与簇索引一致的。\x0d\x0a(15) 多表联结（具体查询方案需要通过测试得到） \x0d\x0awhere子句中限定条件尽量使用相关联的字段，且尽量把相关联的字段放在前面。 \x0d\x0aSELECT a.field1,b.field2 FROM a,b WHERE a.field3=b.field3\x0d\x0afield3上没有索引的情况下: \x0d\x0a对a作全表扫描，结果排序 \x0d\x0a对b作全表扫描，结果排序 \x0d\x0a结果合并。 \x0d\x0a对于很小的表或巨大的表比较合适。\x0d\x0afield3上有索引 \x0d\x0a按照表联结的次序，b为驱动表，a为被驱动表 \x0d\x0a对b作全表扫描 \x0d\x0a对a作索引范围扫描 \x0d\x0a如果匹配，通过a的rowid访问\x0d\x0a(16) 避免一对多的join。如： \x0d\x0aSELECT tb1.field3,tb1.field4,tb2.field2 FROM tb1,tb2 WHERE tb1.field2=tb2.field2 AND tb1.field2=‘BU1032’ AND tb2.field2= ‘aaa’ \x0d\x0a不如： \x0d\x0adeclare @a varchar(80) \x0d\x0aSELECT @a=field2 FROM tb2 WHERE field2=‘aaa’ \x0d\x0aSELECT tb1.field3,tb1.field4,@a FROM tb1 WHERE field2= ‘aaa’\x0d\x0a(16) 子查询 \x0d\x0a用exists/not exists代替in/not in操作 \x0d\x0a比较： \x0d\x0aSELECT a.field1 FROM a WHERE a.field2 IN(SELECT b.field1 FROM b WHERE b.field2=100) \x0d\x0aSELECT a.field1 FROM a WHERE EXISTS( SELECT 1 FROM b WHERE a.field2=b.field1 AND b.field2=100) \x0d\x0aSELECT field1 FROM a WHERE field1 NOT IN( SELECT field2 FROM b) \x0d\x0aSELECT field1 FROM a WHERE NOT EXISTS( SELECT 1 FROM b WHERE b.field2=a.field1)\x0d\x0a(17) 主、外键主要用于数据约束，sybase中创建主键时会自动创建索引，外键与索引无关，提高性能必须再建索引。\x0d\x0a(18) char类型的字段不建索引比int类型的字段不建索引更糟糕。建索引后性能只稍差一点。\x0d\x0a(19) 使用count(*)而不要使用count(column_name)，避免使用count(DISTINCT column_name)。\x0d\x0a(20) 等号右边尽量不要使用字段名，如： \x0d\x0aSELECT * FROM tb WHERE field1 = field3\x0d\x0a(21) 避免使用or条件，因为or不使用索引。\x0d\x0a2.避免使用order by和group by字句。\x0d\x0a因为使用这两个子句会占用大量的临时空间(tempspace),如果一定要使用，可用视图、人工生成临时表的方法来代替。 \x0d\x0a如果必须使用，先检查memory、tempdb的大小。 \x0d\x0a测试证明，特别要避免一个查询里既使用join又使用group by，速度会非常慢！\x0d\x0a3.尽量少用子查询，特别是相关子查询。因为这样会导致效率下降。\x0d\x0a一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。\x0d\x0a4．消除对大型表行数据的顺序存取\x0d\x0a在 嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。 \x0d\x0a比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询 10亿行数据。 \x0d\x0a避免这种情况的主要方法就是对连接的列进行索引。 \x0d\x0a例如，两个表：学生表（学号、姓名、年龄??）和选课表（学号、课程号、成绩）。如果两个 表要做连接，就要在“学号”这个连接字段上建立索引。 \x0d\x0a还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。 \x0d\x0a下面的查询将强迫对orders表执行顺序操作： \x0d\x0aSELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008 \x0d\x0a虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句： \x0d\x0aSELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001 \x0d\x0aUNION \x0d\x0aSELECT ＊ FROM orders WHERE order_num=1008 \x0d\x0a这样就能利用索引路径处理查询。\x0d\x0a5．避免困难的正规表达式\x0d\x0aMATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _” \x0d\x0a即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。 \x0d\x0a另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3] >“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。\x0d\x0a6．使用临时表加速查询\x0d\x0a把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如： \x0d\x0aSELECT cust.name，rcvbles.balance，??other COLUMNS \x0d\x0aFROM cust，rcvbles \x0d\x0aWHERE cust.customer_id = rcvlbes.customer_id \x0d\x0aAND rcvblls.balance>0 \x0d\x0aAND cust.postcode>“98000” \x0d\x0aORDER BY cust.name \x0d\x0a如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序： \x0d\x0aSELECT cust.name，rcvbles.balance，??other COLUMNS \x0d\x0aFROM cust，rcvbles \x0d\x0aWHERE cust.customer_id = rcvlbes.customer_id \x0d\x0aAND rcvblls.balance>;0 \x0d\x0aORDER BY cust.name \x0d\x0aINTO TEMP cust_with_balance \x0d\x0a然后以下面的方式在临时表中查询： \x0d\x0aSELECT ＊ FROM cust_with_balance \x0d\x0aWHERE postcode>“98000” \x0d\x0a临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。 \x0d\x0a注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。\x0d\x0a7．用排序来取代非顺序存取\x0d\x0a非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。
[create_time]2022-11-16 14:49:45[/create_time]2022-12-01 14:49:45[finished_time]1[reply_count]0[alue_good]信必鑫服务平台[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.3b707489.Pzvh_phCV7cMa9W2PNEYAQ.jpg?time=66&tieba_portrait_time=66[avatar]TA获得超过5.2万个赞[slogan]这个人很懒，什么都没留下![intro]202[view_count]
数据库索引怎么建立
right?0?81999-2020,CSDN.NET,AllRightsReserved程序员必备的浏览器插件登录越来越好ing关注数据库索引是什么，有什么用，怎么用转载2018-12-0423:30:365点赞越来越好ing码龄2年关注下面是关于数据库索引的相关知识：简单来说，数据库索引就是数据库的数据结构！进一步说则是该数据结构中存储了一张表中某一列的所有值，也就是说索引是基于数据表中的某一列创建的。总而言之：一个索引是由表中某一列上的数据组成，并且这些数据存储在某个数据结构中。2.索引的作用。举个例子，假设有一张数据表Emplyee，该表有三列：表中有几万条记录。现在要执行下面这条查询语句，查找出所有名字叫“Jesus”的员工的详细信息3.如果没有数据库索引功能，数据库系统会逐行的遍历整张表，对于每一行都要检查其Employee_Name字段是否等于“Jesus”。因为我们要查找所有名字为“Jesus”的员工，所以当我们发现了一条名字是“Jesus”的记录后，并不能停止继续查找，因为可能有其他员工也叫“Jesus”。这就意味着，对于表中的几万条记录，数据库每一条都要检查。这就是所谓的“全表扫描”（fulltablescan）4.而数据库索引功能索引的最大作用就是加快查询速度，它能从根本上减少需要扫表的记录/行的数量。5.如何创建数据库索引。可以基于Employee表的两列创建索引即可：拓展资料：索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。如果想按特定职员的姓来查找他或她，则与在表中搜索所有的行相比，索引有助于更
[create_time]2023-04-26 15:48:39[/create_time]2023-05-11 15:48:39[finished_time]1[reply_count]0[alue_good]猪八戒网[uname]https://pic.rmb.bdstatic.com/c958ab6d003b1ca8df45ae4fa0226ac5.jpeg[avatar]百度认证:重庆猪八戒网络有限公司官方账号[slogan]猪八戒网（zbj.com）创建于2006年，现已形成猪八戒网、天蓬网和线下八戒工场的“双平台+一社区”服务模式，是中国领先的人才共享平台。 [intro]91[view_count]Oracle中的位图索引是什么，怎么用的啊？
1、语法
create bitmap index index_name on 表名(字段);
2、举个例子你就能明白了：
如有表 test(id,name,address)
数据
(1,张三,大连)
(2,李四,天津)
(3,王五,北京)
(4,赵六,大连)
....
类似这样的数据，如果查询的时候用到 【where address='大连'】，因为数据库中有很多这样的数据，所以一般的索引起不到查询加速的作用，而建立位图索引后会产生如下位图效果：
假设有4条数据(就如上所示)
大连 天津 北京
1 0 0
0 1 0
0 0 1
1 0 0
这样当查询：
select * from 表 where address='大连' or address='北京';
的时候数据库很快就能根据 同行的 1和0 判断出那一条数据符合要求。
---
以上，希望对你有所帮助。
[create_time]2017-11-22 11:56:06[/create_time]2009-08-25 22:13:54[finished_time]2[reply_count]150[alue_good]奔驰M888[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.4d20c647.Jb70VzK5Uag1QUZTg5MQrQ.jpg?time=2976&tieba_portrait_time=2976[avatar]TA获得超过1.1万个赞[slogan]这个人很懒，什么都没留下![intro]14792[view_count]
oracle 位图索引的原理
1、语法create bitmap index index_name on 表名(字段);2、举个例子你就能明白了：如有表 test(id,name,address)数据(1,张三,大连)(2,李四,天津)(3,王五,北京)(4,赵六,大连)....类似这样的数据，如果查询的时候用到 ，因为数据库中有很多这样的数据，所以一般的索引起不到查询加速的作用，而建立位图索引后会产生如下位图效果：假设有4条数据(就如上所示)大连 天津 北京 1 0 0 0 1 0 0 0 1 1 0 0这样当查询：select * from 表 where address='大连' or address='北京';的时候数据库很快就能根据 同行的 1和0 判断出那一条数据符合要求。
[create_time]2018-04-12 19:20:23[/create_time]2014-01-13 11:38:20[finished_time]2[reply_count]15[alue_good]heyongjia1999[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.d15c7be6.eQR0uvFntXKP0IFgt9d17A.jpg?time=3900&tieba_portrait_time=3900[avatar]超过18用户采纳过TA的回答[slogan]这个人很懒，什么都没留下![intro]2780[view_count]
Oracle的索引类型
有两大类索引：唯一索引：对于被索引列，索引表中每一行包含一个唯一值；非唯一索引：行中的索引值可重复；从索引中读取数据的操作取决于使用的索引类型和查询中访问索引的方法。对于CTXCAT类型的索引来说，当对基表进行DML操作的时候，Oracle自动维护索引。对文档的改变马上反映到索引中。CTXCAT是事务形的索引。索引的同步在对基表插入，修改，删除之后同步索引。推荐使用sync同步索引。Oracle中的索引包含有如下几种类型：B*树索引：这是Oracle中最常用的索引，它的构造类似于二叉树，能根据键提供一行或一个行集的快速访问，通常只需要很少的读操作就能找到正确的行。在oracle中物理结构不一样。createindexINDEX_NAMEonTABLE_NAME(ACCNO，ZONENO，CINO)会根据ACCNO，ZONENO，CINO生成一个BTree索引树。createindexINDEX_NAMEonTABLE_NAME(ACCNO)。也是比较难于发现的性能问题之一。比如：bdcs_qlr_xz中的zjh是NVARCHAR2类型，在zjh字段上有索引。如果使用下面的语句将执行全表扫描。
[create_time]2023-06-28 18:42:00[/create_time]2023-07-13 18:42:00[finished_time]1[reply_count]0[alue_good]深空游戏[uname]https://pic.rmb.bdstatic.com/bjh/user/7ac05459aa617502be5edd0077a0e373.png[avatar]百度认证:东莞市深空信息咨询官方账号[slogan]这个人很懒，什么都没留下![intro]6[view_count]Oracle的索引类型
最近在写一篇关于oracle索引的论文 在这里就讨论一下索引的分类 逻辑上 Single column 单行索引 Concatenated 多行索引 Unique 唯一索引 NonUnique 非唯一索引 Function based函数索引 Domain 域索引 物理上 Partitioned 分区索引 NonPartitioned 非分区索引 B tree Normal 正常型B树 Rever Key 反转型B树 Bitmap 位图索引 索引结构 B tree 适合与大量的增 删 改（OLTP） 不能用包含OR操作符的查询 适合高基数的列（唯一值多） 典型的树状结构 每个结点都是数据块 大多都是物理上一层 两层或三层不定 逻辑上三层 叶子块数据是排序的 从左向右递增 在分支块和根块中放的是索引的范围 Bitmap: 适合与决策支持系统 做UPDATE代价非常高 非常适合OR操作符的查询 基数比较少的时候才能建位图索引 树型结构 索引头 开始ROWID 结束ROWID（先列出索引的最大范围） BITMAP 每一个BIT对应着一个ROWID 它的值是 还是 如果是 表示著BIT对应的ROWID有值 lishixinzhi/Article/program/Oracle/201311/18675
[create_time]2022-11-07 12:34:40[/create_time]2022-11-17 06:00:54[finished_time]1[reply_count]0[alue_good]大沈他次苹0B[uname]https://himg.bdimg.com/sys/portrait/item/wise.1.268b9e4f._Pqr3QJiDoKzKAJr45bDew.jpg?time=4988&tieba_portrait_time=4988[avatar]TA获得超过6159个赞[slogan]这个人很懒，什么都没留下![intro]13[view_count]
