标签: query-performance

我一直在为不同的公司工作，我注意到他们中的一些人更喜欢拥有将所有“亲戚”加入表格的视图。但是在应用程序中，有时我们只需要使用 1 列。

那么只进行简单的选择，然后将它们“加入”到系统代码中会更快吗？

该系统可以是 php、java、asp 或任何连接到数据库的语言。

所以问题是，从服务器端（php、java、asp、ruby、python...）到数据库并运行一个查询来获取我们需要的一切或从服务器端到数据库并运行哪个更快？一次只从一个表中获取列的查询？

[敬礼]

（检查一个）

[ ] Well trained professional, [ ] Casual reader, [ ] Hapless wanderer,

我有一个（检查所有适用的）

[ ] query [ ] stored procedure [ ] database thing maybe  

运行良好（如果适用）

[ ] yesterday [ ] in recent memory [ ] at some point 

但现在突然变慢了。

我已经检查过以确保它没有被阻止，并且它不是某些长时间运行的维护任务、报告或其他带外进程的受害者。

有什么问题，我应该怎么做，我可以提供哪些信息来获得帮助？

[*Insert appropriate closing remarks*]

我有一个一定很常见的查询模式，但我不知道如何为它编写有效的查询。我想查找与“最近日期不晚于”另一个表的行相对应的表的行。

inventory比如说，我有一张表格，它代表了我在某一天持有的库存。

date       | good | quantity
------------------------------
2013-08-09 | egg  | 5
2013-08-09 | pear | 7
2013-08-02 | egg  | 1
2013-08-02 | pear | 2

和一张表，“价格”说，它保存了某一天的商品价格

date       | good | price
--------------------------
2013-08-07 | egg  | 120
2013-08-06 | pear | 200
2013-08-01 | egg  | 110
2013-07-30 | pear | 220

如何有效地获得库存表每一行的“最新”价格，即

date       | pricing date | good | quantity | price
----------------------------------------------------
2013-08-09 | 2013-08-07   | egg  | 5        | 120
2013-08-09 …

在最新版本的 PostgreSQL 中（截至 2013 年 12 月），我们能否在两个或多个内核之间共享查询以提高性能？还是我们应该获得更快的内核？

我需要计算一个日期范围内的滚动总和。为了说明，使用AdventureWorks 示例数据库，以下假设语法将完全满足我的需要：

SELECT
    TH.ProductID,
    TH.TransactionDate,
    TH.ActualCost,
    RollingSum45 = SUM(TH.ActualCost) OVER (
        PARTITION BY TH.ProductID
        ORDER BY TH.TransactionDate
        RANGE BETWEEN 
            INTERVAL 45 DAY PRECEDING
            AND CURRENT ROW)
FROM Production.TransactionHistory AS TH
ORDER BY
    TH.ProductID,
    TH.TransactionDate,
    TH.ReferenceOrderID;

遗憾的是，RANGE窗口框架范围目前在 SQL Server 中不允许间隔。

我知道我可以使用子查询和常规（非窗口）聚合编写解决方案：

SELECT 
    TH.ProductID,
    TH.TransactionDate,
    TH.ActualCost,
    RollingSum45 =
    (
        SELECT SUM(TH2.ActualCost)
        FROM Production.TransactionHistory AS TH2
        WHERE
            TH2.ProductID = TH.ProductID
            AND TH2.TransactionDate <= TH.TransactionDate
            AND TH2.TransactionDate >= DATEADD(DAY, -45, TH.TransactionDate)
    )
FROM Production.TransactionHistory AS TH
ORDER BY
    TH.ProductID,
    TH.TransactionDate, …

我一直在阅读 Kimberly Tripp 撰写的一些关于 SQL Server 计划缓存的精彩文章，例如：http : //www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/

为什么甚至有“针对临时工作负载进行优化”的选项？这不应该一直开着吗？无论开发人员是否使用 ad-hoc SQL，为什么不在每个支持它的实例上启用此选项（SQL 2008+），从而减少缓存膨胀？

我们的系统写入了大量数据（一种大数据系统）。写入性能足以满足我们的需求，但读取性能真的太慢了​​。

我们所有表的主键（约束）结构都相似：

timestamp(Timestamp) ; index(smallint) ; key(integer).

一个表可以有数百万行，甚至数十亿行，而一个读请求通常是针对特定时间段（时间戳/索引）和标记的。查询返回大约 20 万行是很常见的。目前，我们每秒可以读取大约 15k 行，但我们需要快 10 倍。这是可能的，如果是，如何？

