标签: performance

我发现以下查询可以按数据库检测 CPU 使用率，但它们显示不同的结果：

WITH DB_CPU_Stats
AS
(
    SELECT DatabaseID, DB_Name(DatabaseID) AS [DatabaseName], 
      SUM(total_worker_time) AS [CPU_Time_Ms]
    FROM sys.dm_exec_query_stats AS qs
    CROSS APPLY (
                    SELECT CONVERT(int, value) AS [DatabaseID] 
                  FROM sys.dm_exec_plan_attributes(qs.plan_handle)
                  WHERE attribute = N'dbid') AS F_DB
    GROUP BY DatabaseID
)
SELECT ROW_NUMBER() OVER(ORDER BY [CPU_Time_Ms] DESC) AS [row_num],
       DatabaseName,
        [CPU_Time_Ms], 
       CAST([CPU_Time_Ms] * 1.0 / SUM([CPU_Time_Ms]) OVER() * 100.0 AS DECIMAL(5, 2)) AS [CPUPercent]
FROM DB_CPU_Stats
--WHERE DatabaseID > 4 -- system databases
--AND DatabaseID <> 32767 -- ResourceDB
ORDER BY row_num …

我遇到了一个查询的性能问题，我似乎无法理解。

我从游标定义中提取了查询。

此查询需要几秒钟才能执行

SELECT A.JOBTYPE
FROM PRODROUTEJOB A
WHERE ((A.DATAAREAID=N'IW')
AND ((A.CALCTIMEHOURS<>0)
AND (A.JOBTYPE<>3)))
AND EXISTS (SELECT 'X'
FROM PRODROUTE B
WHERE ((B.DATAAREAID=N'IW')
AND (((((B.PRODID=A.PRODID)
AND ((B.PROPERTYID=N'PR1526157') OR (B.PRODID=N'PR1526157')))
AND (B.OPRNUM=A.OPRNUM))
AND (B.OPRPRIORITY=A.OPRPRIORITY))
AND (B.OPRID=N'GRIJZEN')))
AND NOT EXISTS (SELECT 'X'
FROM ADUSHOPFLOORROUTE C
WHERE ((C.DATAAREAID=N'IW')
AND ((((((C.WRKCTRID=A.WRKCTRID)
AND (C.PRODID=B.PRODID))
AND (C.OPRID=B.OPRID))
AND (C.JOBTYPE=A.JOBTYPE))
AND (C.FROMDATE>{TS '1900-01-01 00:00:00.000'}))
AND ((C.TODATE={TS '1900-01-01 00:00:00.000'}))))))
GROUP BY A.JOBTYPE
ORDER BY A.JOBTYPE

实际的执行计划是这样的。

注意到服务器范围的设置被设置为 MaxDOP 1，我尝试使用 maxdop 设置。

添加OPTION (MAXDOP 0)到查询或更改服务器设置会导致更好的性能和此查询计划。

但是，有问题的应用程序（Dynamics AX）不会执行这样的查询，它使用游标。 …

我正在优化一些查询。

对于下面的查询，

SET STATISTICS IO ON;
DECLARE @OrderStartDate DATETIME2 = '27 feb 2016';
DECLARE @OrderEndDate  DATETIME2 = '28 feb 2016';

SELECT  o.strBxOrderNo
        , o.sintOrderStatusID
        , o.sintOrderChannelID
        , o.sintOrderTypeID
        , o.sdtmOrdCreated
        , o.sintMarketID
        , o.strOrderKey
        , o.strOfferCode
        , o.strCurrencyCode
        , o.decBCShipFullPrice
        , o.decBCShipFinal
        , o.decBCShipTax
        , o.decBCTotalAmount
        , o.decWrittenTotalAmount
        , o.decBCWrittenTotalAmount
        , o.decBCShipOfferDisc
        , o.decBCShipOverride
        , o.decTotalAmount
        , o.decShipTax
        , o.decShipFinal
        , o.decShipOverride
        , o.decShipOfferDisc
        , o.decShipFullPrice
        , o.lngAccountParticipantID
        , CONVERT(DATE, o.sdtmOrdCreated, 120) as OrderCreatedDateConverted
FROM    tablebackups.dbo.tblBOrder o
WHERE   o.sdtmOrdCreated >= …

下面的查询执行时间超过 11 分钟。

SELECT `c`.*, 
       `e`.`name`                                                 AS `employee_name`, 
       `e`.`emp_no`, 
       `d`.`code`                                                 AS `department_code`, 
       IF(ew.code IS NOT NULL, ew.code, egw.code)                 AS shift_code, 
       IF(ew.code IS NOT NULL, ew.time_in_from, egw.time_in_from) AS time_in_from, 
       IF(ew.code IS NOT NULL, ew.time_out_to, egw.time_out_to)   AS time_out_to, 
       IF(ew.code IS NOT NULL, ew.next_day, egw.next_day)         AS next_day 
FROM   `tms_emp_badge_card` AS `c` 
       LEFT JOIN `tms_door_record_raw` AS `dr` 
              ON `c`.`card_no` = `dr`.`card_no` 
       LEFT JOIN `tms_employee` AS `e` 
              ON `c`.`emp_no` = `e`.`emp_no` 
       LEFT JOIN `tms_emp_group` AS `g` 
              ON `e`.`group_id` = `g`.`id` 
       LEFT JOIN `tms_emp_department` AS `d` …

我想使用任何可能的 RDBMS 创建一个数据库。它将有一个包含大约 150 列的表。目标是执行一些其他对象的最近邻搜索。所以它是150维空间中的NNS。

