标签: optimization

我正在尝试优化在 PostgreSQL 15.4 中连接两个大表（40MM+ 行）的查询。

SELECT files.id, ARRAY_AGG(b.status)\nFROM files\nLEFT OUTER JOIN processing_tasks b\n    ON (files.id = b.file_id AND b.job_id = 113)\nWHERE files.round_id = 591\nGROUP BY files.id;\n

explain (analyze)完全相同的查询的两个计划位于：

\n

• https://explain.depesz.com/s/cUXB需要 87 秒，使用并行 Seq 扫描processing_tasks.job_id（默认计划）

  \n
\n

• https://explain.depesz.com/s/j39G需要 4 秒，使用位图索引扫描processing_tasks.job_id（当 时set local enable_seqscan = OFF）

  \n
\n

在 中files，908,275 / 39,000,105 (2.3%) 个元组有round_id=591; 它是静态的。
\n在 中processing_tasks，4,026,364 / 60,780,802 (6.6%) 个元组有job_id=113，并且随着行的插入，这个值将变得越来越常见，可能达到表的 …

我对 PostgreSQL 中的查询计划器有疑问。我知道，这个规划器正在从 pg_statistics 获取数据，但是......谁能告诉我这个规划器是根据什么依据这些信息进行有效查询的？它是如何使用这些统计数据的？有没有比文档更好的描述整个过程？

我完全知道我的问题可能无法理解，但我真的不知道如何更容易地解释我的问题。如果您有问题，请提问。

对于 MySQL 5.1.49 中的以下表结构：

