=======关于索引在应用中的想明确的几个问题，UP给分==========

[imdt]

如下表：
create tabel tab1
( col1 int,
col2 int,
...
col2 ...
)

create tabel tab2
( col1 int,
col2 int,
...
col2 ...
)
我在表tab1的col1列建立了索引

1、索引再连接中对查询的影响，具体来讲就是建立索引字段在连接时的先后顺序；
select a.col1,b.col2
from tab1 a,tab2 b
where a.col1=b.col1
and a.col1=@num;
和
select a.col1,b.col2
from tab1 a,tab2 b
where b.col1=a.col1
and a.col1=@param;
三个问题：
. 这两个查询会有什么不同？
. 两个表是先做连接在过滤数据还是，先过滤数据后建立连接？
. 如果是先连接后过滤数据，该怎么写才可以先过滤数据够建立连接？
2、条件过滤的先后顺序，
select *
from tab1
where col1=@param1
and col2=@patam2
……
and coln=@patamn

请问先执行那个过滤条件？

3、据说表的结构变化时，索引会失效，请问是否属实，该如何重建索引？
4、我怎么能够判定一个索引再查询中被引用？
5、如何在查询中指定使用某个索引！

[imdt]

大家都睡了么！

[meteorlg]

1.没有不同
先做过滤，因为查询分析器会自动优化
2.先做有索引的列

[leimin]

question:
建立2个表，customers,servicecall
--customer(customerID PK)
CustomerID CustomerName Address City State Zip phone
cust1 Customer One 123 Main St. Chicago IL 60601 [phone]
cust2 Customer Two 248 Elm St. Serverville IL 60679 [phone]
cust3 Customer Three 831 First St. Netville IL 60831 [phone]
--servicecall(ServiceCallID PK)
ServiceCallID CustomerID ServiceDate LaborRate Hours Cost
1 cust1 2001-09-14 00:00:00.000 55.0000 3.0 200.0000
2 cust1 2001-09-17 00:00:00.000 55.0000 1.5 70.0000
3 cust1 2001-09-19 00:00:00.000 55.0000 2.0 .0000
4 cust2 2001-09-25 00:00:00.000 60.0000 3.5 180.0000
5 cust3 2001-09-27 00:00:00.000 65.0000 4.5 275.0000
execute:
select * from servicecall a
inner join customers b
on a.customerid=b.customerid
where a.servicecallid=5

select * from servicecall a,customers b
where a.customerid=b.customerid and a.servicecallid=5

三个问题：
. 这两个查询会有什么不同？
从执行规划来看，是一样的。
. 两个表是先做连接在过滤数据还是，先过滤数据后建立连接？
先通过主键过虑数据，在连接。
. 如果是先连接后过滤数据，该怎么写才可以先过滤数据够建立连接？

[leimin]

2、条件过滤的先后顺序，
select *
from tab1
where col1=@param1
and col2=@patam2
……
and coln=@patamn

请问先执行那个过滤条件？
A:首先是根据PK 索引，然后是一般索引。

3、据说表的结构变化时，索引会失效，请问是否属实，该如何重建索引？
A:如果是联合索引，比如CUSTOMERS表的主键是CUSTONERID,CUSTONERNAME,如果CUSTOMERNAME 变化了，要从新建立INDEX,不过对于经常UPDATE,INSERT的表要定期更新INDEX统计，这样可以提高检索的速度。
update_statistics table|view
你也可用SP_AUTOSTATS配置自动更新索引统计
DBCC DBRINDEX('TABLENAME',INDEX_NAME,FILLFACTOR)


4、我怎么能够判定一个索引再查询中被引用？
在执行规划中可以看见。CTRL+L
也可以；
set showplan_all on
go
select * from servicecall a
inner join customers b
on a.customerid=b.customerid
where a.servicecallid=5
go
set showplan_all off

[imdt]

很感谢各位！验证后散分！

[imdt]

在线等待答案！望高手指点！

[welyngj]

3.重建索引
在数据库中创建索引时，查询所使用的索引信息存储在索引页中。连续索引页由从一个页到下一个页的指针链接在一起。当对数据的更改影响到索引时，索引中的信息可能会在数据库中分散开来。重建索引可以重新组织索引数据（对于聚集索引还包括表数据)的存储，清除碎片。这可通过减少获得请求数据所需的页读取数来提高磁盘性能。

在 Microsoft® SQL Server™ 2000 中，如果要用一个步骤重新创建索引，而不想删除旧索引并重新创建同一索引，则使用 CREATE INDEX 语句的 DROP_EXISTING 子句可以提高效率。这一优点既适用于聚集索引也适用于非聚集索引。

以删除旧索引然后重新创建同一索引的方式重建聚集索引，是一种昂贵的方法，因为所有二级索引都使用聚集键指向数据行。如果只是删除聚集索引然后重新创建，则会使所有非聚集索引都被删除和重新创建两次。一旦删除聚集索引并再次重建该索引，就会发生这种情形。通过在一个步骤中重新创建索引，可以避免这一昂贵的做法。在一个步骤中重新创建索引时，会告诉 SQL Server 要重新组织现有索引，避免了删除和重新创建非聚集索引这些不必要的工作。该方法的另一个重要优点是可以使用现有索引中的数据排序次序，从而避免了对数据重新排序。这对于聚集索引和非聚集索引都十分有用，可以显著减少重建索引的成本。另外，通过使用 DBCC DBREINDEX 语句，SQL Server 还允许对一个表重建（在一个步骤中）一个或多个索引，而不必单独重建每个索引。

DBCC DBREINDEX 也可用于重建执行 PRIMARY KEY 或 UNIQUE 约束的索引，而不必删除并创建这些约束（因为对于为执行 PRIMARY KEY 或 UNIQUE 约束而创建的索引，必须先删除该约束，然后才能删除该索引）。例如，可能需要在 PRIMARY KEY 约束上重建一个索引，以便为该索引重建给定的填充因子。


5.不可以自己指定，由查询分析器决定。