标签: performance

我有一个非常简单的查询：

SELECT COUNT(*)
FROM messages
INNER JOIN users ON messages.user_id = users.user_id

加入需要 1146 毫秒，没有加入需要 220 毫秒（220 毫秒对我来说仍然很慢）。在包含 1,000,000+ 行的消息表上进行测试。

我在两个表 ( message_idand user_id)上都设置了主键，并设置了连接messages.user_idand的外键users.user_id。

此查询的原因是为分页系统提供记录总数。

我还能做些什么来加速查询？

SELECT * 
FROM   SameLogTable
WHERE  ID_Table IN (SELECT ID_Table-1
                    FROM   SameLogTable
                    WHERE  <SameCondition>) OR
       ID_Table IN (SELECT ID_Table
                    FROM   SameLogTable
                    WHERE  <SameCondition>) OR
       ID_Table IN (SELECT ID_Table+1
                    FROM   SameLogTable
                    WHERE  <SameCondition>)

此查询在日志记录表上运行，我想选择特定事件，以及这些事件之前和之后的事件。这个解决方案感觉丑陋且效率低下，为此编写更好的方法是什么？

示例：如果我对 LogTable 的 ID 为 4 和 23 的行感兴趣，我想得到以下结果：

ID    Column1    Column2    ...
3     ...        ...
4     ...        ...
5     ...        ...
22    ...        ...
23    ...        ...
24    ...        ...

这些都是来自同一 LogTable 的所有行，除了我使用 WHERE 指定第 4 行和第 23 行，并且我希望 Select 自动返回第 3,5 行（第 4 行）和第 22、24 行（第 …

在 SQL Sever 中更新时，我的理解是删除整行然后重新创建（这就是您获得新时间戳的原因）。那么，如果您更新 1 个字段或 500 个字段，更新的性能是否会发生变化？

我怀疑如果有索引列，因为它必须更新索引，服务器会执行更多的“工作”。回答时，假设没有触发器。

我们的软件产品目前在 Windows 7 上发布，使用 Postgres 8.3 作为其数据库。在一个繁忙的站点上，可能有 24 个自动化系统每分钟生成 100 行（x100 列），3-10 个人类客户查看大约 1000 行的子集——所有这些都是一次检索，增量更新每分钟左右查询 pk + 时间戳并检索相关的新行。有一些辅助表，但此表具有主要活动。

作为有限的多主系统的第一步（以帮助地理上分离的团队），我们实施了到 9.3 的升级。性能不是第一要务，因此并未真正对其进行分析。随着发布时间的到来，管理层决定暂时放弃 9.3，理由是担心可能会降低性能和缺乏测试资源。我确信性能问题很荒谬，所以我做了一些 PgBench 测试。

使用 9.3 的 pgbench，我交替连接到本地 8.3 和 9.3 安装（不同的端口号）。我已经在这个谷歌驱动器电子表格中捕获了我的结果，但总结是通常 8.3 击败 9.3。9.3 仅在原始插入性能方面获胜。

我们对 postgresql.conf 文件进行了一些自定义，我通常将其保留在 8.3 到 9.3 之间，我将列出非默认设置

max_connections = 1000
shared_buffers = 320MB
temp_buffers = 80MB
max_prepared_transactions = 50    #8.3 only, 9.3 left at 0 (not sure why)
max_fsm_pages = 204800            #8.3 only, 9.3 doesn't have setting
autovacuum_max_workers = 30

那么，这只是进步的代价，还是我应该在 9.3 …

我们在表 Tbl 中有一个聚集索引，顺序为 A、B、C。编写一个查询是否有意义

WHERE A = @a, B = @b, C = @c

或者它会和

WHERE C = @c, B = @b, A = @a

查询顺序对聚集索引有意义吗？

我有一个包含 700,000 行的表，其中包含一个字符串 id 字段，其值例如 rec-232276-dup-0 和 rec-354240-org。rec- 是常数，但 id 的其他部分可以改变。

我想拆分这个字符串，以便我只有整数部分和一个布尔值，具体取决于下一部分是否等于 dup 或 org（1 表示 dup，0 表示 org），我将其插入回表中。

我编写了以下循环来执行此操作，并且在功能上它运行良好，但是当我在完整的 700,000 行上运行它时，它需要非常长的时间（+12 小时和计数）。