CREATE TABLE `leads` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `institution_id` int(10) unsigned NOT NULL,
  `lender_id` int(10) unsigned NOT NULL,
  `product_id` int(10) unsigned NOT NULL,
  `client_id` int(10) unsigned NOT NULL,
  `contract_id` int(10) unsigned DEFAULT NULL,
  `employee_id` int(11) unsigned DEFAULT NULL,
  `create_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `inquiry_date` timestamp NULL DEFAULT NULL,
  `claimed_date` timestamp NULL DEFAULT NULL,
  `refunded` timestamp NULL DEFAULT NULL,
  `price` decimal(10,2) unsigned NOT NULL,
  `downloaded` int(11) NOT NULL DEFAULT '0',
  `status` enum('in_review','declined','pre-approved') DEFAULT NULL, …

对于布尔用途列，哪个更好：可为空char(0)或tinyint(1).

我知道 bool 是 tinyint(1) 的别名，但在 O'reilly 出版的“高性能 MySQL”一书中说：

“如果您想在单个存储空间中存储真/假值，另一种选择是创建一个可为空的 CHAR(0) 列。该列能够存储值 (NULL) 或零的缺失-length 值（空字符串）。"

哪个更适合大小、性能、索引或...

更新：我发现此链接对这个问题很有用： Innodb Tables 的高效布尔值存储

我有一个奇怪的问题，我真的不明白。简单地说，我有一个包含 4 个表连接的连接，我相信它们都有适当的索引，但是查询需要大量的时间，除非我删除它的一部分。

更大的图片是，有 3 种类型的对象 A、B 和 C，每个对象都有自己的表，并且相关联，A 是孩子，B 是父母，C 是祖父母。除此之外，还有一个关系表 R，允许多个 B 与多个 C 相关，并且由于关系 R 属于特定类型，因此还有一个附加表 T。

现在在有问题的查询中，我试图获取类型 A 的记录列表，谁的父母与祖父母有特定类型的关系，祖父母的名字 ILIKE 另一个字符串。

表A有~700k条记录，表B有~60k条记录，表C有~8k条记录，表R有~90k条记录，表T有~100条记录。

由于 A 包含链接到字段 B.id 的字段 parent_id，因此 B 不需要直接包含在查询中。

所以查询是这样的：

SELECT DISTINCT A.id, A.name
FROM A
JOIN R ON A.parent_id=R.lhs
JOIN T ON R.type=T.id AND T.alias='type-name'
JOIN C ON R.rhs=C.id
WHERE A.flag=1 AND A.strvalue='value' AND C.name ILIKE '%substr%'
ORDER BY A.name ASC
LIMIT 25;

像这样运行查询需要超过 10 秒（我从来没有让它运行完成，因为它需要太长时间）。

在我的实际设置中，我在关键 ID 字段中有类型，所以查询实际上挂在类型中的一个字段上，但索引也会这样做。

奇怪的是我已经尝试从查询中取出位，因此尝试确定花费太长时间的位，并删除 T 部分或 ILIKE 部分似乎使其在正常时间范围内执行。 …

基于 Paul White 的博客，SQL Server 中存在三个优化阶段，搜索 0（事务处理）、搜索 1（快速计划）和搜索 2（完全优化）。每个阶段都有进入和终止条件。

我的问题是，我们可以强制优化器在一个优化阶段运行吗？

我有以下查询。有没有一种方法可以将其放入一个查询中？如果没有，我可以进一步缩小它吗？请指教。

    DECLARE @highRegion TABLE(regionId INT, countR INT)
    DECLARE @lowRegion TABLE(regionId INT, countR INT)
    DECLARE @midRegion TABLE(regionId INT, countR INT)

    INSERT INTO @highRegion
    SELECT c.fRegionID,
           COUNT(1) AS VALUE
    FROM   census.Country c
           INNER JOIN census.IncomeGroup ig
                ON  c.fIncomeGroupID = ig.IncomeGroupID
    WHERE  ig.Name IN ('High income: nonOECD', 'High income: OECD')
    GROUP BY
           c.fRegionID

    INSERT INTO @lowRegion
    SELECT c.fRegionID AS VALUE,
           COUNT(1)
    FROM   census.Country c
           INNER JOIN census.IncomeGroup ig
                ON  c.fIncomeGroupID = ig.IncomeGroupID
    WHERE  ig.Name = 'Upper middle income'
    GROUP BY
           c.fRegionID

    INSERT INTO …

我有一张像：

create table x (a varchar(20),
b varchar(30),
c varchar(30),
primary key clustered(a asc))

所以我想知道我是否创建了一个像这样的索引：

Create nonclustered index test on x(a) include (b,c)

该索引将使我使用列 a、b、c 的查询更快？

我仍然是查询优化的新手，我有一个存储过程，它使用游标遍历表中的每一行，并执行以下操作：

1. 计算每行之间的时间差
2. 计算每行之间的距离
3. 如果距离 < 5 AND TimeDifference > 3 分钟，则添加到 TEMP 表

我尝试将此 Cursor 转换为 WHILE 循环，但性能下降。所以我需要帮助将其转换为SET BASED方法而不是Procedural Based方法

所以 Cursor 执行这个逻辑：

-- READ Current Row into Cursor Variables
FETCH NEXT FROM crAssetIgnitionOnOff INTO
              @current_iVehicleMonitoringID
            , @current_iAssetID
            , @current_dtUTCDateTime
            , @current_sptGeoLocationPoint
            , @current_fLatitude
            , @current_fLongitude
            , @current_fAngle
            , @current_fSpeedKPH 
            , @current_sIgnitionStatus
            , @current_eEventCode
            , @current_sEventCode

IF(@current_iAssetID = @prev_iAssetID)
    BEGIN

        ---- Calculate Time Difference from previous Point
    DECLARE @diffInSeconds INT
        SET @diffInSeconds = DATEDIFF(SECOND, @prev_dtUTCDateTime, @current_dtUTCDateTime) …

我每周使用Ola Hallengren 的解决方案更新统计数据。

根据下面的文章，我正在考虑启用 Auto Stats Async 并打开跟踪标志 2371。

具有大表的数据库应使用自动更新统计数据异步功能

现在，我的数据库的 async 选项为 false：

此外，来自SQL Server 2008 及更高版本的重要修补程序：

此设置允许异步自动更新统计信息，同时您当前运行的查询继续使用旧统计信息，直到更新的统计信息可供使用，从而降低不可预测的查询性能。对此的替代方案（这是默认设置）是暂停查询执行（仅适用于使用该对象统计信息的查询），同时为该对象自动同步更新统计信息。根据对象的大小以及硬件和 I/O 子系统，这可能需要几秒钟到几分钟的时间。

题：

在测试环境中，在将 Auto Update Stats Async 设置为 ON 之前/之后，可以进行哪些好的简单测试？

在什么情况下我更有可能从异步自动更新统计信息中受益？

数据库 500GB+，大表。