标签: optimization

我最近看到了“where 1=1 statement”这个问题；为了编写更清晰的代码（从宿主语言的角度），我在构建动态 SQL 时经常使用的 SQL 构造。

一般来说，添加到 SQL 语句中是否会对查询性能产生负面影响？我不是在寻找关于特定数据库系统的答案（因为我已经在 DB2、SQL Server、MS-Access 和 mysql 中使用过它）——除非在不了解细节的情况下不可能回答。

我们需要每晚在我们的 SQL Server 2008 R2 上做一些报告。计算报告需要几个小时。为了缩短时间，我们预先计算了一个表格。该表是基于 JOINining 12 个相当大（数千万行）的表创建的。

直到几天前，这个聚合表的计算才用了大约 4 个小时。我们的 DBA 将这个大连接拆分为 3 个较小的连接（每个连接 4 个表）。临时结果每次都保存到一个临时表中，供下次join使用。

DBA 增强的结果是，聚合表在 15 分钟内计算完成。我想知道这怎么可能。DBA 告诉我，这是因为服务器必须处理的数据数量较少。换句话说，在大的原始连接中，服务器必须处理比在总和较小的连接中更多的数据。但是，我认为优化器会使用原始大连接有效地执行此操作，自行拆分连接并仅发送下一个连接所需的列数。

他所做的另一件事是在其中一个临时表上创建了索引。但是，我再次认为优化器会在需要时创建适当的哈希表，并更好地优化计算。

我和我们的 DBA 讨论过这个问题，但他自己不确定是什么导致了处理时间的改善。他刚刚提到，他不会责怪服务器，因为计算如此大的数据可能会让人不知所措，而且优化器可能很难预测最佳执行计划...... 我明白这一点，但我想对确切原因有更多明确的答案。

所以，问题是：

1. 什么可能导致大的改善？

2. 将大连接拆分为小连接是标准程序吗？

3. 在多个较小连接的情况下，服务器必须处理的数据量真的更小吗？

这是原始查询：

    Insert Into FinalResult_Base
SELECT       
    TC.TestCampaignContainerId,
    TC.CategoryId As TestCampaignCategoryId,
    TC.Grade,
    TC.TestCampaignId,    
    T.TestSetId
    ,TL.TestId
    ,TSK.CategoryId
    ,TT.[TestletId]
    ,TL.SectionNo
    ,TL.Difficulty
    ,TestletName = Char(65+TL.SectionNo) + CONVERT(varchar(4),6 - TL.Difficulty) 
    ,TQ.[QuestionId]
    ,TS.StudentId
    ,TS.ClassId
    ,RA.SubjectId
    ,TQ.[QuestionPoints] 
    ,GoodAnswer  = Case When TQ.[QuestionPoints] Is null Then 0
                      When TQ.[QuestionPoints] > 0 Then 1 
                      Else 0 End
    ,WrongAnswer …

这是我的查询示例：

SELECT
    nickname, 
    CASE class_id
      WHEN 1 THEN 'Druid'
      WHEN 2 THEN 'Necromancer'
      WHEN 3 THEN 'Mage'
      WHEN 4 THEN 'Priest'
      WHEN 5 THEN 'Warrior'
      WHEN 6 THEN 'Stalker'
      WHEN 7 THEN 'Paladin'
      WHEN 8 THEN 'Psionic'
    END class_name,
    ROUND(AVG(level),2) level,
    ROUND(AVG(tabard_id),2) tabard,
    CASE rank_id
      WHEN 1 THEN 'Leader'
      WHEN 2 THEN 'Officer'
      WHEN 3 THEN 'Veteran'
      WHEN 4 THEN 'HonoryMember'
      WHEN 5 THEN 'OrdinaryMember'
      WHEN 6 THEN 'Alt'
      WHEN 7 THEN 'Apprentice'
      WHEN 8 THEN 'Penalty'
    END rank_name,
    ROUND(AVG(loyality),2) …

