标签: performance-tuning

我需要搜索一个非常大的PostgreSQL表（500+M行），我想限制返回的搜索结果，但是使用“limit”关键字并不能阻止对整组数据的搜索（正确吗？）

想象一下我的搜索结果包含 1M 行，但我只需要搜索结果中的前 100 条记录！PostgreSQL 数据库是否必须在内存中临时创建这 1M 搜索结果行，然后给我所需的 100 个结果？

或者有什么办法告诉PostgreSQL一旦找到100条记录就停止搜索？

这是我的表，当然还没有填充 500M 记录！

CREATE TABLE con
(
  id bigserial NOT NULL,
  tag1 integer NOT NULL DEFAULT 0,
  tag2 integer NOT NULL DEFAULT 0,
  ref1 integer NOT NULL DEFAULT 0,
  ref2 integer NOT NULL DEFAULT 0,
  CONSTRAINT con_pkey PRIMARY KEY (id)
)

以及测试查询的解释分析：

explain analyze SELECT * FROM con where tag1 = '64813' and tag2 = '80'

Seq Scan on con  (cost=0.00..3215204.72 rows=2470 width=112) (actual time=0.016..36970.528 rows=7505 loops=1)
   Filter: …

我试图弄清楚发生了什么，但目前我无法解决这个问题......

我有两台具有相同规格的服务器，实际上也连接了几乎相同的用户（只有我）...

其中一台服务器的 CPU 使用率稳定在 20%，而另一台服务器的 CPU 使用率稳定在 1%...相同的数据库，相同的进程...

如果 SQL Server 和其他服务器都处于空闲状态，我如何才能知道与其他服务器相比，SQL Server 上实际消耗如此大量 CPU 的是什么？

我继承了一个相当复杂的存储过程，它导致我们的生产环境超时。我使用 SQL Sentry Plan Explorer 来帮助我查看一些问题。我已经确定了一些，但我很难想出可以进行的优化。我们正在使用 SQL Server 2019 和COMPATIBILITY_VERSION = 150.

该存储过程通过 API 调用将数据返回到 Web 客户端，因此页面加载的性能非常重要。通过多个应用程序分析会话，此存储过程已被确定为瓶颈。

以下是已发现的一些问题：

1. PROD 中存在超过 4 百万行数据的超时 (ActualElapsedms = 11499)
2. 估计子树成本高达 187.74（我们下一个最慢的存储过程的子树成本为 0.653）
3. 查询计划的部分内容显示了剩余 I/O（令人惊讶的是其中之一甚至是索引查找）
4. 有tempdb溢出数据警告
5. 逻辑读取接近128k
6. Sentry 显示 3 个缺失的 JOIN 谓词，INSERT INTO @ValidRows....但我不知道如何识别它们。

所涉及的表上有索引，从我看来它们似乎足够了。但是，我看到许多索引扫描在计划中被称为问题区域（黄色突出显示）

以下是实际执行计划的链接：https://www.brentozar.com/pastetheplan/ ?id=S1TN4NOS9

CREATE VIEW [dbo].[DailyNotePublishedContentView]
WITH SCHEMABINDING
AS 
SELECT
    T.Id AS DailyNoteContentId,
    T.DateModified,
    T.ModifiedBy,
    T.Region,
    T.DateAdded,
    T.CreatedBy,
    V.Id AS VersionId,
    V.DateAdded AS VersionDateAdded,
    V.CreatedBy as VersionCreatedBy,
    V.ContentType,
    V.DateDue,
    V.IsPrivate,
    V.ProjectId,
    V.PublishDate,
    V.AuthorTeamId, …

我有一个我想要改进的程序，它使用这个 where 子句：

WHERE   p.PlatformId = ISNULL(@PlatformId, p.PlatformId)
and p.PayeeStsId     = 1
and p.PlatformPayeeId   = ISNULL(@platformPayeeId, p.PlatformPayeeId)
and pba.PayeeBankStsId=1
and a.Gcid = ISNULL(@Gcid, a.Gcid)

这ISNULL给我使用索引带来了问题，我怎样才能避免使用这种格式ISNULL？

p.PlatformId = ISNULL(@PlatformAccountId, p.PlatformId)

这种格式导致执行计划进行索引扫描。

将数据库放在一个服务器实例上的一个常见问题是它们都共享相同的 tempdb。是否可以为单独的数据库分配 tempdb 文件/和文件组。资源调控器允许这样做吗？

数据库 1，只能访问 tempdb 中的一个文件/文件组 1。

数据库 2，只能访问 tempdb 中的一个文件/文件组 2。

关于 SQLOS 的执行模型（RUNNING 状态、RUNNABLE 队列、WAITER 列表），当当前正在进行 RAM 中页面的逻辑读取时，任务的状态是什么？

