标签: performance

我想从 6 列中获取最小值。

到目前为止，我已经找到了三种方法来实现这一点，但我担心这些方法的性能，并想知道哪种方法对性能更好。

第一种方法是使用大 case 语句。这是一个包含 3 列的示例，基于上面链接中的示例。我的案例陈述会更长，因为我将查看 6 列。

Select Id,
       Case When Col1 <= Col2 And Col1 <= Col3 Then Col1
            When Col2 <= Col3 Then Col2 
            Else Col3
            End As TheMin
From   MyTable

第二种选择是将UNION运算符与多个选择语句一起使用。我会把它放在一个接受 Id 参数的 UDF 中。

select Id, dbo.GetMinimumFromMyTable(Id)
from MyTable

和

select min(col)
from
(
    select col1 [col] from MyTable where Id = @id
    union all
    select col2 from MyTable where Id = @id
    union all
    select col3 …

我知道存储过程通过执行路径更有效（比应用程序中的内联 sql）。然而，当被按下时，我对原因不是很了解。

我想知道对此的技术推理（以稍后我可以向某人解释的方式）。

谁能帮我制定一个好的答案？

问这个问题，特别是针对 Postgres，因为它对 R 树/空间索引有很好的支持。

我们有下表，其中包含单词及其频率的树结构（嵌套集模型）：

lexikon
-------
_id   integer  PRIMARY KEY
word  text
frequency integer
lset  integer  UNIQUE KEY
rset  integer  UNIQUE KEY

和查询：

SELECT word
FROM lexikon
WHERE lset BETWEEN @Low AND @High
ORDER BY frequency DESC
LIMIT @N

我认为覆盖索引(lset, frequency, word)会很有用，但我觉得如果范围内的lset值太多，它可能表现不佳(@High, @Low)。

(frequency DESC)有时，当使用该索引的搜索早期产生@N与范围条件匹配的行时，一个简单的索引也可能就足够了。

但似乎性能在很大程度上取决于参数值。

有没有办法让它快速执行，不管范围(@Low, @High)是宽还是窄，也不管高频词是否幸运地在（窄）选择的范围内？

R-tree/空间索引有帮助吗？

添加索引，重写查询，重新设计表，没有限制。

我是代理键的粉丝。我的发现存在确认偏倚的风险。

我在这里和http://stackoverflow.com 上看到的许多问题都使用自然键而不是基于IDENTITY()值的代理键。

我的计算机系统背景告诉我，对整数执行任何比较运算都比比较字符串快。

这个评论让我怀疑我的信念，所以我想我会创建一个系统来研究我的论点，即整数比字符串更快，用作 SQL Server 中的键。

由于小数据集可能几乎没有可辨别的差异，我立即想到了一个两表设置，其中主表有 1,000,000 行，而辅助表在主表中的每一行有 10 行，总共有 10,000,000 行。次要表。我的测试的前提是创建两组这样的表，一组使用自然键，一组使用整数键，并在简单的查询上运行计时测试，例如：

SELECT *
FROM Table1
    INNER JOIN Table2 ON Table1.Key = Table2.Key;

以下是我作为测试台创建的代码：

USE Master;
IF (SELECT COUNT(database_id) FROM sys.databases d WHERE d.name = 'NaturalKeyTest') = 1
BEGIN
    ALTER DATABASE NaturalKeyTest SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE NaturalKeyTest;
END
GO
CREATE DATABASE NaturalKeyTest 
    ON (NAME = 'NaturalKeyTest', FILENAME = 
        'C:\SQLServer\Data\NaturalKeyTest.mdf', SIZE=8GB, FILEGROWTH=1GB) 
    LOG ON (NAME='NaturalKeyTestLog', FILENAME = 
        'C:\SQLServer\Logs\NaturalKeyTest.mdf', SIZE=256MB, FILEGROWTH=128MB); …

我正在运行 PostgresSQL 9.2 并且有一个 12 列的关系，大约有 6,700,000 行。它包含 3D 空间中的节点，每个节点都引用一个用户（创建它的人）。要查询哪个用户创建了多少个节点，我执行以下操作（添加explain analyze以获取更多信息）：

EXPLAIN ANALYZE SELECT user_id, count(user_id) FROM treenode WHERE project_id=1 GROUP BY user_id;
                                                    QUERY PLAN                                                         
---------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=253668.70..253669.07 rows=37 width=8) (actual time=1747.620..1747.623 rows=38 loops=1)
   ->  Seq Scan on treenode  (cost=0.00..220278.79 rows=6677983 width=8) (actual time=0.019..886.803 rows=6677983 loops=1)
         Filter: (project_id = 1)
 Total runtime: 1747.653 ms