我试图理解为什么使用表变量会阻止优化器使用索引查找然后书签查找与索引扫描。

填充表：

CREATE TABLE dbo.Test 
(
    RowKey INT NOT NULL PRIMARY KEY, 
    SecondColumn CHAR(1) NOT NULL DEFAULT 'x',
    ForeignKey INT NOT NULL 
) 

INSERT dbo.Test 
(
    RowKey, 
    ForeignKey
) 
SELECT TOP 1000000 
    ROW_NUMBER() OVER (ORDER BY (SELECT 0)),
    ABS(CHECKSUM(NEWID()) % 10)     
FROM sys.all_objects s1
CROSS JOIN sys.all_objects s2 

CREATE INDEX ix_Test_1 ON dbo.Test (ForeignKey) 

使用单个记录填充表变量，并尝试通过搜索外键列来查找主键和第二列：

DECLARE @Keys TABLE (RowKey INT NOT NULL) 

INSERT @Keys (RowKey) VALUES (10)

SELECT 
    t.RowKey,
    t.SecondColumn
FROM
    dbo.Test t 
INNER JOIN 
    @Keys k
ON
    t.ForeignKey = …

表t有两个索引：

create table t (a int, b int);
create type int_pair as (a int, b int);
create index t_row_idx on t (((a,b)::int_pair));
create index t_a_b_idx on t (a,b);

insert into t (a,b)
select i, i
from generate_series(1, 100000) g(i)
;

ANY运算符不使用索引：

explain analyze
select *
from t
where (a,b) = any(array[(1,1),(1,2)])
;
                                            QUERY PLAN                                             
---------------------------------------------------------------------------------------------------
 Seq Scan on t  (cost=0.00..1693.00 rows=1000 width=8) (actual time=0.042..126.789 rows=1 loops=1)
   Filter: (ROW(a, b) = ANY (ARRAY[ROW(1, 1), ROW(1, 2)]))
   Rows Removed …

我正在运行一个查询，该查询给出有关内存的警告Excessive Grant。

使用的表和索引太多，包括复杂的view，因此很难在此处添加所有定义。

我试图找出我可能导致Excessive Grant. 可以转换吗？

查看执行计划，我可以看到以下内容：

<ScalarOperator
  ScalarString="CONVERT(date,[apia_repl_sub].[dbo].[repl_Aupair].[ArrivalDate] as [repl].[ArrivalDate],0)">
  <Convert DataType="date" Style="0" Implicit="false">
    <ScalarOperator>
      <Identifier>
        <ColumnReference Database="[apia_repl_sub]" Schema="[dbo]" Table="[repl_Aupair]" Alias="[repl]" Column="ArrivalDate" />
      </Identifier>
    </ScalarOperator>
  </Convert>
</ScalarOperator>

和这个：

<ScalarOperator ScalarString="CONVERT(date,[JUNOCORE].[dbo].[applicationPlacementInfo].[arrivalDate] as [pi].[arrivalDate],0)">
  <Convert DataType="date" Style="0" Implicit="false">
    <ScalarOperator>
      <Identifier>
        <ColumnReference Database="[JUNOCORE]" Schema="[dbo]" Table="[applicationPlacementInfo]" Alias="[pi]" Column="arrivalDate" />
      </Identifier>
    </ScalarOperator>
  </Convert>
</ScalarOperator>

这是查询，尽管您也可以在此处查看带有执行计划的查询：

DECLARE @arrivalDate DATEtime = '2018-08-20'

SELECT      app.applicantID,
            app.applicationID,
            a.preferredName,
            u.firstname,
            u.lastname,
            u.loginId                       AS emailAddress,
            s.status                        AS statusDescription,
            CAST(repl.arrivalDate AS DATE)  AS …

我试图解决以下问题大约一个小时，但仍然没有进一步解决。

好的，我有一张桌子（MyISAM）：

