Questions tagged «index-tuning»

假设我有一个包含字段A和的表格B。我在A+ 上进行常规查询B，因此在上创建了一个复合索引(A,B)。A组合索引还会仅对查询进行完全优化吗？ 此外，我在上创建了索引A，但Postgres仍然仅在上将复合索引用于查询A。如果前面的答案是肯定的，那么我认为这并不重要，但是如果单个A索引可用，为什么默认情况下为什么要选择复合索引呢？

86 postgresql  database-design  performance  index  index-tuning 

过去一周，我一直在做MS10775A课程，但培训师无法可靠回答的一个问题是： 重新索引会更新统计信息吗？ 我们在网上找到了讨论它是否可行的讨论。

43 sql-server  index  sql-server-2012  index-tuning  statistics 

这个问题是关于SQL Server索引技术的有效性的。我认为它被称为“索引交集”。 我正在使用一个存在许多性能和稳定性问题的现有SQL Server（2008）应用程序。开发人员对索引做了一些奇怪的事情。我无法获得有关这些问题的最终基准，也无法在互联网上找到任何非常好的文档。 表格上有许多可搜索的列。开发人员在可搜索列的每个EACH上创建了一个列索引。从理论上讲，SQL Server在大多数情况下将能够组合（相交）这些索引中的每一个以有效地访问表。这是一个简化的示例（实际表具有更多字段）： CREATE TABLE [dbo].[FatTable]( [id] [bigint] IDENTITY(1,1) NOT NULL, [col1] [nchar](12) NOT NULL, [col2] [int] NOT NULL, [col3] [varchar](2000) NOT NULL, ... CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable] ( [col1] ASC ) CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC ) select * from …

35 sql-server  sql-server-2008  index-tuning 

有没有一种方法可以找出了解为表创建哪些索引的最佳方法？

33 postgresql  database-design  index-tuning 

SQL Server如何确定其对查询计划的缺失索引建议中的关键列的顺序？

32 sql-server  query-performance  index-tuning 

我有一个带有多列索引的表，并且我对正确排序索引以在查询中获得最大性能存有疑问。 场景： PostgreSQL 8.4，具有约一百万行的表 c1列中的值可以有大约100个不同的值。我们可以假设这些值是均匀分布的，因此每个可能的值都有大约10000行。 列c2可以具有1000个不同的值。每个可能的值都有1000行。 搜索数据时，条件始终包含这两列的值，因此该表具有包含c1和c2的多列索引。如果您仅使用一列进行过滤的查询，我已经读到了正确排序多列索引中的列的重要性。在我们的方案中情况并非如此。 我的问题是这个： 考虑到一个过滤器选择的数据要少得多的事实，如果第一个索引的选择性最强（允许使用较小的数据集），我是否可以提高性能？在看到引用的文章中的图形之前，我从未考虑过这个问题： 引用的文章中有关多列索引的图像。 查询使用两列中的值进行过滤。我没有只使用一列进行过滤的查询。它们都是：WHERE c1=@ParameterA AND c2=@ParameterB。也有类似这样的条件：WHERE c1 = "abc" AND c2 LIKE "ab%"

31 postgresql  index  index-tuning 

时不时地运行Microsoft SQL Server Profiler，它建议我创建一系列新的索引和统计信息（“ ... 97％的预期改进...”）。 据我了解，每个增加的索引都可以使SQL SELECT查询更快，但由于必须调整索引，因此SQL UPDATE或SQL 查询的速度也会INSERT变慢。 我想知道的是，什么时候会有“太多”的索引/统计信息？ 也许对此没有明确的答案，但有一些经验法则。

26 sql-server  performance  index  index-tuning 