如果是 WAITER 列表，最流行的等待类型是什么？

我可以以某种方式测量此类操作所需的时间吗？

我知道很多逻辑读取会减慢您的查询速度，很多表/索引扫描（已经位于缓冲池中）会减慢您的查询速度 - 我只想知道它们如何出现在统计信息/dmv 中或如何将其与其他数据区分开来“经典”等待类型。

我们正在研究 SSIS Lookup 和 T-SQL Join 之间的性能差异。我们要连接两个表；表位于同一个 SQL 服务器实例中，不同的数据库中。

我怀疑对于小表连接，差异很小或可以忽略不计。在这种情况下，我们的团队更喜欢 T-SQL，它比编写图表更容易编码/脚本。此外，在 DevOps 角度，我们可以在 DB 项目中编译/构建脚本；不幸的是，SSIS 不会正确编译 T-SQL，我可以在 SSIS 执行 SQL 语句中编写“testabcd”，并且该项目仍将构建/编译。

但是，对于需要更长时间处理的大量行，什么更快？具有索引和统计信息的 T-SQL 或全部在内存中进行的 SSIS？

我以不同的观点阅读了这些文章，团队正在努力达成共识。

https://derekdb.wordpress.com/2012/03/13/ssis-lookup-or-t-sql-join/ http://www.sqlservercentral.com/blogs/jamesserra/2011/08/29/when- to-use-t_2D00_sql-or-ssis-for-etl/

让我们假设，T-SQL 引擎和 SSIS 提供相同的硬件：CPU 和内存。鉴于相同的规格，我想从内部算法的角度了解性能速度。

当 nvarchar(max) 列只有几 MB 数据时，我在表上的单行插入/更新语句上遇到性能不佳的情况。

这是我的表结构：

CREATE TABLE [dbo].[tbl_set_Cart](
    [ID] [int] NOT NULL,
    [AS400_CUSTOMER_COD] [nvarchar](50) NOT NULL,
    [AS400_LISTIN] [int] NOT NULL,
    [VALUE] [nvarchar](max) NOT NULL,
    [DELIVERY_COSTS] [nvarchar](max) NOT NULL,
    [ITEMS_COUNT] [int] NOT NULL,
    [ITEMS] [nvarchar](max) NOT NULL,
    [KIND] [int] NOT NULL,
    [CHECKOUT_INFO] [nvarchar](max) NOT NULL,
    [ISSUES] [nvarchar](max) NOT NULL,
    [LAST_CHECK] [datetime] NOT NULL,
    [USER_ID] [int] NOT NULL,
    [IMPERSONATED_USER_ID] [int] NOT NULL,
    [OVERRIDE_PRICES] [bit] NOT NULL,
    [HAS_ISSUE] [bit] NOT NULL,
    [IS_CONFIRMED] [bit] NOT NULL,
    [IS_COLLECTED] [bit] NOT NULL,
    [_METADATA] [nvarchar](max) NOT …

我在 Windows Server 上运行 SQL Server 2016 企业版，内存为 128 GB。在安装过程中，我为 SQL 服务器分配了 124 GB，因为该服务器仅专用于 SQL，其余的留给操作系统。

现在，当 DML/DDL 查询运行或任何维护计划运行时，每个任务管理器的内存消耗飙升至 97%。但。PLE 保持良好状态（即 > 300 秒）并且未观察到性能问题。一旦作业和查询完成，SQL 在相当长一段时间内不会释放内存，我必须进行内存上限或等待一整天才能释放内存。

除了内存上限之外，还有什么方法可以让 SQL Server 释放内存以及为什么 SQL 无法在所有作业完成后立即释放内存。

将较大的 varchar 变量放入小列是否存在任何性能问题？我在执行计划中没有看到任何性能差异。只想验证。

例子，

create table dbo.Product
(
    ProductId int identity(1,1),
    ProductName varchar(25),
    ProductDescription varchar(255),

    constraint pk_ProductId Primary Key (ProductId)
)

案例 1 大 varchar(4000)

declare @ProductNameVar varchar(4000),@ProductDescriptionVar varchar(4000)

set @ProductNameVar = 'Table'
set @ProductDescriptionVar ='manufactured , oak table, round edges..' 

INSERT INTO dbo.Product(ProductName, ProductDescription) 
VALUES (@ProductNameVar, @ProductDescriptionVar)

案例 2 小型 Varchars

declare @ProductNameVar varchar(25),@ProductDescriptionVar varchar(255)

set @ProductNameVar = 'Table'
set @ProductDescriptionVar ='manufactured , oak table, round edges..' 

INSERT INTO dbo.Product(ProductName, ProductDescription) 
VALUES (@ProductNameVar, @ProductDescriptionVar)