我已经尝试使用一些明显的方法，例如 L1 或 L2 距离，但当然对于包含多行的表需要花费大量时间。我还尝试查看 KD-tree（注意我没有测试它）和 PG-Strom，但它们对于多维数据并不是一个好的解决方案。

我可以使用数学方法（如 KD-tree）或技术方法（如 PG-Strom）以某种方式提高所描述的搜索速度吗？

我将尝试使用任何可以提高 NNS 速度的 RDBMS。但是 MySQL 和 PostgreSQL 是最适合我的 DBMS。

让我们做几个假设：

我有一个看起来像这样的表：

 a | b
---+---
 a | -1
 a | 17
  ...
 a | 21
 c | 17
 c | -3
  ...
 c | 22

关于我的套装的事实：

• 整个表的大小是 ~ 10 ¹⁰行。

• 我有 ~ 100k 行，列中有值a，a其他值类似（例如c）。

• 这意味着在“a”列中有大约 100k 个不同的值。

• 我的大多数查询都会读取 a 中给定值的全部或大部分值，例如select sum(b) from t where a = 'c'.

• 该表的编写方式使得连续值在物理上接近（要么按顺序写入，要么我们假设CLUSTER已在该表和列上使用a）。

• 该表很少更新，我们只关心读取速度。

• 该表相对较窄（比如每个元组约 25 个字节，+ 23 个字节的开销）。

现在的问题是，我应该使用什么样的索引？我的理解是：

• BTree我的问题是 BTree 索引会很大，因为据我所知它会存储重复值（它必须这样做，因为它不能假设表是物理排序的）。如果 BTree 很大，我最终不得不读取索引和索引指向的表部分。（我们可以使用fillfactor = 100来稍微减小索引的大小。）

• BRIN …

当使用子查询查找具有匹配字段的所有先前记录的总数时，在只有 50k 条记录的表上性能很差。如果没有子查询，查询会在几毫秒内执行。对于子查询，执行时间超过一分钟。

对于此查询，结果必须：

• 仅包括给定日期范围内的那些记录。
• 包括所有先前记录的计数，不包括当前记录，无论日期范围如何。

基本表模式

Activity
======================
Id int Identifier
Address varchar(25)
ActionDate datetime2
Process varchar(50)
-- 7 other columns

示例数据

Id  Address     ActionDate (Time part excluded for simplicity)
===========================
99  000         2017-05-30
98  111         2017-05-30
97  000         2017-05-29
96  000         2017-05-28
95  111         2017-05-19
94  222         2017-05-30

预期成绩

对于日期范围2017-05-29，以2017-05-30

Id  Address     ActionDate    PriorCount
=========================================
99  000         2017-05-30    2  (3 total, 2 prior to ActionDate)
98  111         2017-05-30    1  (2 total, 1 prior to ActionDate) …

我正在尝试对 SQL Server 2014 Enterprise 中的查询进行性能优化。

我已经在 SQL Sentry Plan Explorer 中打开了实际的查询计划，我可以在一个节点上看到它有一个Seek Predicate和一个Predicate

什么之间的区别寻求谓词和谓词？

注意：我可以看到这个节点有很多问题（例如估计行与实际行、剩余 IO），但问题与任何这些都无关。

• 我只想在一列中存储 3 个状态（如果是 2，我会使用布尔值）
• 我考虑过使用 ENUM('up', 'down', 'none') 但似乎 ENUM 占用了一些空间
• 有没有更好的方法在 PostgresQL 列中只存储 -1 0 和 1？

在我们的一位客户身上，我们的应用程序一直存在一些性能问题。它是一个 .NET 3.5 Web 应用程序，它使用和更新 SQL Server 数据库上的数据。目前我们的生产环境由一台 Windows 2008 R2 机器作为前端和一个 SQL Server 2008 R2 集群在后端组成。我们的应用程序使用 COM+ 和 MSDTC 连接到数据库。

正在发生的事情是这样的：我们的最终用户有时会抱怨应用程序运行缓慢。有些页面需要比预期更长的时间来加载。在试图弄清楚发生了什么时，我设法在数据库端发现了一些可能导致性能下降的奇怪行为。我注意到有时有一些 SQL 语句需要更多的时间来运行，这超出了预期。我设法使用探查器跟踪（使用 TSQL_Duration 模板）来识别长时间运行的查询，从而识别出其中的一些语句（主要是调用我们的一些应用程序的存储过程）。

问题是，当我直接在 SQL Management Studio 上的数据库上运行这些存储过程时，有时它们确实需要很长时间（大约 7/8 秒），有时它们很快（不到 1 秒）。我不知道为什么会发生这种情况，这让我抓狂，因为 SQL 机器（4 核，32 GB）没有被任何其他应用程序使用，并且这些查询不应该花这么长时间运行。

不是 DBA 或 SQL Server 专家，我一直在尝试查看一些可以帮助我理解问题的东西。以下是我为尝试解决问题而采取的步骤以及我迄今为止发现的内容：

• 应用程序调用的所有 TSQL 代码都编写在存储过程中。
• 我在 SQL Server Profiler 上发现了一些长时间运行的查询，但是当我在 Management Studio 上运行这些查询时，它们要么需要很长时间才能运行（从 4 秒到 10 秒），要么运行得很快（不到 1 秒）。我正在使用参数中传递的相同数据运行完全相同的查询。这些查询主要是带有选择语句的存储过程。
• 我尝试查看等待和队列统计信息以尝试确定是否有进程在等待某些资源。我运行了以下查询：

WITH Waits AS
    (SELECT
        wait_type,
        wait_time_ms / 1000.0 AS WaitS,
        (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS, …