我正在使用PostgreSQL（9.4）数据库在Ruby on Rails中开发应用程序。在我的用例中，表中的列将被非常频繁地查找，因为应用程序的重点是在模型上搜索非常特定的属性。 我目前正在决定是使用一种integer类型还是只使用典型的字符串类型（例如character varying(255)，Rails中的默认字符串类型）作为列，因为我不确定索引的性能会有什么不同。 这些列是枚举。对于具有的可能值的数量，它们具有固定的大小。大多数枚举长度不超过5，这意味着该索引在应用程序的整个生命周期中或多或少是固定的；因此，整数和字符串索引的节点数将相同。 但是，将被索引的字符串可能长约20个字符，这在内存中大约是整数的5倍（如果整数是4个字节，并且字符串是每个字符1个字节的纯ASCII，则成立）。我不知道数据库引擎怎么做索引查找窗口，但如果它需要“扫描”的字符，直到它匹配准确，那么在本质上这意味着该字符串查找就超过5倍的整数查找速度较慢; 直到匹配整数查找为止的“扫描”将是4个字节而不是20个字节。这就是我的想象： 查找值为（整数）4： 正在扫描.........................找到| 正在获取记录... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | BYTE_8 | ... | 查找值是（字符串）“ some_val”（8个字节）： 扫描................................................. ....................................发现| 正在获取记录... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | …

26 postgresql  index  query-performance  index-tuning  postgresql-performance 

我正在一个需要大量选择查询的报表系统上工作，但是该报表系统基于仅填充一次的数据库。数据库管理系统是Microsoft SQL Server2017。可能有更好的方法来设计这样的系统，但让我们从理论上解决这个问题。 从理论上讲： 如果我们有一个非常大的数据库（几张表上有1.5亿行） 我们可以假设数据库只会被填充一次。 索引每个可能的列组合是否会对选择查询产生负面的性能影响？

23 sql-server  t-sql  index-tuning  sql-server-2017 

对于具有标识列的表，是否应为标识列创建聚集或非聚集的PK /唯一索引？ 原因是将为查询创建其他索引。使用非聚集索引（在堆上）并返回该索引未覆盖的列的查询将使用较少的逻辑I / O（LIO），因为没有额外的聚集索引b树查找步骤？ create table T ( Id int identity(1,1) primary key, -- clustered or non-clustered? (surrogate key, may be used to join another table) A .... -- A, B, C have mixed data type of int, date, varchar, float, money, .... B .... C .... ....) create …

19 sql-server  index-tuning  performance-tuning  database-internals  heap 

简而言之 ，查询优化器选择索引视图索引时会考虑哪些因素？ 对我来说，索引视图似乎无视我对Optimizer如何选择索引的理解。我以前看过这个问题，但是OP不太受欢迎。 我确实在寻找路标，但是我将伪造一个伪示例，然后发布带有大量DDL，输出和示例的真实示例。 假设我使用的是Enterprise 2008+，请理解 with(noexpand) 伪示例 以这个伪示例为例：我创建一个具有22个联接，17个过滤器和一个马戏团小马的视图，该马戏小马穿过一千万个行表。这种观点很昂贵（是的，用大写字母E）可以实现。我将对SCHEMABIND进行索引并为视图建立索引。然后一个 SELECT a,b FROM AnIndexedView WHERE theClusterKeyField < 84。在Optimizer逻辑中，我无法进行底层联接。 结果： 没有提示：4825读取720行，在76ms内读取47 cpu，估计的子树开销为0.30523。 使用提示：17次读取，720行，4 ms内15 cpu，估计的子树成本为0.007253 那么这是怎么回事？我已经在Enterprise 2008、2008-R2和2012中进行了尝试。通过每一个度量标准，我都认为使用视图索引的效率大大提高。我没有参数嗅探问题或数据偏斜，因为这是广告问题。 一个真实（长）的例子 除非您是一个受虐狂，否则您可能不需要或不想阅读此部分。 是的 ，企业版。 Microsoft SQL Server 2012-11.0.2100.60（X64）2012年2月10日19:39:15版权所有（c）Windows NT 6.2（Build 9200：）上的Microsoft Corporation Enterprise Edition（64位）（Hypervisor） 风景 CREATE VIEW dbo.TimelineMaterialized WITH SCHEMABINDING AS SELECT TM.TimelineID, TM.TimelineTypeID, TM.EmployeeID, …

