标签: performance

我们使用的是 PostgreSQL v8.2.3。

涉及的表有：EMPLOYEE和EMAILLIST。

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2 个表以这样的方式连接，如果 EMPLOYEE.EMAIL1 或 EMPLOYEE.EMAIL2 没有匹配的条目，则将返回这些行。

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

列EMAIL是VARCHAR（256）的EMAILLIST表索引。现在，响应时间是 14 秒。

表数统计：目前EMPLOYEE有165,018条记录，EMAILLIST有1,810,228条记录，未来两个表都有望增长。

1. 索引 VARCHAR …

当我运行以下代码时，它需要 22.5 分钟并进行 1.06 亿次读取。但是，如果我只运行内部 select 语句本身，它只需要 15 秒并执行 264k 读取。作为旁注，选择查询不返回任何记录。

知道为什么IF EXISTS它会运行更长时间并进行更多读取吗？我还更改了 select 语句，SELECT TOP 1 [dlc].[id]并在 2 分钟后将其杀死。

作为临时修复，我已将其更改为执行 count( * ) 并将该值分配给变量@cnt。然后它做一个IF 0 <> @cnt声明。但我认为EXISTS会更好，因为如果在 select 语句中返回了记录，它会在找到至少一条记录后停止执行扫描/搜索，而count(*)将完成完整查询。我错过了什么？

IF EXISTS
   (SELECT [dlc].[ID]
   FROM TableDLC [dlc]
   JOIN TableD [d]
   ON [d].[ID] = [dlc].[ID]
   JOIN TableC [c]
   ON [c].[ID] = [d].[ID2]
   WHERE [c].[Name] <> [dlc].[Name])
BEGIN
   <do something>
END

对于我尝试优化的中等复杂查询，我注意到删除TOP n子句会更改执行计划。我猜想，当查询包含TOP n数据库引擎时，会运行查询而忽略该TOP子句，然后最后将结果集缩小到请求的n行数。图形执行计划似乎表明情况确实如此——TOP是“最后”一步。但似乎还有更多事情发生。

我的问题是，TOP n 子句如何（以及为什么）影响查询的执行计划？

这是我的情况的简化版本：

查询匹配来自两个表 A 和 B 的行。

如果没有该TOP子句，优化器估计将有来自表 A 的 19k 行和来自表 B 的 46k 行。返回的实际行数是 A 的 16k 和 B 的 13k。哈希匹配用于连接这两个结果集总共 69 行（然后应用排序）。此查询发生得非常快。

当我添加TOP 1001优化器时不使用哈希匹配；相反，它首先对表 A 的结果进行排序（与 19k/16k 相同的估计值/实际值）并对表 B 执行嵌套循环。表 B 的估计行数现在为 1，奇怪的是TOP n直接影响对 B 的估计执行次数（索引搜索） - 它似乎总是2n+1，或者在我的情况下是 2003 年。如果我改变，这个估计会相应地改变TOP n。当然，由于这是嵌套连接，因此实际执行次数为 16k（表 A 中的行数），这会减慢查询速度。

实际场景有点复杂，但这捕获了基本思想/行为。两个表都使用索引查找进行搜索。这是 SQL Server 2008 R2 企业版。

我有一个很烦人的问题。我想使用 INNODB 作为我的主要数据库引擎并放弃 MyISAM，因为我需要前者来使用 galera-cluster 进行冗余。

我将newbb_post表复制（描述如下）到一个名为的新表newbb_innopost并将其更改为 InnoDB。每个表当前都保存5,390,146条目。

在新启动的数据库上运行这些选择（因此此时不涉及缓存！）数据库产生以下结果（省略完整的输出，请注意我什至不要求数据库对结果进行排序）：

SELECT post.postid, post.attach FROM newbb_post AS post WHERE post.threadid = 51506;

.
.
| 5401593 | 0 |
| 5401634 | 0 |
+---------+--------+
62510 行（0.13 秒）