注意： PostgreSQL 是和我们的软件一起打包的，所以不同客户端的硬件是不一样的。

它是一个用于测试的虚拟机。VM 的主机是具有 24.0 GB RAM 的 Windows Server 2008 R2 x64。

服务器规范（虚拟机 VMWare）

Server 2008 R2 x64
2.00 GB of memory
Intel Xeon W3520 @ 2.67GHz (2 cores)

postgresql.conf 优化

shared_buffers = 512MB (default: 32MB)
effective_cache_size = 1024MB (default: 128MB)
checkpoint_segment = 32 (default: 3)
checkpoint_completion_target = 0.9 (default: 0.5)
default_statistics_target = 1000 (default: 100)
work_mem = 100MB (default: 1MB)
maintainance_work_mem = 256MB …

我有一个 PostgreSQL 9.2 实例，它在 RHEL 6.3、8 核机器上运行，内存为 16GB。服务器专用于此数据库。鉴于默认的 postgresql.conf 在内存设置方面相当保守，我认为允许 Postgres 使用更多内存可能是个好主意。令我惊讶的是，遵循wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server 上的建议实际上显着降低了我运行的每个查询的速度，但在更复杂的查询中显然更明显。

我还尝试运行 pgtune，它给出了以下建议并调整了更多参数，但这并没有改变任何东西。它建议 1/4 RAM 大小的 shared_buffers 这似乎符合其他地方的建议（特别是在 PG wiki 上）。

default_statistics_target = 50
maintenance_work_mem = 960MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 11GB
work_mem = 96MB
wal_buffers = 8MB
checkpoint_segments = 16
shared_buffers = 3840MB
max_connections = 80

我尝试在更改设置后重新索引整个数据库（使用reindex database），但这也无济于事。我玩过 shared_buffers 和 work_mem。从非常保守的默认值 (128k / 1MB) 逐渐改变它们会逐渐降低性能。

我运行EXPLAIN (ANALYZE,BUFFERS)了一些查询，罪魁祸首似乎是 Hash Join 明显变慢了。我不清楚为什么。

举一些具体的例子，我有以下查询。它在默认配置下运行约 2100 毫秒，在增加缓冲区大小的配置上运行约 3300 毫秒： …

我想了解为什么在 UAT（3 秒内运行）与 PROD（23 秒内运行）上执行相同查询时会有如此巨大的差异。

UAT 和 PROD 都拥有准确的数据和索引。

询问：

set statistics io on;
set statistics time on;

SELECT CONF_NO,
       'DE',
       'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance',
       CONF_TARGET_NO
FROM   CONF_TARGET ct
WHERE  CONF_NO = 161
       AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-'
       AND ( ( REGISTRATION_TYPE = 'I'
               AND (SELECT COUNT(1)
                    FROM   PORTFOLIO
                    WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                           AND DEACTIVATED_YN = 'N') > 1 )
              OR ( REGISTRATION_TYPE = 'K'
                   AND (SELECT COUNT(1)
                        FROM   CAPITAL_MARKET
                        WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS …

我有一个相当简单的查询

SELECT TOP 1 dc.DOCUMENT_ID,
        dc.COPIES,
        dc.REQUESTOR,
        dc.D_ID,
        cj.FILE_NUMBER
FROM DOCUMENT_QUEUE dc
JOIN CORRESPONDENCE_JOURNAL cj
    ON dc.DOCUMENT_ID = cj.DOCUMENT_ID
WHERE dc.QUEUE_DATE <= GETDATE()
  AND dc.PRINT_LOCATION = 2
ORDER BY cj.FILE_NUMBER

这给了我可怕的表现（就像从不费心等待它完成一样）。查询计划如下所示：

但是，如果我删除它，TOP 1我会得到一个看起来像这样的计划，它会在 1-2 秒内运行：

下面更正 PK 和索引。

TOP 1更改查询计划这一事实并不让我感到惊讶，我只是有点惊讶它使情况变得更糟。

注意：我已经阅读了这篇文章的结果并理解了 aRow Goal等的概念。我很好奇的是如何更改查询以使其使用更好的计划。目前我正在将数据转储到临时表中，然后从中取出第一行。我想知道是否有更好的方法。

编辑对于事后阅读本文的人，这里有一些额外的信息。

• Document_Queue - PK/CI 是 D_ID，它有大约 5k 行。
• Correspondence_Journal - PK/CI 是 FILE_NUMBER，CORRESPONDENCE_ID，它有大约 140 万行。

当我开始时，没有其他索引。我在 Correspondence_Journal (Document_Id, File_Number) 上找到了一个