【问题标题】:optimizing the stored procedure with indexing使用索引优化存储过程
【发布时间】:2014-05-04 05:49:56
【问题描述】:

我有一个这样的存储过程:

ALTER PROCEDURE [dbo].[IBS_fetchrequested]
   @tid integer = null,
   @Tbaroced dbo.TBarcode readonly
as 
begin
   SET NOCOUNT ON;

   if (select COUNT(*) from  Khanger_tbl 
       where tid = @tid and requested = 1 and delivered = 0) > 0
   begin
      select 
         t.TBarcode, k.HBarcode as keyloc 
      from 
         Khanger_tbl k
      inner join 
         transaction_tbl t on k.transactid = t.transactID
      where 
         tid = @tid 
         and requested = 1 
         and delivered = 0  
         and t.Tbarcode not in (select carid from @Tbaroced) 
         and t.status = 3
    end
end

在我的数据库中,我有大约 2 条缺失记录。如果我在 Khanger_tbl 中的 tid 上添加索引,我的存储过程性能会提高吗?如何提高这些存储过程的性能?还有什么技巧吗?

感谢任何帮助!

如果我添加一个索引,它将如何影响我的插入和更新? 我该如何优化这个?

【问题讨论】:

  • where子句中引用的列(tid、requested、delivered、status、barcode),它们属于哪些表?
  • tid,requested,delivered 属于 Khanger_tbl 和 status,barcode 属于 transaction_tbl
  • 为什么在运行查询之前检查表中是否存在记录?

标签: sql-server sql-server-2008 stored-procedures


【解决方案1】:

为什么在运行查询之前检查数据是否存在?
只需运行查询,如果没有数据,您将返回一个空记录集。你这样做的方式是读取数据表两次。

...而且,是的,如果没有索引,在tid 上添加索引会加快速度。它会稍微减慢插入速度。

对于data distribution,对于表中的任何特定列,这与表中有多少记录具有该列中的每个值有关。 例如,对于像requested 这样的布尔值列,如果表中的数据分布使得只有一小部分记录具有requestedvalue = 1,那么在“requested”上放置索引将加快速度更多。

 ALTER PROCEDURE [dbo].[IBS_fetchrequested]
 @tid integer = null,
 @Tbaroced dbo.TBarcode readonly
 as 
 SET NOCOUNT ON;

   Select t.TBarcode, k.HBarcode as keyloc 
   From   Khanger_tbl k
      Join transaction_tbl t 
         on t.transactid = k.transactID
   Where tid = @tid 
     and requested = 1 
     and delivered = 0  
     and t.Tbarcode not in 
            (select carid from @Tbaroced) 
     and t.status = 3

【讨论】:

  • 好的,先生,在这种情况下,我必须为两者(tid 和请求)提供索引
  • 在我的情况下,只有一小部分记录具有 Deliverd=0 和 tid..所以我可以同时给出索引?
  • 从执行计划我怎么能理解这是提高性能??
  • 先生能否给个提示
  • 先生,我想检查表扫描成本??
猜你喜欢
  • 1970-01-01
  • 2021-04-17
  • 2012-02-26
  • 2018-04-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多