提高查询性能-T-SQL

我有一个表，它已经按列“datetime”排序。因为当它被插入时，我存储UTC日期，所以它被订购。这是一张非常拥挤的桌子。因此，如果可能的话，我正在努力提高查询性能

---

当我使用某物

WHERE columnDateTime>dateToSearch

时，返回行的时间太长。由于我的表已按

columnDateTime

排序，我可以做些什么来提高查询性能。例如，当一个表按

cod

排序，您尝试搜索

cod>40

T-SQL优化将在找到cod=41时停止搜索，并返回表的其余部分，因为它知道该表是按该索引排序的。这是不是可以告诉T-SQL，我的表也已经按

columnDateTime

排序了

按顺序插入数据并不意味着它按顺序保存。不需要太过技术化，也不需要更快的性能：

• 在该列上创建一个聚集索引。这要求表上没有其他聚集索引，并且没有

  主键

  （或者它有

  非聚集

  ，这不是默认值）。使用聚集索引，当使用

  >datetimeValue

  进行筛选时，引擎将执行索引扫描（而不是完整的表扫描），并且不需要访问数据的传统页面，因为聚集索引离开就是数据

• 在该列上创建一个

  非聚集索引。此子句没有限制（至少在这种情况下是这样），但是对于与筛选日期的每个匹配，引擎将需要访问另一个包含请求列的页面，除非在创建索引时
  包含这些列。请记住，包含的列将增大索引的大小，并且需要额外的维护任务，例如，修改包含的列时
  

除此之外，您应该检查您的查询计划；如果您有连接、函数调用或其他条件，SQL引擎可能不会使用索引，即使它们存在。有很多事情可能会使查询运行缓慢，您必须发布完整的查询执行计划（作为开始）以检查详细信息

您可以使用此查询检查表是否已具有索引：

DECLARE @table_name VARCHAR(200) = 'YourTableName'

SELECT
     SchemaName = SCHEMA_NAME(t.schema_id),
     TableName = t.name,
     IndexName = ind.name,
     IndexType = CASE ind.index_id WHEN 0 THEN 'Heap' WHEN 1 THEN 'Clustered' ELSE 'Nonclustered' END,
     Disabled = ind.is_disabled,
     ColumnOrder = ic.index_column_id,
     ColumnName = col.name,
     ColumnType = y.name,
     ColumnLength = y.max_length,
     ColumnIncluded = ic.is_included_column
FROM 
    sys.indexes ind
    INNER JOIN sys.index_columns ic ON  ind.object_id = ic.object_id and ind.index_id = ic.index_id 
    INNER JOIN sys.columns col ON ic.object_id = col.object_id and ic.column_id = col.column_id 
    INNER JOIN sys.tables t ON ind.object_id = t.object_id 
    INNER JOIN sys.types y ON y.user_type_id = col.user_type_id
WHERE 
     t.is_ms_shipped = 0 AND
     t.name = @table_name
ORDER BY
    SchemaName,
    t.name, 
    ind.name, 
    ic.index_column_id 

---

您需要确保至少有一个索引包含

datetimeColumn

，且

ColumnOrder=1

未禁用。如果它已经存在，那么您的问题就在其他地方，如果没有更多详细信息，我们将无法提供更多帮助。

（1）您使用的是

mysql

还是

SQL Server

T-SQL

是Microsoft版本的SQL。（2） 在关系数据库中，“表按…排序”的概念并不准确。这些表没有并且根本无法排序。但是，它们确实有索引。在考虑性能时，了解所有索引的确切细节非常重要。（3） 你的问题太模糊，无法回答：“太长”是多长？说“人口稠密”毫无意义！（4） 确切的问题很重要！读取：@RafaelAndrade数据在关系数据库中不是“有序的”。它仅由查询中的ORDER by子句进行排序。如果是SQL Server，则可以通过聚集键/聚集索引进行逻辑（而不是物理）排序，尽管与所有性能转换一样，需要使用-query+schema+query plan提供指导。如果没有聚集索引，则表是一个堆，虽然您可能认为存在基于插入的顺序，但SQL Server无法依赖该顺序。如果您严格按时间顺序插入行，并且该列从未更新，并且大多数查询都会在其上进行过滤，则它是一个很好的候选列（非唯一）聚集索引。当然，您也可以在其上创建一个常规索引。如果没有索引，SQL Server只生成有关列中值分布的统计信息——这些是一些帮助，但没有适当的索引那么多。它不能利用您认为存在的任何顺序，因为它不能保证存在顺序。@AnthonyHancock M在你声称我告诉人们“不正确的信息”之前，你应该确保你正确理解聚集索引的概念？聚集索引仍然将数据无序地分散在磁盘上的各个页面中，并且可以使用聚集索引以特定顺序检索数据。优化者根据查询、索引和表统计信息决定是否以这种方式使用聚集索引。