19 sql-server  index-tuning  clustered-index  materialized-view 

假设我们有一个这样的表定义： CREATE TABLE MyTab ( ID INT IDENTITY(1,1) CONSTRAINT PK_MyTab_ID PRIMARY KEY ,GroupByColumn NVARCHAR(10) NOT NULL ,WhereColumn DATETIME NULL ) 和一个过滤的非聚集索引，如下所示： CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn ON MyTab (GroupByColumn) WHERE (WhereColumn IS NULL) 为什么此索引未针对此查询“覆盖”： SELECT GroupByColumn ,COUNT(*) FROM MyTab WHERE WhereColumn IS NULL GROUP BY GroupByColumn 我正在得到这个执行计划： KeyLookup用于WhereColumn IS NULL谓词。 这是计划：https …

18 sql-server  query-performance  index-tuning  filtered-index 

我正在针对以下情况寻求有关表/索引设计的建议： 我有一个大表（股价历史数据，InnoDB，3500万行，并且还在不断增长），它具有复合主键（资产（整数），日期（日期））。除了定价信息外，我还有200个双精度值需要与每个记录相对应。 CREATE TABLE `mytable` ( `assetid` int(11) NOT NULL, `date` date NOT NULL, `close` double NOT NULL, `f1` double DEFAULT NULL, `f2` double DEFAULT NULL, `f3` double DEFAULT NULL, `f4` double DEFAULT NULL, ... skip a few … `f200` double DEFAULT NULL, PRIMARY KEY (`assetid`, `date`)) ENGINE=`InnoDB` DEFAULT CHARACTER …

17 database-design  mysql-5.5  partitioning  index-tuning 

我有一个表，CustPassMaster其中有16列，其中一个是CustNum varchar(8)，并且创建了一个index IX_dbo_CustPassMaster_CustNum。当我运行SELECT语句时： SELECT * FROM dbo.CustPassMaster WHERE CustNum = '12345678' 它完全忽略索引。这让我感到困惑，因为我还有另一个表，CustDataMaster其中包含更多列（55），其中一个是CustNum varchar(8)。我IX_dbo_CustDataMaster_CustNum在此表的此列（）上创建了一个索引，并使用了几乎相同的查询： SELECT * FROM dbo.CustDataMaster WHERE CustNum = '12345678' 它使用我创建的索引。 这背后有什么具体的理由吗？为什么要使用from的索引CustDataMaster，而不使用from的索引CustPassMaster？是由于列数少吗？ 第一个查询返回66行。对于第二个，返回1行。 另外，还要注意：CustPassMaster具有4991条记录和CustDataMaster5376条记录。这可能是忽略索引的原因吗？CustPassMaster也有具有相同CustNum值的重复记录。这是另一个因素吗？ 我将此主张基于两个查询的实际执行计划结果。 这是DDL CustPassMaster（具有未使用的索引的DDL ）： CREATE TABLE dbo.CustPassMaster( [CustNum] [varchar](8) NOT NULL, [Username] [char](15) NOT NULL, [Password] [char](15) NOT NULL, /* more columns here */ [VBTerminator] …

16 sql-server  sql-server-2012  index-tuning 

我很难找到有关如何在PostgreSQL中缓存索引的“一般性”解释，因此我希望对以下任何或所有假设进行现实检查： PostgreSQL索引（如行）位于磁盘上，但可以缓存。 索引可能完全在高速缓存中，或者根本不存在。 是否缓存它取决于使用频率（由查询计划者定义）。 因此，大多数“明智的”索引将一直存在于缓存中。 索引buffer cache与行位于同一高速缓存（？）中，因此索引所使用的高速缓存空间不可用于行。 我理解这一点的动机来自另一个问题，我曾问过有人建议在不能访问大多数数据的表上使用部分索引。 在进行此操作之前，我想弄清楚使用部分索引有两个优点： 我们减小了缓存中索引的大小，从而为缓存中的行本身释放了更多空间。 我们减小了B树的大小，从而加快了查询响应速度。

16 postgresql  performance  index-tuning  cache