超过百万条数据的表怎样提高查询速度？解决方法

超过百万条数据的表怎样提高查询速度？
数据库是SQL Server 2005。
表结构很简单，id、username、password、email共四列，id自增，主键。
数据共640万行多一点（是什么数据大家都知道哈）。

现在执行select * from table1 where username='username'这条查询语句需要耗时15s，有什么办法能将此查询时间降到1s之内？

切实可行的，经测试满足要求的回复，本人将再开帖给1000分。（PS：只给第一个，因为我只有1000分。）

------解决方案--------------------
username 列创建索引.
------解决方案--------------------
利用索引覆盖试试
create index tset on tb(username) include(id,password,email)
------解决方案--------------------
可以保留ID，还是让其自增，但是将 username设置成聚集索引。我觉得ID在这里没有用或者说是鸡肋。这样的表多数时候会用USERNAME作为查询条件，不会用ID作为查询条件。
------解决方案--------------------
username 可能有重复数据，你先删了，确定唯一

然后在username 上面建立主键，可能会超时

解决方法打开 SQL Server Management Studio，工具--->选项---->查询执行--->执行超时值。

然后收缩数据库

然后你在执行你的语句一到两秒可以搞定

楼主这全套服务，你不给100也得给80吧

------解决方案--------------------

SQL code

create index ix_id on tb(id)
create index ix_username on tb(username)
--加上 上面两个索引,你会发现可以实现的.

------解决方案--------------------
如果这个字段有频繁的Insert update操作，那不建议设置为聚集索引

探讨

进一步还可以试试把主键设置成非聚集索引,而将 username 列设置为聚集索引.

------解决方案--------------------

探讨

引用:

哪有在名称上建聚集索引的，一般都是用ID查找，用名称查应该只是偶尔用用。ID上建聚集索引没啥错。


你去翻翻"sql server 2005 高级管理"那本书,人家上面说,在类似于 id 之类的列上建聚集索引是没有太大意义的,因为它并不代表对象的什么属性,对查询毫无帮助,聚集索引应该建在数据繁杂,且使用又频繁的列上.