标签: execution-plan

只是想知道统计数据是否保存在数据库中而不是内存中？如果我将数据库从生产服务器备份/恢复到开发服务器，它是否会保留相同的统计信息，以便在开发服务器上执行计划不会有太大不同？

在 PostgreSQL 中，EXPLAIN 或 EXPLAIN ANALYZE 将显示执行查询的估计成本。但是 MySQL 中的 EXPLAIN 不提供此信息。如何在不安装其他工具的情况下获得估算成本？我正在使用 MySQL-5.6.16。

针对此数据库的全文查询（存储 RT（请求跟踪器）票证）似乎需要很长时间才能执行。附件表（包含全文数据）大约为 15GB。

数据库模式如下，大约有 200 万行：

rt4=# \d+ 附件
                                                    表“public.attachments”
     专栏 | 类型 | 修饰符 | 存储 | 描述
-----------------+------------------------------------------+-- -------------------------------------------------- -------+----------+-------------
 身份证 | 整数 | not null default nextval('attachments_id_seq'::regclass) | 平原 |
 交易ID | 整数 | 不为空| 平原 |
 家长 | 整数 | 非空默认值 0 | 平原 |
 消息ID | 字符变化(160) | | 扩展 |
 主题 | 字符变化(255) | | 扩展 |
 文件名 | 字符变化(255) | | 扩展 |
 内容类型 | 字符变化(80) | | 扩展 |
 内容编码 …

我们最近将我们的服务器从 SQL Server 2008R2 升级到 SQL Server 2014。我们有一个查询在 2008R2 中运行良好，但现在在 2014 年运行速度非常慢并且执行计划很糟糕。

我做了几次测试...

1. 将 2014 DB 切换回 2008/2012 兼容模式。
2. 使用分页测试查询。

这两者都导致查询运行与 SQL Server 2008R2 相同且速度快。

为什么 SQL Server 2014 中的计划如此糟糕且查询运行时间如此之长？

此图显示了 2 个查询，一个使用 rownumber 其在 2008R2 中运行的方式，然后第二个是使用分页进行修复。两者都在 2014 年运行，两者都非常不同，但在 2008 年，我们看到的性能与 2014 年使用分页相同。

在对分区进行连接时与在整个表上进行连接时，以下连接具有非常不同的行估计：

CREATE TABLE m_data.ga_session (
  session_id         BIGINT                   NOT NULL,
  visitor_id         BIGINT                   NOT NULL,
  transaction_id     TEXT,

  timestamp          TIMESTAMP WITH TIME ZONE NOT NULL,
  day_id             INTEGER                  NOT NULL,
  [...]

  device_category    TEXT                     NOT NULL,
  [...]
  operating_system   TEXT

);

对于所有分区：

CREATE TABLE IF NOT EXISTS m_data.ga_session_20170127 ( CHECK (day_id = 20170127) ) INHERITS (m_data.ga_session);
-- the identifier are theoretically invalid, but they get truncated to 63 chars and nevertheless work
CREATE INDEX IF NOT EXISTS "ga_session__m_tmp.normalize_device_category(ga_session.device_category)" on m_data.ga_session_20170127 USING btree (m_tmp.normalize_device_category(device_category)) ;
CREATE INDEX …

我有一个分区视图，其中包含以下插入触发器（可怜的 mans 分区）。当我执行 DELETE 时，我得到以下查询计划：

delete from factproductprice where pricedate = '20170725'

在视图上触发：

ALTER TRIGGER [dbo].[factProductPriceDelete] ON [dbo].[FactProductPrice]
INSTEAD OF DELETE AS
BEGIN
  IF @@ROWCOUNT = 0 RETURN;

  DECLARE @PriceDate DATE
  SELECT @PriceDate = CAST(PriceDate AS DATE) FROM DELETED
  IF @PriceDate BETWEEN '20140101' AND '20141231'
  BEGIN
    DELETE FROM dbo.FactProductPrice2014
    WHERE ProductId IN (SELECT ProductId FROM DELETED) AND SalesPriceSchemeId IN (SELECT SalesPriceSchemeId FROM DELETED) AND PriceDate IN (SELECT PriceDate FROM DELETED) 
  END
  IF @PriceDate BETWEEN '20150101' AND '20151231'
  BEGIN
    DELETE FROM …

