加了索引，查询速度为什么还是这么的慢，各位大神求解
[问题点数：40分]
本版专家分：0
CSDN今日推荐
本版专家分：15496
2017年9月 MS-SQL Server大版内专家分月排行榜第二2017年8月 MS-SQL Server大版内专家分月排行榜第二2017年7月 MS-SQL Server大版内专家分月排行榜第二
2017年11月 MS-SQL Server大版内专家分月排行榜第三2017年10月 MS-SQL Server大版内专家分月排行榜第三
本版专家分：12
本版专家分：15496
2017年9月 MS-SQL Server大版内专家分月排行榜第二2017年8月 MS-SQL Server大版内专家分月排行榜第二2017年7月 MS-SQL Server大版内专家分月排行榜第二
2017年11月 MS-SQL Server大版内专家分月排行榜第三2017年10月 MS-SQL Server大版内专家分月排行榜第三
本版专家分：12
本版专家分：12
本版专家分：17
本版专家分：0
匿名用户不能发表回复！|
CSDN今日推荐为什么有些字段索引后反而更加影响查询速度_百度知道
为什么有些字段索引后反而更加影响查询速度
我有更好的答案
因为是记录url其字段值很长，在MySQL数据库里为长字段添加索引后查询速度是有可能变慢的。建议使用前缀索引试一试，看看能否改善。先删除原有的索引，在重新添加前缀索引，例如：alter table tblName drop index old_indexNalter table tblName add index new_indexName(col_url(50));上述语句只对col_url字段的前50个字符设置索引，这样检索的速度会有所提高，您可以尝试50以外的数字看看实用效果，选择一个恰当的数字。
采纳率：89%
来自团队：
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。mysql 加了orderby 查询速度超级慢怎么办
[问题点数：40分]
本版专家分：0
CSDN今日推荐
本版专家分：2856
2016年8月 总版技术专家分月排行榜第二2011年11月 总版技术专家分月排行榜第二
2016年10月优秀大版主2016年8月论坛优秀版主2015年4月优秀版主2014年11月论坛优秀版主
2016年4月 荣获微软MVP称号2015年4月 荣获微软MVP称号2014年4月 荣获微软MVP称号2013年4月 荣获微软MVP称号2009年1月 荣获微软MVP称号2012年4月 荣获微软MVP称号2011年4月 荣获微软MVP称号2010年4月 荣获微软MVP称号
2011年10月 总版技术专家分月排行榜第三
本版专家分：0
本版专家分：0
本版专家分：47
本版专家分：2
2010年12月 挨踢职涯大版内专家分月排行榜第二
本版专家分：15832
2014年2月 总版技术专家分月排行榜第一
2014年1月 总版技术专家分月排行榜第二2013年12月 总版技术专家分月排行榜第二
2016年10月优秀小版主
2014年4月 荣获微软MVP称号
本版专家分：0
本版专家分：0
本版专家分：15832
2014年2月 总版技术专家分月排行榜第一
2014年1月 总版技术专家分月排行榜第二2013年12月 总版技术专家分月排行榜第二
2016年10月优秀小版主
2014年4月 荣获微软MVP称号
匿名用户不能发表回复！|
CSDN今日推荐穷且益坚，不坠青云之志……
【Oracle 11g】为何加了索引反而查询变慢
这里我们探讨数据在磁盘上的物理组织 对索引的开销造成的影响。
一般来讲，主键值彼此接近的行的物理位置也会靠在一起。（表会很自然地按主键顺序聚簇）
在某种情况下，使用这个索引可能很不错，但是在另外一种情况下它却不能很好的工作。从生产系统转储数据并加载到开发系统时，也应该考虑这点。看完了本篇文章的实验，你就能回答这类问题：”为什么在这台机器上运行的完全不同？难道它们不一样吗？“是的，它们确实不一样的，因为数据在磁盘上的物理组织不一样。
本文讨论的是最长用的B*树索引。下图是典型的B*树索引布局
实验一、探究磁盘上的物理组织对索引的影响
本文使用数据库是oracle11g，分析或查询工具是sqlplus。可以看到sqlplus将每一行都查询出来了，所以统计的时间是准确的。如果使用toad或者pl/sql developer这种工具，首次只会返回部分数据，在这种客户端看到的时间是不准确的。
创建一张表
SQL& create
colocated(x int, y varchar2(80));
表已创建。
有插入数据，注意，x是有顺序的。
SQL& begin
for i in 1..100000
insert into colocated(x,y)
values(i, rpad(dbms_random.random, 75, '*'));
然后对表创建主键，主键选择x列
SQL& alter table colocated
add constraint colocated_pk
primary key(x);
表已更改。
这里我们使用oracle标准内置包DBMS_METADATA，查询这个表的定义，可以看到创建的表中有这段（CONSTRAINT “COLOCATED_PK” PRIMARY KEY (“X”)
USING INDEX）， 默认使用我们创建的主键作为索引。
SQL& SET LONG 5000;
SQL& select dbms_metadata.get_ddl('TABLE', 'COLOCATED') FROM DUAL;
DBMS_METADATA.GET_DDL('TABLE','COLOCATED')
CREATE TABLE "SYS"."COLOCATED"
"X" NUMBER(*,0),
"Y" VARCHAR2(80),
CONSTRAINT "COLOCATED_PK" PRIMARY KEY ("X")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DE
FAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM"
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
DBMS_METADATA.GET_DDL('TABLE','COLOCATED')
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DE
FAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM"
统计表的统计信息.（关于如下的函数，可以参考Oracle）
SQL& begin dbms_stats.gather_table_stats(user, 'COLOCATED');
PL/SQL 过程已成功完成。
在创建一张表，数据同表colocated。
SQL& create table disorganized
select x,y
from colocated
表已创建。
SQL& alter table disorganized
add constraint disorganized_pk
primary key(x);
表已更改。
对表colocated进行统计信息收集
SQL& begin dbms_stats.gather_table_stats(user, 'DISORGANIZED');
PL/SQL 过程已成功完成。
第一步，看看有序的物理组织对使用索引进行查询的影响
下面来看看这两个存有相同数据的表的查询性能，打印结果在这里不再展示，只展示查询语句和执行计划以及统计结果。
SQL& set autotrace on;
SQL& set timing on;
SQL& select * from colocated where x between 20000 and 40000;
00: 00: 30.11
Plan hash value:
--------------------------------------------------------------------------------
| Operation
| Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
0 | SELECT STATEMENT
(0)| 00:00:04 |
TABLE ACCESS BY INDEX ROWID| COLOCATED
(0)| 00:00:04 |
INDEX RANGE SCAN
| COLOCATED_PK | 20002 |
(0)| 00:00:01 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("X"&=20000 AND "X"&=40000)
recursive calls
db block gets
consistent gets
physical reads
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
从上可以看到，
consistent gets”获取数据执行了2900次I/O
00: 00: 30.11
第二步，看看无序的物理组织对使用索引进行的查询产生的影响
来看看对照组
SQL& select/*+ index ( disorganized disorganized_pk) */ * from disorganized
where x between 20000 and 40000;
00: 00: 32.04
Plan hash value:
--------------------------------------------------------------------------------
| Operation
| Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
0 | SELECT STATEMENT
1582K| 20039(1)| 00:04:01 |
TABLE ACCESS BY INDEX ROWID| DISORGANIZED
1582K| 20039(1)| 00:04:01 |
INDEX RANGE SCAN
| DISORGANIZED_PK | 20002 |
43(0)| 00:00:01 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("X"&=20000 AND "X"&=40000)
recursive calls
db block gets
consistent gets
physical reads
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
从上可以看到，
consistent gets”获取数据执行了21359次I/O
00: 00: 32.04
SQL& select a.index_name,
b.num_rows,
a.clustering_factor
from user_indexes a, user_tables b
where index_name in ('COLOCATED_PK', 'DISORGANIZED_PK')
and a.table_name = b.table_name
INDEX_NAME
BLOCKS CLUSTERING_FACTOR
COLOCATED_PK
DISORGANIZED_PK
结果分析：
上述两句SQL都走了索引，表中存储的数据都相同，查询的结果集也相同，但是查询时间差别好大。对于物理上共同放置的数据（COLOCATED），查询时间大幅下降。在某种情况下，使用这个索引可能很不错，但是在另外一种情况下它却不能很好的工作。
补充说明：
关于CLUSTERING_FACTOR ，该数值越接近BLOCKS ，则说明rows越有序；
反之，如果该数值越接近NUM_ROWS , 则说明rows越无序。
（This defines how ordered the rows are in the index. If CLUSTERING_FACTOR approaches the number of blocks in the table, the rows are ordered. If it approaches the number of rows in the table, the rows are randomly ordered. In such a case (clustering factor near the number of rows), it is unlikely that index entries in the same leaf block will point to rows in the same data blocks. ）
如何减小CLUSTERING_FACTOR 值呢？解决方法：
1.使用索引组织表(index organized table, IOT)。存储在堆中的表示无组织的，IOT中的数据则是按主键存储和排序。
2.重建该表。
实验二、全表扫描比使用索引更快的例子
再来个测试
SQL& select * from disorganized where x between 20000 and 40000
00: 00: 31.49
Plan hash value:
--------------------------------------------------------------------------------
| Operation
| Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
0 | SELECT STATEMENT
(1)| 00:00:04|
TABLE ACCESS FULL| DISORGANIZED | 20002 |
(1)| 00:00:04 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("X"&=40000 AND "X"&=20000)
recursive calls
db block gets
consistent gets
physical reads
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
这个测试说明在某些情况下，全表扫描快于使用索引查询。
其它补充：
先看看我的数据库中block的大小
------------------------------------ ----------- ------------------------------
可以看到block大小为8k。
下面看看表中每行占用空间大小
SQL& select vsize(x),vsize(y) from colocated where rownum=1;
---------- ----------
可以看到，随机的某一行占用总计77个字节。（number类型占用空间很少是因为其按照有效数字，正负号，小数位来存储的。所以有效数字越多，占用空间越大）
所以，可以看到，每个块（block）中可以存储多行数据。所以，如果数组是随机存储的，那么如果通过索引访问，则很多块会被重复读取，导致访问变慢。
block是oracle中最小的逻辑存储单元。如图（引用自）
本文参考《Oracle_Database_9i10g11g编程艺术深入数据库体系结构》第2版，Thomas Kyte著，苏金国 王小振等译，327~405页。
没有更多推荐了，请帮忙优化一下SQL，查询速度相当慢，每个查询字段都已经建立索引了，可是还是不行。
[问题点数：50分，结帖人eddie_520]
本版专家分：0
结帖率 83.33%
CSDN今日推荐
本版专家分：1479
本版专家分：0
结帖率 83.33%
本版专家分：89
本版专家分：1046
本版专家分：135
本版专家分：135
本版专家分：28988
2017年2月 Oracle大版内专家分月排行榜第二2003年10月 PowerBuilder大版内专家分月排行榜第二
2017年6月 Oracle大版内专家分月排行榜第三2017年3月 Oracle大版内专家分月排行榜第三2006年12月 Oracle大版内专家分月排行榜第三
匿名用户不能发表回复！|
CSDN今日推荐