如您所见，这大约需要 1.7 秒。考虑到数据量，这还算不错，但我想知道这是否可以改进。我尝试在用户列上添加 BTree 索引，但这没有任何帮助。

您有其他建议吗？

为了完整起见，这是完整的表定义及其所有索引（没有外键约束、引用和触发器）：

    Column     |           Type           |                      Modifiers                    
---------------+--------------------------+------------------------------------------------------
 id            | bigint                   | not null default nextval('concept_id_seq'::regclass)
 user_id       | bigint …

考虑 SQL Server 2014 中的以下查询计划：

在查询计划中，自联接ar.fId = ar.fId产生 1 行的估计值。然而，这是一个逻辑上不一致的估计：ar有20,608行和只有一个不同的值fId（准确地反映在统计数据中）。因此，此连接会生成行 ( ~424MMrows)的完整叉积，从而导致查询运行数小时。

我很难理解为什么 SQL Server 会得出一个很容易证明与统计数据不一致的估计值。有任何想法吗？

初步调查和其他细节

根据 Paul在此处的回答，用于估计连接基数的 SQL 2012 和 SQL 2014 启发式方法似乎都应该可以轻松处理需要比较两个相同直方图的情况。

我从跟踪标志 2363 的输出开始，但不太容易理解。请问下面的片段意味着SQL Server在比较直方图fId和bId以估计选择性的只加入使用fId？如果是这样，那显然是不正确的。还是我误读了跟踪标志输出？

Plan for computation:
  CSelCalcExpressionComparedToExpression( QCOL: [ar].fId x_cmpEq QCOL: [ar].fId )
Loaded histogram for column QCOL: [ar].bId from stats with id 3
Loaded histogram for column QCOL: [ar].fId from stats with id 1 …

我想针对其他一些分支（例如 Percona 服务器、MariaDB 以及可能的其他分支）对 MySQL 服务器 rpm 进行性能测试（又名烘焙）。我希望通过提出这个问题，我可以更好地理解设置适当性能测试背后的方法。我计划使用 sysbench 来运行我的实际测试，但我对任何事情都持开放态度。

1. 我应该采取哪些步骤来确保测试结果在一个苹果对苹果的比较中并且只有 RDBMS 是变体？
2. 我从哪里开始？
3. 我如何评估结果？
4. 你能给我什么建议？

我的应用程序是非常数据库密集型的。目前，我正在运行 MySQL 5.5.19 并使用 MyISAM，但我正在迁移到 InnoDB。剩下的唯一问题是校验和性能。

我的应用程序CHECKSUM TABLE在高峰时间每秒执行大约 500-1000 条语句，因为客户端 GUI 不断轮询数据库以进行更改（它是一个监控系统，因此必须非常敏感且快速）。

使用 MyISAM，可以在表修改时预先计算实时校验和，并且速度非常快。但是，InnoDB 中没有这样的东西。所以，CHECKSUM TABLE很慢。

我希望能够检查表的最后更新时间，不幸的是，这在 InnoDB 中也不可用。我现在卡住了，因为测试表明应用程序的性能急剧下降。

更新表的代码行太多了，因此在应用程序中实现逻辑来记录表更改是不可能的。

是否有任何快速方法来检测 InnoDB 表中的变化？

我可能在标题中问错了问题。以下是事实：

在我们基于 Django 的站点的管理界面上进行客户查询时，我的客户服务人员一直抱怨响应速度慢。

我们使用的是 Postgres 8.4.6。我开始记录慢查询，并发现了这个罪魁祸首：

SELECT COUNT(*) FROM "auth_user" WHERE UPPER("auth_user"."email"::text) LIKE UPPER(E'%deyk%')

此查询的运行时间超过 32 秒。下面是 EXPLAIN 提供的查询计划：

QUERY PLAN
Aggregate  (cost=205171.71..205171.72 rows=1 width=0)
  ->  Seq Scan on auth_user  (cost=0.00..205166.46 rows=2096 width=0)
        Filter: (upper((email)::text) ~~ '%DEYK%'::text)

因为这是 Django ORM 从 Django Admin 应用程序生成的 Django QuerySet 生成的查询，所以我无法控制查询本身。索引似乎是合乎逻辑的解决方案。我尝试创建一个索引来加快速度，但没有任何区别：

CREATE INDEX auth_user_email_upper ON auth_user USING btree (upper(email::text))

我究竟做错了什么？我怎样才能加快这个查询？

时不时地运行 Microsoft SQL Server Profiler，它建议我创建一堆新的索引和统计信息（“... 97% 估计改进...”）。

根据我的理解，每个添加的索引都可以使 SQLSELECT查询更快，但也会使UPDATEorINSERT查询变慢，因为必须调整索引。

我想知道的是，我什么时候有“太多”的索引/统计信息？

也许对此没有明确的答案，但有一些经验法则。