将主表连接到详细表时，如何鼓励 SQL Server 2014 使用较大（详细）表的基数估计作为连接输出的基数估计？

例如，当将 10K 主行连接到 100K 详细行时，我希望 SQL Server 估计连接为 100K 行——与估计的详细行数相同。我应该如何构建我的查询和/或表和/或索引以帮助 SQL Server 的估算器利用每个详细信息行始终具有相应的主行这一事实？（这意味着它们之间的连接永远不应该减少基数估计。）

这里有更多细节。我们的数据库有一对主/明细表：VisitTarget每个销售交易占一行，每个交易VisitSale中的每个产品占一行。这是一个一对多的关系：一个 VisitTarget 行平均有 10 个 VisitSale 行。

表格如下所示：（我正在简化为仅针对此问题的相关列）

-- "master" table
CREATE TABLE VisitTarget
(
  VisitTargetId int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
  SaleDate date NOT NULL,
  StoreId int NOT NULL
  -- other columns omitted for clarity  
);
-- covering index for date-scoped queries
CREATE NONCLUSTERED INDEX IX_VisitTarget_SaleDate 
    ON VisitTarget (SaleDate) INCLUDE (StoreId /*, ...more columns */);

-- …

我有一个支持 .NET Core API 应用程序的 Azure SQL 数据库。浏览 Azure 门户中的性能概览报告表明，我的数据库服务器上的大部分负载（DTU 使用情况）来自 CPU，特别是一个查询：

正如我们所见，查询 3780 负责几乎所有服务器上的 CPU 使用率。

这在某种程度上是有道理的，因为查询 3780（见下文）基本上是整个应用程序的关键，并且经常被用户调用。这也是一个相当复杂的查询，需要许多连接才能获得所需的正确数据集。查询来自一个最终看起来像这样的 sproc：

-- @UserId UNIQUEIDENTIFIER

SELECT
    C.[Id],
    C.[UserId],
    C.[OrganizationId],
    C.[Type],
    C.[Data],
    C.[Attachments],
    C.[CreationDate],
    C.[RevisionDate],
    CASE
        WHEN
            @UserId IS NULL
            OR C.[Favorites] IS NULL
            OR JSON_VALUE(C.[Favorites], CONCAT('$."', @UserId, '"')) IS NULL
        THEN 0
        ELSE 1
    END [Favorite],
    CASE
        WHEN
            @UserId IS NULL
            OR C.[Folders] IS NULL
        THEN NULL
        ELSE TRY_CONVERT(UNIQUEIDENTIFIER, JSON_VALUE(C.[Folders], CONCAT('$."', @UserId, '"')))
    END [FolderId],
    CASE 
        WHEN C.[UserId] IS NOT NULL OR …

我在 SQL Server 2017 执行计划中看到过这个警告：

警告：操作导致剩余 IO [原文如此]。实际读取的行数为 (3,321,318)，但返回的行数为 40。

这是 SQLSentry PlanExplorer 的一个片段：

为了改进代码，我添加了一个非聚集索引，以便 SQL Server 可以访问相关行。它工作正常，但通常会有太多（大）列包含在索引中。它看起来像这样：

如果我只添加索引而不包含列，如果我强制使用索引，它看起来像这样：

显然，SQL Server 认为键查找比剩余 I/O 昂贵得多。我有一个没有太多测试数据的测试设置（还），但是当代码投入生产时，它需要处理更多的数据，所以我很确定需要某种非聚集索引。

当您在 SSD 上运行时，键查找真的那么昂贵，我必须创建全脂索引（有很多包含列）？