我做错了什么导致它花费这么多时间？这是导致这种情况的字符串操作吗？我可以做些什么来改善这种情况？

谢谢你的帮助。

我的脚本如下：

select id
into #ControlTable 
from [dbo].[original_test_dataset]

declare @TableID varchar(20)

while exists (select * from #ControlTable)
begin

   select @TableID = (select top 1 id
                    from #ControlTable
                    order by id asc)

   declare @duplicate bit
   declare @id_only varchar(10)

   --1. Find id only
   -- Trim off rec-
   set @id_only = REPLACE(@TableID,'rec-','')
   -- Find position of first - and …

我一直在努力使这个查询更有效地工作。

我发现 where 子句中 Or 的数量是这个查询中最大的问题。此查询位于存储过程中。

我到了我能想到的唯一选择的地步。：

• 为所有不同的入站参数可能性创建 16 种不同的查询。
• 创建动态 sql 查询，但我认为这不会更快
• 恢复到字符串 sql，但我不喜欢这样做，因为它们的执行速度不如存储过程。

我相信其他人以前也遇到过这个问题。查询性能在大约一秒或更短的时间内开始并不可怕，但在某些情况下，它被多次命中，导致长达 5 或 6 秒的延迟。

查询如下。：

DECLARE @PERSON_ID AS INT
DECLARE @ITEM_ID AS INT
DECLARE @ITEM_VERSION AS INT
DECLARE @ITEM_SUB_NAME AS VARCHAR(250)
DECLARE @ITEM_SUB_SUB_NAME AS VARCHAR(250)

--DEFAULTS
SET @PERSON_ID = 0
SET @ITEM_ID = 0
SET @ITEM_VERSION = 1
SET @ITEM_SUB_NAME = NULL
SET @ITEM_SUB_SUB_NAME = NULL

    SELECT ID, PERSON_ID, 
           ISNULL(ITEM_VERSION, 1) AS ITEM_VERSION,
           ISNULL(ITEM_SUB_NAME, '') AS 'ITEM_SUB_NAME',
           ISNULL(ITEM_SUB_SUB_NAME, '') AS 'ITEM_SUB_SUB_NAME',
           ISNULL(ITEM_DATE, '1/1/1900') AS …

我有以下查询。出于性能优化的原因，我被要求用 SQL 中的 ISNULL 函数替换逻辑。我怎样才能做到这一点？请指教。

                   SELECT CASE 
                               WHEN tb1.[tag-value] IS NOT NULL THEN tb1.[tag-value]
                               ELSE 'N/A'
                          END     AS [tag-value]
                   FROM   @AgentTableFilt ta

我有这个查询运行了很长时间

    (@P0 nvarchar(4000))

select emaildmo0_.Id as Id7_
    ,emaildmo0_.CreatedDate as CreatedD2_7_
    ,emaildmo0_.EmailAddress as EmailAdd3_7_
    ,emaildmo0_.EmailType_Id as EmailType4_7_
    ,emaildmo0_.isPreferedEmail as isPrefer5_7_
    ,emaildmo0_.ProfileId as ProfileId7_
    ,emaildmo0_.UpdatedDate as UpdatedD6_7_
from dbo.Email emaildmo0_
where emaildmo0_.EmailAddress = @P0

这是执行计划

我的第一个问题为什么是索引扫描而不是索引查找

ExecutionPlan.xml 中的这两行

        <Warnings>
          <PlanAffectingConvert ConvertIssue="Cardinality Estimate" Expression="CONVERT_IMPLICIT(nvarchar(255),[emaildmo0_].[EmailAddress],0)" />
          <PlanAffectingConvert ConvertIssue="Seek Plan" Expression="CONVERT_IMPLICIT(nvarchar(255),[emaildmo0_].[EmailAddress],0)=[@P0]" />
        </Warnings>

你能帮我解释一下这个警告是什么意思吗？如果有任何建议来调整这个查询

我一直在试图弄清楚如何配置一个具有 64GB 内存（远大于数据库）的 PostgreSQL 实例，以及我是否应该选择更多内核或更快的内核。（假设通行证总数在 15- 20% 的差异）

一些额外的细节：最密集的 READ 将是通过大量 UNION 的 JSONB。本例中的操作系统是 CentOS 6。