标签: performance

SQL Server 2012 和 2016 标准：

如果我将if-else逻辑放在存储过程中以执行代码的两个分支之一，取决于参数的值，引擎是否缓存最新版本？

如果在接下来的执行中，参数的值发生了变化，它是否会重新编译并重新缓存存储过程，因为必须执行代码的不同分支？（此查询的编译成本非常高。）

我有一个查询，它使用 select 运行得更快，top 100而不使用top 100. 返回的记录数为 0。你能解释一下查询计划的差异或分享解释这种差异的链接吗？

没有top文本的查询：

SELECT --TOP 100
*
FROM InventTrans
     JOIN
     InventDim
     ON InventDim.DATAAREAID = 'dat' AND 
        InventDim.INVENTDIMID = InventTrans.INVENTDIMID
WHERE InventTrans.DATAAREAID = 'dat' AND 
      InventTrans.ITEMID = '027743' AND 
      InventDim.INVENTLOCATIONID = '???? ?????' AND 
      InventDim.ECC_BUSINESSUNITID = '?????????';

上面的查询计划（没有top）：

https://pastebin.com/cbtJpxFf

IO 和 TIME 统计信息（没有top）：

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = …

我正在运行一个查询，该查询给出有关内存的警告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 …

我在试图找出数据库中的一些性能问题时遇到了困难。我正在使用大量在线资源来了解要监控的内容以及如何解释该信息。

从上面的，我无法找到的之间有什么区别一个明确的解释pg_stat_database.tup_returned和pg_stat_database.tup_fetched。

在 pgAdmin4 中，有一个漂亮的图表叫做“Tuples out”，其中对比了这两个概念，但我不知道如何解释这些信息。在官方文档中只说：

• tup_returned: 此数据库中查询返回的行数
• tup_fetched: 此数据库中查询获取的行数

“获取”和“返回”究竟是什么意思？

我正在使用 postgresql 10。

给定以下堆表，其中包含 400 行，编号从 1 到 400：

DROP TABLE IF EXISTS dbo.N;
GO
SELECT 
    SV.number
INTO dbo.N 
FROM master.dbo.spt_values AS SV
WHERE 
    SV.[type] = N'P'
    AND SV.number BETWEEN 1 AND 400;

以及以下设置：

SET NOCOUNT ON;
SET STATISTICS IO, TIME OFF;
SET STATISTICS XML OFF;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

以下SELECT语句在大约6 秒内完成（demo、plan）：

DECLARE @n integer = 400;

SELECT
    c = COUNT_BIG(*) 
FROM dbo.N AS N
CROSS JOIN dbo.N AS N2
CROSS JOIN dbo.N …

有哪些有效的方法可以对数据库操作执行编程性能测试，尤其是在数据库本身不提供专用工具的环境中？

例如，在 Google App Engine 中，整个页面加载被评估为一项操作，其中可能包括特定的数据库操作。SQLite 和其他集成数据库中也可能存在此问题。由于很难完全抽象需要测试的（等价的）选择和插入，是否有任何推荐的数据库工具来对这些类型的查询执行更彻底的诊断？

由于 RAM 的限制，是否可以让 InnoDB 使用与 MyISAM 相同的索引而不是聚集索引，同时获得其并发性能的好处？

认为这已通过以下链接解决 - 解决方法有效 - 但补丁没有。与 Microsoft 支持一起解决。

http://support.microsoft.com/kb/2606883

好的，所以我有一个问题，我想把它扔给 StackOverflow，看看是否有人有想法。

请注意，这是 SQL Server 2008 R2

问题：启用触发器时，从包含 15000 条记录的表中删除 3000 条记录需要 3-4 分钟，禁用触发器时只需 3-5 秒。

表设置

我们将称为 Main 和 Secondary 的两个表。Secondary 包含我要删除的项目记录，因此当我执行删除操作时，我会加入到 Secondary 表中。在删除语句之前运行一个进程，以使用要删除的记录填充辅助表。

删除声明：

DELETE FROM MAIN 
WHERE ID IN (
   SELECT Secondary.ValueInt1 
   FROM Secondary 
   WHERE SECONDARY.GUID = '9FFD2C8DD3864EA7B78DA22B2ED572D7'
);

这个表有很多列和大约 14 个不同的 NC 索引。在我确定触发器是问题之前，我尝试了很多不同的事情。

• 开启页面锁定（我们默认已关闭）
• 手动收集统计数据
• 禁用自动收集统计信息
• 已验证的索引运行状况和碎片
• 从表中删除聚集索引
• 检查执行计划（没有任何显示为缺少索引，实际删除的成本为 70%，记录的连接/合并成本为 28%

触发器

该表有 3 个触发器（插入、更新和删除操作各一个）。我修改了删除触发器的代码以使其返回，然后选择一个以查看它被触发了多少次。它在整个操作过程中只触发一次（如预期的那样）。

ALTER TRIGGER [dbo].[TR_MAIN_RD] ON [dbo].[MAIN]
            AFTER DELETE
            AS  
                SELECT 1
                RETURN

回顾

• 使用 …

我有以下表格和索引定义：

CREATE TABLE munkalap (
    munkalap_id serial PRIMARY KEY,
    ...
);

CREATE TABLE munkalap_lepes (
    munkalap_lepes_id serial PRIMARY KEY,
    munkalap_id integer REFERENCES munkalap (munkalap_id),
    ...
);

CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id);

为什么在以下查询中没有使用 munkalap_id 上的任何索引？

EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id);

QUERY PLAN
Hash Join  (cost=119.17..2050.88 rows=38046 width=214) (actual time=0.824..18.011 rows=38046 loops=1)
  Hash Cond: (ml.munkalap_id = m.munkalap_id)
  ->  Seq Scan on munkalap_lepes ml  (cost=0.00..1313.46 rows=38046 width=214) (actual time=0.005..4.574 rows=38046 loops=1)
  ->  Hash  (cost=78.52..78.52 rows=3252 …

鉴于表：

    Column    |            Type             
 id           | integer                     
 latitude     | numeric(9,6)                
 longitude    | numeric(9,6)                
 speed        | integer                     
 equipment_id | integer                     
 created_at   | timestamp without time zone
Indexes:
    "geoposition_records_pkey" PRIMARY KEY, btree (id)

该表有 2000 万条记录，相对而言，这不是一个大数目。但它会使顺序扫描变慢。

我怎样才能获得max(created_at)每个的最后一条记录 ( ) equipment_id？

我已经尝试了以下两个查询，其中有几个变体，我已经阅读了本主题的许多答案：

select max(created_at),equipment_id from geoposition_records group by equipment_id;

select distinct on (equipment_id) equipment_id,created_at 
  from geoposition_records order by equipment_id, created_at desc;

我也尝试过创建 btree 索引，equipment_id,created_at但 Postgres 发现使用 seqscan 更快。强制enable_seqscan = off也没有用，因为读取索引与 seq 扫描一样慢，可能更糟。

查询必须定期运行，始终返回最后一个。

使用 Postgres …