Questions tagged «index-tuning»

我正在优化一些查询。 对于以下查询， SET STATISTICS IO ON; DECLARE @OrderStartDate DATETIME2 = '27 feb 2016'; DECLARE @OrderEndDate DATETIME2 = '28 feb 2016'; SELECT o.strBxOrderNo , o.sintOrderStatusID , o.sintOrderChannelID , o.sintOrderTypeID , o.sdtmOrdCreated , o.sintMarketID , o.strOrderKey , o.strOfferCode , o.strCurrencyCode , o.decBCShipFullPrice , o.decBCShipFinal , o.decBCShipTax , o.decBCTotalAmount , o.decWrittenTotalAmount , o.decBCWrittenTotalAmount …

15 sql-server  query-performance  sql-server-2014  optimization  index-tuning 

这个问题是关于SQL Server索引性能的，其中包含a varchar(2000)作为INCLUDE索引。 我试图在缓慢而不稳定的数据库应用程序中提高性能。在某些情况下，数据是通过大VARCHAR字符串来访问的，与查询包括像multple字符串操作SUBSTRING()，SPACE()和DATALENGTH()。这是访问的简化示例； update fattable set col3 = SUBSTRING(col3,1,10) + '*' + SUBSTRING(col3,12,DATALENGTH(col3)-12) from fattable where substring(col3,10,1) = 'A' and col2 = 2 模式如下所示： 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 …

15 sql-server  sql-server-2008  performance  index-tuning 

我一直在与我的办公室中的各种开发人员就索引的成本以及唯一性是有利还是昂贵（可能两者都有）进行辩论。问题的症结在于我们的竞争资源。 背景 之前，我曾读过一篇讨论，其中指出Unique索引并不需要额外维护，因为Insert操作会隐式地检查索引是否适合B树，并且如果在非唯一索引中找到重复项，则会在其后附加一个唯一化符。键的结尾，否则直接插入。在此事件序列中，Unique索引没有附加成本。 我的同事通过说这Unique是在寻求B树中的新职位之后强制执行的第二项操作来抗衡此声明，因此，与非唯一索引相比，维护成本更高。 最糟糕的是，我看到了带有标识列（本质上是唯一的）的表，该列是表的集群键，但明确地表示为非唯一。最糟糕的是我对唯一性的痴迷，并且所有索引都被创建为唯一，并且当不可能定义与索引的显式唯一关系时，我将表的PK附加到索引的末尾以确保唯一性得到保证。 我经常参与开发团队的代码审查，并且我需要能够提供一些一般性的指导方针，以使他们可以遵循。是的，应该评估每个索引，但是当您有五台服务器，每台服务器都有数千个表，并且一个表上有多达二十个索引时，您需要能够应用一些简单的规则来确保一定水平的质量。 题 Insert与维护非唯一索引的成本相比，唯一性是否会在后端增加成本？其次，将表的主键附加到索引的末尾以确保唯一性有什么问题？ 表定义示例 create table #test_index ( id int not null identity(1, 1), dt datetime not null default(current_timestamp), val varchar(100) not null, is_deleted bit not null default(0), primary key nonclustered(id desc), unique clustered(dt desc, id desc) ); create index [nonunique_nonclustered_example] on #test_index (is_deleted) include …

14 sql-server  index-tuning  database-internals  unique-constraint 