SELECT post.postid, post.attach FROM newbb_innopost AS post WHERE post.threadid = 51506;
.
.
| 5397410 | 0 |
| 5397883 | 0 |
+---------+--------+
62510 行（1 分 22.19 秒）

0.13 秒到 86.19 秒 (!)

我想知道为什么会这样。我确实在 Stackexchange 上阅读了一些涉及 InnoDB …

如果我有一个UPDATE实际上没有改变任何数据的语句（因为数据已经处于更新状态）。在WHERE子句中进行检查以防止更新是否有任何性能优势？

例如，以下 UPDATE 1 和 UPDATE 2 之间的执行速度是否有任何差异：

CREATE TABLE MyTable (ID int PRIMARY KEY, Value int);
INSERT INTO MyTable (ID, Value)
VALUES
    (1, 1),
    (2, 2),
    (3, 3);

-- UPDATE 1
UPDATE MyTable
SET
    Value = 2
WHERE
    ID = 2
    AND Value <> 2;
SELECT @@ROWCOUNT;

-- UPDATE 2
UPDATE MyTable
SET
    Value = 2
WHERE
    ID = 2;
SELECT @@ROWCOUNT;

DROP TABLE MyTable;

我问的原因是我需要行数来包含未更改的行，所以我知道如果 ID 不存在是否进行插入。因此，我使用了 UPDATE 2 表单。如果使用 UPDATE 1 表单有性能优势，是否有可能以某种方式获得我需要的行数？

我们在虚拟 Windows 2008 R2 服务器上运行 SQL Server 2008 R2 (10.50.1600)。在将 CPU 从 1 核升级到 4 核并将 RAM 从 4 GB 升级到 10 GB 后，我们注意到性能更差。

我看到的一些观察：

1. 运行时间 <5 秒的查询现在需要 >200 秒。
2. CPU 被锁定在 100，而 sqlservr.exe 是罪魁祸首。
3. 一个有 460 万行的表上的 select count(*) 花费了 90 多秒。
4. 服务器上运行的进程没有改变。唯一的变化是增加了 cpu 和 ram。
5. 其他 sql 服务器有一个静态分页文件，该服务器设置为自行管理它。

有没有人遇到过这个问题？

根据 sp_BlitzErik，我跑了

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

给我这些结果。

这是一个纯理论问题。假设我在多台服务器上部署了一个应用程序。

1. 负载均衡器，
2. 多个/可扩展的应用程序服务器
3. 一个（单一的）数据库服务器（目前）

在前两个部分，我知道要寻找什么。但是数据库服务器呢？我应该寻找什么样的硬件？

• CPU 频率与数据库服务器相关吗？
• 多核 CPU 是否相关？
• RAM比CPU重要吗？

PS：假设选择的数据库是 MySQL 或 PostgreSQL。

我在数据库中有相当数量的数据。我有格式良好的表格和它们之间的良好关系，我的数据中有一些冗余。但是我应该在规范化方面走多远？过多的标准化是否存在性能缺陷？

根据我对 PostgreSQL 9.2 中的空闲连接问题的评论，一些未提交的事务（可能与其中一些空闲连接有关）可能会导致一些性能问题。

确定是否存在未提交的事务的好方法是什么（如果有办法知道它们所在的连接是否空闲，则加分）？

非常感谢！

我们开始为 VMware 中的 SQL Server 2016 节点虚拟集群提供一组物理服务器。我们将使用企业版许可证。

我们计划设置 6 个节点，但关于在 CPU 时钟速度与 CPU 核心数方面配置物理服务器的理想方式存在一些争论。

我知道这在很大程度上取决于交易量和存储的数据库数量以及其他特定于软件的因素，但是否有建议的一般经验法则？

例如，双 8 核 3.2 GHz 物理服务器（16 核）是否比双 16 核 2.6 GHz 服务器（32 核）更优惠？

有没有人遇到过进一步深入研究此类主题的白皮书？