+---------+-------------+------+-----+-------------------+----------------+
| Field   | Type        | Null | Key | Default           | Extra          |
+---------+-------------+------+-----+-------------------+----------------+
| id      | int(11)     | NO   | PRI | NULL              | auto_increment |
| http    | smallint(3) | YES  | MUL | 200               |                |
| elapsed | float(6,3)  | NO   |     | NULL              |                |
| cached  | tinyint(1)  | YES  |     | NULL              |                |
| ip      | int(11)     | NO   |     | NULL              |                |
| date    | timestamp   | …

有没有办法如何将基数估计“注入”到 SQL Server 优化器（任何版本）？

即类似于 Oracle 的基数提示。

我的动机是由这篇文章驱动的，查询优化器真的有多好？^[1]，他们测试基数估计量对选择一个糟糕计划的影响。因此，如果我可以强制 SQL Server 精确地“估计”复杂查询的基数就足够了。

^[1]莱斯、维克多等人。“查询优化器有多好，真的吗？”
VLDB 基金会会议录 9.3 (2015)：204-215。

我现在负责 SQL 开发的同事说我永远不应该使用OR语句，因为它会弄乱查询优化器并忽略产生慢查询的表索引。我在谷歌搜索时找不到任何这样的例子。以下查询的替代方案变得非常难看，其中有十几个代码块看起来几乎相同（对于示例）使用 if else 语句为每个变量状态。请注意检查为短路的变量，如果值为 2，则返回所有结果，否则按字段过滤。

我询问了一些包含这些关于为什么不使用OR语句的声明的资源，并收到了以下链接（我们使用的是 MS SQL Server）。

• /sf/ask/394779731/
• https://bertwagner.com/2018/02/20/or-vs-union-all-is-one-better-for-performance/
• http://sqlserverplanet.com/optimization/using-union-instead-of-or

这些示例似乎都不像当前的实现，如下所示。我发现很难相信这段代码有问题，但如果有问题，请告诉我。我还想了解更多信息，其中关于不使用的评论OR实际上可能适用以及为什么如此，以便更好地理解该问题。

SELECT
    e.EmployeeName,
    e.DepartmentName,
    crs.Title,
    c.Name as CompanyName
FROM Employee E
Left Outer Join Company c ON c.Id = @companyId
    INNER JOIN Department d on e.DepartmentId = d.Id 
WHERE   
    c.Id = @companyId           
    AND (@Active = 2 OR  crs.IsActive = @Active)
    AND (@Dot = 2 OR IsDot = @Dot)
    AND crs.CompanyId = @companyId
    AND d.CompanyId = @companyId
ORDER BY EmployeeName, Title, …

我有两个类似的查询，它们生成相同的查询计划，只是一个查询计划执行了 1316 次聚集索引扫描，而另一个执行了 1 次。

两个查询之间的唯一区别是不同的日期标准。长时间运行的查询实际上更窄了日期条件，并拉回了更少的数据。

我已经确定了一些对这两个查询都有帮助的索引，但我只想了解为什么 Clustered Index Scan 操作符在一个查询上执行 1316 次，而这个查询实际上与它执行 1 次的查询相同。

我查看了正在扫描的PK的统计数据，它们是相对最新的。

原始查询：

select distinct FIR_Incident.IncidentID
from FIR_Incident
left join (
    select incident_id as exported_incident_id
    from postnfirssummary
) exported_incidents on exported_incidents.exported_incident_id = fir_incident.incidentid
where FI_IncidentDate between '2011-06-01 00:00:00.000' and '2011-07-01 00:00:00.000'
    and exported_incidents.exported_incident_id is not null

生成这个计划：

缩小日期范围标准后：

select distinct FIR_Incident.IncidentID
from FIR_Incident
left join (
    select incident_id as exported_incident_id
    from postnfirssummary
) exported_incidents on exported_incidents.exported_incident_id = fir_incident.incidentid
where FI_IncidentDate between '2011-07-01 00:00:00.000' and '2011-07-02 00:00:00.000' …