我想根据两列是否相等来进行快速查找。我试图使用带有索引的计算列，但是SQL Server似乎没有使用它。如果仅使用带有索引的静态填充的位列，则会得到预期的索引查找。 似乎还有其他类似的问题，但是没有一个问题集中在为什么不使用索引上。 测试表： CREATE TABLE dbo.Diffs ( Id int NOT NULL IDENTITY (1, 1), DataA int NULL, DataB int NULL, DiffPersisted AS isnull(convert(bit, case when [DataA] is null and [DataB] is not null then 1 when [DataA] <> [DataB] then 1 else 0 end), 0) PERSISTED , DiffComp AS …

14 sql-server  index  index-tuning  computed-column 

我的桌子上有很多插入物，将（uploaded_at）字段之一设置为NULL。然后，定期任务选择所有元组WHERE uploaded_at IS NULL，对其进行处理并更新，将其设置uploaded_at为当前日期。 我应该如何索引表？ 我了解我应该使用部分索引，例如： CREATE INDEX foo ON table (uploaded_at) WHERE uploaded_at IS NULL 或类似的东西。我有点困惑，但是如果对一个始终为的字段进行索引是正确的话NULL。或者使用b树索引是否正确。哈希看起来是个更好的主意，但是它已经过时了，不能通过流热备份复制来复制。任何建议将不胜感激。 我已经尝试了以下索引： "foo_part" btree (uploaded_at) WHERE uploaded_at IS NULL "foo_part_id" btree (id) WHERE uploaded_at IS NULL 并且查询计划程序似乎总是选择foo_part索引。explain analyse也会为foo_part索引产生更好的结果： Index Scan using foo_part on t1 (cost=0.28..297.25 rows=4433 width=16) (actual time=0.025..3.649 rows=4351 loops=1) Index Cond: (uploaded_at …

14 postgresql  index  index-tuning  null 

我有桌子 | base_schedule_line_items | CREATE TABLE base_schedule_line_items（ idint（10）unsigned NOT NULL AUTO_INCREMENT， installmentint（10）unsigned NOT NULL， on_date日期NOT NULL， actual_date日期默认值， payment_typeint（11）NOT NULL， scheduled_principal_outstanding十进制（65,0）NOT NULL， scheduled_principal_due十进制（65,0） NOT NULL， scheduled_interest_outstanding十进制（65,0）NOT NULL， scheduled_interest_due十进制（65,0）NOT NULL， currencyint（11）NOT NULL， updated_at日期时间NOT NULL缺省'2013-01-06 14:29:16'， created_atdatetime NOT NULL默认值' 2013-01-06 14:29:16'， loan_base_schedule_idint（10）unsigned NOT NULL， lending_idint（10）unsigned NOT NULL， rescheduletinyint（1）DEFAULT'0'， PRIMARY KEY（id）， KEY index_base_schedule_line_items_loan_base_schedule （loan_base_schedule_id），KEY …

13 mysql  index  index-tuning 

这是一种奇怪的情况，但我希望有人能回答。 在进行一些性能问题排查期间，我们按照的要求将NONCLUSTERED INDEX添加到了表中sp_BlitzIndex。第二天，我们检查了它的使用情况，结果显示0次读取（0次扫描/搜索，0次单例查找），因此我们将其禁用。 在第二分钟，我们收到了抱怨应用程序缓慢（性能问题）的投诉，这是我们在添加INDEX时首先尝试检查并解决的问题。 现在，从理论上讲，这听起来纯属巧合。可证明，可衡量的是，未使用 INDEX 。禁用它不会导致查询性能下降。但它几乎TOO巧合。 题 因此，我的问题就很简单了： 它是在所有可能的，一个非聚集索引，其使用提供的统计（从动态管理视图/ sp_BlitzIndex）显示NO使用，还是已经帮助受影响的表以某种方式查询性能？

13 sql-server  database-design  index-tuning  sql-server-2016  nonclustered-index 

我的开发人员已将其应用程序设置为将GUID用作几乎所有表的PK，并且默认情况下，SQL Server已在这些PK上设置了聚集索引。 该系统还比较年轻，我们最大的表刚刚超过一百万行，但是我们正在研究索引并希望能够迅速扩展，因为不久的将来可能会需要它。 因此，我的第一个倾向是将聚集索引移动到创建的字段，该字段是DateTime的bigint表示形式。但是，使CX唯一的唯一方法是在此CX中包括GUID列，但先创建顺序。 这会导致群集密钥太宽，是否会提高写入性能？读取也很重要，但是此时写入可能是一个更大的问题。

13 sql-server  index-tuning  clustered-index  uniqueidentifier 

我有一个托管在Azure上的SQL数据库。问题在于大小已失控，我可以在主键聚集索引中看到多达99％的碎片。 我能够使用online=onoption 重建所有其他索引，并且不会影响性能。PK聚簇索引之一的大小大于200GB，并且为此REBUILD...WITH (ONLINE=ON)导致锁定。 实际上，确实有来自所有时区的用户都在访问该网站，因此，我找不到可以离线重建索引的时间。 在不造成站点停机的情况下重建大型索引的最佳策略是什么？ 我相信重组将无济于事，因为碎片化率为99％。问题在于该表即使在线也被锁定。主要问题是索引大于200GB。主键是一个整数。

13 sql-server  index-tuning  azure-sql-database  clustered-index 

SQL Server 2014标准版 我需要找到特定月份往返特定城市的航班数量。例如 select count(*) from flights where flightTo_AirportCode = 'aaaa' and flightFrom_Airportcode = 'bbbb' and flightdate < '2016-04-01' and flightdate > '2016-02-28' ; 表模式如下。 我正在尝试评估索引模型A或索引模型B（如下）是否更可取（建立索引需要花费数小时，并且磁盘空间一次只能存在一个，因此我想在跳之前先进行研究）。 根据我的经验，任何一个索引都可以。我对吗？ create index [modelA] on flights (flightTo_AirportCode, flightFrom_AirportCode, flightDate) create index [modelB] on flights (flightDate, flightTo_AirportCode, flightFrom_AirportCode) （或者，更好的是，我可以使用二进制索引或高级机制来解决这个问题吗？） CREATE TABLE [dbo].[flights]( [flightId] [uniqueidentifier] …

11 sql-server  sql-server-2014  index-tuning 

我面临着一些反复出现的死锁，其中之一是键锁，并且包含带有XLOCK提示的SELECT查询，该查询成为了死锁的受害者。另一个语句是对其中一个表的INSERT，该表是第一个查询的视图的一部分。 视图： create view dbo.viewE as select * from dbo.E where myValue > 13000 选择查询： select * from dbo.viewE with (XLOCK) where A > GETUTCDATE() INSERT语句： INSERT INTO [dbo].[E] (myValue,A) VALUES (10,GetDate()) 基础表dbo.E在大约20列中拥有约300万行，其中有些是ntext。 取出查询并使用两个事务手动进行模拟，该行为是可重现的。如果从选择中删除了XLOCK，则行为会更改。 死锁图： <deadlock-list> <deadlock victim="process222222221"> <process-list> <process id="process222222221" taskpriority="0" logused="0" waitresource="KEY: 5:72057604035644444 (ccdf51accc0c)" waittime="2522" ownerId="27202256401" transactionname="SELECT" lasttranstarted="2015-09-14T16:32:36.160" …

11 sql-server  sql-server-2008-r2  index-tuning  locking  deadlock 

我正在努力在以下情况下设置索引视图，以便在执行以下查询时不会进行两次聚集索引扫描。每当我为该查询创建索引视图然后使用它时，它似乎都会忽略我在其上放置的任何索引： -- +++ THE QUERY THAT I WANT TO IMPROVE PERFORMANCE-WISE +++ SELECT TOP 1 * FROM dbo.TB_test1 t1 INNER JOIN dbo.TB_test2 t2 ON t1.PK_ID1 = t2.FK_ID1 ORDER BY t1.somethingelse1 ,t2.somethingelse2; GO 表格设置如下： 两张桌子 它们由上面的查询通过内部联接联接 并按上面的查询从第一个表开始的列排序，然后从第二个表开始的列排序；仅选择TOP 1 （在下面的脚本中，还有一些行可以生成测试数据，以防万一有助于重现问题） -- +++ TABLE SETUP +++ CREATE TABLE [dbo].[TB_test1] ( [PK_ID1] [INT] IDENTITY(1, …

11 sql-server  sql-server-2008  index  index-tuning  materialized-view 

我在数据库的表上创建了以下索引： CREATE INDEX [idx_index1] on [table1] (col1, col2, col3) 服务器建议以下“丢失”索引： CREATE INDEX [idx_index2] on [table1] (col1, col2) INCLUDE (col3, col4, col5, col6....) 在我看来，修改现有索引定义以包括建议的列，而不是创建需要维护的新索引，似乎是合乎逻辑的。在col1和col2上选择的查询可以与index2一样有效地使用index1。我是对的还是我可能错过了什么？

11 sql-server  sql-server-2008-r2  index  index-tuning 

根据此查询，如果我发现总读取量很少（非常接近0或0，例如1或2），而用户更新量则较高或中等（我无法通过此查询找到插入或删除的内容），行数很大时，理论上我应该删除索引。 SELECT DISTINCT OBJECT_NAME(s.[object_id]) AS ObjectName , p.rows TableRows , i.name AS [INDEX NAME] , (user_seeks + user_scans + user_lookups) AS TotalReads , user_updates UserUpdates FROM sys.dm_db_index_usage_stats s INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] AND i.index_id = s.index_id INNER JOIN sys.partitions p ON p.object_id = i.object_id WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') …

11 sql-server  index  index-tuning  best-practices 

我有一张大桌子的I / O问题。 一般统计 该表具有以下主要特征： 环境：Azure SQL数据库（层为P4 Premium（500个DTU）） 行：2,135,044,521 1,275个已使用的分区 聚集和分区索引 模型 这是表的实现： CREATE TABLE [data].[DemoUnitData]( [UnitID] [bigint] NOT NULL, [Timestamp] [datetime] NOT NULL, [Value1] [decimal](18, 2) NULL, [Value2] [decimal](18, 2) NULL, [Value3] [decimal](18, 2) NULL, CONSTRAINT [PK_DemoUnitData] PRIMARY KEY CLUSTERED ( [UnitID] ASC, [Timestamp] ASC ) ) GO ALTER …

10 sql-server  query-performance  index-tuning  azure-sql-database