为何我的查询速度这么慢? 在线,急.............. 如何做索引?我的表里有一个字段custID被设为主键的. 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 DBCC INDEXDEFRAG整理指定的表或视图的聚集索引和辅助索引碎片。语法DBCC INDEXDEFRAG ( { database_name | database_id | 0 } , { table_name | table_id | 'view_name' | view_id } , { index_name | index_id } ) [ WITH NO_INFOMSGS ] 你的主键就是索引呀，用dbcc indexdefrag 命令来整理一下索引碎片 我运行了 DBCC DBREINDEX('customer')后好象快了不少, 这个DBCC DBREINDEX('customer')到底是起到了什么作用? DBCC DBREINDEX重建指定数据库中表的一个或多个索引。语法DBCC DBREINDEX ( [ 'database.owner.table_name' [ , index_name [ , fillfactor ] ] ] ) [ WITH NO_INFOMSGS ]参数'database.owner.table_name'是要重建其指定的索引的表名。数据库、所有者和表名必须符合标识符的规则。有关更多信息，请参见使用标识符。如果提供 database 或 owner 部分，则必须使用单引号 (') 将整个 database.owner.table_name 括起来。如果只指定 table_name，则不需要单引号。index_name是要重建的索引名。索引名必须符合标识符的规则。如果未指定 index_name 或指定为 ' '，就要对表的所有索引进行重建。fillfactor是创建索引时每个索引页上要用于存储数据的空间百分比。fillfactor 替换起始填充因子以作为索引或任何其它重建的非聚集索引（因为已重建聚集索引）的新默认值。如果 fillfactor 为 0，DBCC DBREINDEX 在创建索引时将使用指定的起始 fillfactor。WITH NO_INFOMSGS禁止显示所有信息性消息（具有从 0 到 10 的严重级别）。注释DBCC DBREINDEX 重建表的索引或为表定义的所有索引。通过允许动态重建索引，可以重建强制 PRIMARY KEY 或 UNIQUE 约束的索引，而不必除去并重新创建这些约束。这意味着不必知道表的结构或约束就可以重建索引，将数据大容量复制到表中后就会出现这种情况。 如果指定 index_name 或 fillfactor，还必须指定以前所有的参数。DBCC DBREINDEX 可以使用一条语句重建表的所有索引，这比对多个 DROP INDEX 和 CREATE INDEX 语句进行编码容易。由于该工作是通过一条语句完成的，所以 DBCC DBREINDEX 自动为原子性，而单个 DROP INDEX 和 CREATE INDEX 语句要成为原子性则必须放在事务中。另外，与使用单个 DROP INDEX 和 CREATE INDEX 语句相比，DBCC DBREINDEX 可从 DBCC DBREINDEX 的优化性能中更多地获益。不支持在系统表上使用 DBCC DBREINDEX。 结果集不管是否指定任何选项（ NO_INFOMSGS 除外），DBCC DBREINDEX 返回以下结果集；下例使用 pubs 数据库的 authors 表（值可能会有变化）：Index (ID = 1) is being rebuilt.Index (ID = 2) is being rebuilt.DBCC execution completed. If DBCC printed error messages, contact your system administrator.如果指定 NO_INFOMSGS 选项，DBCC DBREINDEX 将返回以下结果集（消息）：DBCC execution completed. If DBCC printed error messages, contact your system administrator.权限DBCC DBREINDEX 权限默认授予表所有者、sysadmin 固定服务器角色或 db_owner 和 db_ddladmin 固定数据库角色的成员且不可转让。示例A. 重建某个索引下例使用填充因子 80 重建 pubs 数据库中 authors 表上的 au_nmind 聚集索引。DBCC DBREINDEX ('pubs.dbo.authors', UPKCL_auidind, 80)B. 重建所有索引下例使用填充因子值 70 重建 authors 表上的所有索引。DBCC DBREINDEX (authors, '', 70) 重建索引在数据库中创建索引时，查询所使用的索引信息存储在索引页中。连续索引页由从一个页到下一个页的指针链接在一起。当对数据的更改影响到索引时，索引中的信息可能会在数据库中分散开来。重建索引可以重新组织索引数据（对于聚集索引还包括表数据)的存储，清除碎片。这可通过减少获得请求数据所需的页读取数来提高磁盘性能。在 Microsoft® SQL Server™ 2000 中，如果要用一个步骤重新创建索引，而不想删除旧索引并重新创建同一索引，则使用 CREATE INDEX 语句的 DROP_EXISTING 子句可以提高效率。这一优点既适用于聚集索引也适用于非聚集索引。以删除旧索引然后重新创建同一索引的方式重建聚集索引，是一种昂贵的方法，因为所有二级索引都使用聚集键指向数据行。如果只是删除聚集索引然后重新创建，则会使所有非聚集索引都被删除和重新创建两次。一旦删除聚集索引并再次重建该索引，就会发生这种情形。通过在一个步骤中重新创建索引，可以避免这一昂贵的做法。在一个步骤中重新创建索引时，会告诉 SQL Server 要重新组织现有索引，避免了删除和重新创建非聚集索引这些不必要的工作。该方法的另一个重要优点是可以使用现有索引中的数据排序次序，从而避免了对数据重新排序。这对于聚集索引和非聚集索引都十分有用，可以显著减少重建索引的成本。另外，通过使用 DBCC DBREINDEX 语句，SQL Server 还允许对一个表重建（在一个步骤中）一个或多个索引，而不必单独重建每个索引。DBCC DBREINDEX 也可用于重建执行 PRIMARY KEY 或 UNIQUE 约束的索引，而不必删除并创建这些约束（因为对于为执行 PRIMARY KEY 或 UNIQUE 约束而创建的索引，必须先删除该约束，然后才能删除该索引）。例如，可能需要在 PRIMARY KEY 约束上重建一个索引，以便为该索引重建给定的填充因子。 如果从建表开始就建立了主键，如何在20000条记录时就绪要DBCC，来整理索引， yesterdaycsdn(梦到内河) 现在查询需要多少秒？ 我的主键custID建立完索引的填充因子值为0, 是不是这个有影响?如果为70是不是会快很多?还有,是不是DBCC DBREINDEX('customer')这样一次,以后都会快了? 为0，有点悬乎，这样，需要存储索引的块就要N多吧，速度当然有影响。索引块之所以有碎片和是因为对表的操作，如经常update/insert/delete，所以你重建了索引以后还会要重建，除非不再进行update/insert/delete操作，可行的办法是做一个数据库维护计划。 zheninchangjiang(徐震),你好,一般你建主键索引的填充因子值为多少较好呢? 常叫客户每天都DBCC DBREINDEX('customer')一次,客户会觉不烦呵,点算好? 不用那样做，我自己对于数据库是做了个维护计划，在维护计划中：备份作业每天执行一次索引等优化作业，每星期执行一次建维护计划：在企业管理器中：右击想建计划的数据库-->所有任务-->维护计划...建好后，在管理-->SQLSERVER代理中找到新建的作业,设置一下调度来满足维护周期的需要 填充因子在创建聚集索引时，表中的数据按照索引列中的值的顺序存储在数据库的数据页中。在表中插入新的数据行或更改索引列中的值时，Microsoft® SQL Server™ 2000 可能必须重新组织表中的数据存储，以便为新行腾出空间，保持数据的有序存储。这同样适用于非聚集索引。添加或更改数据时，SQL Server 可能不得不重新组织非聚集索引页中的数据存储。向一个已满的索引页添加某个新行时，SQL Server 把大约一半的行移到新页中以便为新行腾出空间。这种重组称为页拆分。页拆分会降低性能并使表中的数据存储产生碎片。有关更多信息，请参见表和索引构架。创建索引时，可以指定一个填充因子，以便在索引的每个叶级页上留出额外的间隙和保留一定百分比的空间，供将来表的数据存储容量进行扩充和减少页拆分的可能性。填充因子的值是从 0 到 100 的百分比数值，指定在创建索引后对数据页的填充比例。值为 100 时表示页将填满，所留出的存储空间量最小。只有当不会对数据进行更改时（例如，在只读表中）才会使用此设置。值越小则数据页上的空闲空间越大，这样可以减少在索引增长过程中对数据页进行拆分的需要，但需要更多的存储空间。当表中数据会发生更改时，这种设置更为适当。提供填充因子选项是为了对性能进行微调。但是，使用 sp_configure 系统存储过程指定的服务器范围的默认填充因子，在大多数情况下都是最佳的选择。 说明 即使对于一个面向许多插入和更新操作的应用程序来说，数据库读取次数一般也超过数据库写入次数的 5 到 10 倍。因此，指定一个不同于默认设置的填充因子会降低数据库的读取性能，而降低量与填充因子设置值成反比。例如，当填充因子的值为 50% 时，数据库的读取性能会降低两倍。只有当在表中根据现有数据创建新索引，并且可以精确预见将来会对这些数据进行哪些更改时，将填充因子选项设置为另一个值才有用。填充因子只在创建索引时执行；索引创建后，当表中进行数据的添加、删除或更新时，不会保持填充因子。如果试图在数据页上保持额外的空间，则将有背于使用填充因子的本意，因为随着数据的输入，SQL Server 必须在每个页上进行页拆分，以保持填充因子指定的空闲空间百分比。因此，如果表中的数据进行了较大的变动，添加了新数据，可以填充数据页的空闲空间。在这种情况下，可以重新创建索引，重新指定填充因子，以重新分布数据。--一般我不改，就用数据库默认的，你可以根据读写的比率来定一下 呵呵，那你就用 fill factor 来更改一下 时间的转化 求一条SQL语句 在同一表内更新一列的数据 求一sql 语句 numeric 和 decimal 数据类型有什么区别 有關OPENROWSET,如何識別用tab分開的txt文件,並分出各個字段 如何写个存储过程实现这样的效果？ sql 基本问题：如何 创建和删除数据库。 SQL同时查询两个表，出现了重复的数据，请问如何解决？ 菜鸟提问 ，(ado) 怎样删除SQL SERVER 中的记录 ， 我的代码如下.... 全文检索 同一个表中字段更新,如何写触发器,谢谢 菜鸟关于插入命令的用法？
整理指定的表或视图的聚集索引和辅助索引碎片。语法
DBCC INDEXDEFRAG
( { database_name | database_id | 0 }
, { table_name | table_id | 'view_name' | view_id }
, { index_name | index_id }
) [ WITH NO_INFOMSGS ]
用dbcc indexdefrag 命令来整理一下索引碎片
重建指定数据库中表的一个或多个索引。语法
DBCC DBREINDEX
( [ 'database.owner.table_name'
[ , index_name
[ , fillfactor ]
]
]
) [ WITH NO_INFOMSGS ]参数
'database.owner.table_name'是要重建其指定的索引的表名。数据库、所有者和表名必须符合标识符的规则。有关更多信息，请参见使用标识符。如果提供 database 或 owner 部分，则必须使用单引号 (') 将整个 database.owner.table_name 括起来。如果只指定 table_name，则不需要单引号。index_name是要重建的索引名。索引名必须符合标识符的规则。如果未指定 index_name 或指定为 ' '，就要对表的所有索引进行重建。fillfactor是创建索引时每个索引页上要用于存储数据的空间百分比。fillfactor 替换起始填充因子以作为索引或任何其它重建的非聚集索引（因为已重建聚集索引）的新默认值。如果 fillfactor 为 0，DBCC DBREINDEX 在创建索引时将使用指定的起始 fillfactor。WITH NO_INFOMSGS禁止显示所有信息性消息（具有从 0 到 10 的严重级别）。注释
DBCC DBREINDEX 重建表的索引或为表定义的所有索引。通过允许动态重建索引，可以重建强制 PRIMARY KEY 或 UNIQUE 约束的索引，而不必除去并重新创建这些约束。这意味着不必知道表的结构或约束就可以重建索引，将数据大容量复制到表中后就会出现这种情况。 如果指定 index_name 或 fillfactor，还必须指定以前所有的参数。DBCC DBREINDEX 可以使用一条语句重建表的所有索引，这比对多个 DROP INDEX 和 CREATE INDEX 语句进行编码容易。由于该工作是通过一条语句完成的，所以 DBCC DBREINDEX 自动为原子性，而单个 DROP INDEX 和 CREATE INDEX 语句要成为原子性则必须放在事务中。另外，与使用单个 DROP INDEX 和 CREATE INDEX 语句相比，DBCC DBREINDEX 可从 DBCC DBREINDEX 的优化性能中更多地获益。不支持在系统表上使用 DBCC DBREINDEX。 结果集
不管是否指定任何选项（ NO_INFOMSGS 除外），DBCC DBREINDEX 返回以下结果集；下例使用 pubs 数据库的 authors 表（值可能会有变化）：Index (ID = 1) is being rebuilt.
Index (ID = 2) is being rebuilt.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.如果指定 NO_INFOMSGS 选项，DBCC DBREINDEX 将返回以下结果集（消息）：DBCC execution completed. If DBCC printed error messages, contact your system administrator.权限
DBCC DBREINDEX 权限默认授予表所有者、sysadmin 固定服务器角色或 db_owner 和 db_ddladmin 固定数据库角色的成员且不可转让。示例
A. 重建某个索引
下例使用填充因子 80 重建 pubs 数据库中 authors 表上的 au_nmind 聚集索引。DBCC DBREINDEX ('pubs.dbo.authors', UPKCL_auidind, 80)B. 重建所有索引
下例使用填充因子值 70 重建 authors 表上的所有索引。DBCC DBREINDEX (authors, '', 70)
在数据库中创建索引时，查询所使用的索引信息存储在索引页中。连续索引页由从一个页到下一个页的指针链接在一起。当对数据的更改影响到索引时，索引中的信息可能会在数据库中分散开来。重建索引可以重新组织索引数据（对于聚集索引还包括表数据)的存储，清除碎片。这可通过减少获得请求数据所需的页读取数来提高磁盘性能。在 Microsoft® SQL Server™ 2000 中，如果要用一个步骤重新创建索引，而不想删除旧索引并重新创建同一索引，则使用 CREATE INDEX 语句的 DROP_EXISTING 子句可以提高效率。这一优点既适用于聚集索引也适用于非聚集索引。以删除旧索引然后重新创建同一索引的方式重建聚集索引，是一种昂贵的方法，因为所有二级索引都使用聚集键指向数据行。如果只是删除聚集索引然后重新创建，则会使所有非聚集索引都被删除和重新创建两次。一旦删除聚集索引并再次重建该索引，就会发生这种情形。通过在一个步骤中重新创建索引，可以避免这一昂贵的做法。在一个步骤中重新创建索引时，会告诉 SQL Server 要重新组织现有索引，避免了删除和重新创建非聚集索引这些不必要的工作。该方法的另一个重要优点是可以使用现有索引中的数据排序次序，从而避免了对数据重新排序。这对于聚集索引和非聚集索引都十分有用，可以显著减少重建索引的成本。另外，通过使用 DBCC DBREINDEX 语句，SQL Server 还允许对一个表重建（在一个步骤中）一个或多个索引，而不必单独重建每个索引。DBCC DBREINDEX 也可用于重建执行 PRIMARY KEY 或 UNIQUE 约束的索引，而不必删除并创建这些约束（因为对于为执行 PRIMARY KEY 或 UNIQUE 约束而创建的索引，必须先删除该约束，然后才能删除该索引）。例如，可能需要在 PRIMARY KEY 约束上重建一个索引，以便为该索引重建给定的填充因子。
yesterdaycsdn(梦到内河) 现在查询需要多少秒？
索引块之所以有碎片和是因为对表的操作，如经常update/insert/delete，所以你重建了索引以后还会要重建，除非不再进行update/insert/delete操作，可行的办法是做一个数据库维护计划。
常叫客户每天都DBCC DBREINDEX('customer')一次,客户会觉不烦呵,点算好?
备份作业每天执行一次
索引等优化作业，每星期执行一次建维护计划：
在企业管理器中：右击想建计划的数据库-->所有任务-->维护计划...建好后，在管理-->SQLSERVER代理中找到新建的作业,设置一下调度来满足维护周期的需要
在创建聚集索引时，表中的数据按照索引列中的值的顺序存储在数据库的数据页中。在表中插入新的数据行或更改索引列中的值时，Microsoft® SQL Server™ 2000 可能必须重新组织表中的数据存储，以便为新行腾出空间，保持数据的有序存储。这同样适用于非聚集索引。添加或更改数据时，SQL Server 可能不得不重新组织非聚集索引页中的数据存储。向一个已满的索引页添加某个新行时，SQL Server 把大约一半的行移到新页中以便为新行腾出空间。这种重组称为页拆分。页拆分会降低性能并使表中的数据存储产生碎片。有关更多信息，请参见表和索引构架。创建索引时，可以指定一个填充因子，以便在索引的每个叶级页上留出额外的间隙和保留一定百分比的空间，供将来表的数据存储容量进行扩充和减少页拆分的可能性。填充因子的值是从 0 到 100 的百分比数值，指定在创建索引后对数据页的填充比例。值为 100 时表示页将填满，所留出的存储空间量最小。只有当不会对数据进行更改时（例如，在只读表中）才会使用此设置。值越小则数据页上的空闲空间越大，这样可以减少在索引增长过程中对数据页进行拆分的需要，但需要更多的存储空间。当表中数据会发生更改时，这种设置更为适当。提供填充因子选项是为了对性能进行微调。但是，使用 sp_configure 系统存储过程指定的服务器范围的默认填充因子，在大多数情况下都是最佳的选择。 说明 即使对于一个面向许多插入和更新操作的应用程序来说，数据库读取次数一般也超过数据库写入次数的 5 到 10 倍。因此，指定一个不同于默认设置的填充因子会降低数据库的读取性能，而降低量与填充因子设置值成反比。例如，当填充因子的值为 50% 时，数据库的读取性能会降低两倍。
只有当在表中根据现有数据创建新索引，并且可以精确预见将来会对这些数据进行哪些更改时，将填充因子选项设置为另一个值才有用。填充因子只在创建索引时执行；索引创建后，当表中进行数据的添加、删除或更新时，不会保持填充因子。如果试图在数据页上保持额外的空间，则将有背于使用填充因子的本意，因为随着数据的输入，SQL Server 必须在每个页上进行页拆分，以保持填充因子指定的空闲空间百分比。因此，如果表中的数据进行了较大的变动，添加了新数据，可以填充数据页的空闲空间。在这种情况下，可以重新创建索引，重新指定填充因子，以重新分布数据。
--一般我不改，就用数据库默认的，你可以根据读写的比率来定一下