标签: performance

我试图解决以下问题大约一个小时，但仍然没有进一步解决。

好的，我有一张桌子（MyISAM）：

+---------+-------------+------+-----+-------------------+----------------+
| Field   | Type        | Null | Key | Default           | Extra          |
+---------+-------------+------+-----+-------------------+----------------+
| id      | int(11)     | NO   | PRI | NULL              | auto_increment |
| http    | smallint(3) | YES  | MUL | 200               |                |
| elapsed | float(6,3)  | NO   |     | NULL              |                |
| cached  | tinyint(1)  | YES  |     | NULL              |                |
| ip      | int(11)     | NO   |     | NULL              |                |
| date    | timestamp   | …

Postgres 如何触发机制规模？

我们有一个大型的 PostgreSQL 安装，我们正在尝试使用日志表和 TRIGGER(s) 来实现一个基于事件的系统。

基本上，我们希望为每个我们希望收到更新/插入/删除操作通知的表创建一个 TRIGGER。一旦触发此触发器，它将执行一个函数，该函数将简单地将一个新行（对事件进行编码）附加到一个日志表中，然后我们将从外部服务轮询该日志表。

在全面使用 Postgres TRIGGER(s) 之前，我们想知道它们是如何扩展的：我们可以在单个 Postgres 安装上创建多少个触发器？它们会影响查询性能吗？有没有人试过这个？

我有以下查询：

select databasename 
from somedb.dbo.bigtable l where databasename ='someval' and source  <>'kt'
and not exists(select 1 from dbo.smalltable c where c.source=l.source)

上述查询在三秒内完成。

如果上面的查询返回任何值，我们希望存储过程退出，因此我将其重写如下：

If Exists(
select databasename 
from somedb.dbo.bigtable l where databasename ='someval' and source  <>'kt'
and not exists(select 1 from dbo.smalltable c where c.source=l.source)
)
Begin
Raiserror('Source missing',16,1)
Return
End

但是，这需要 10 分钟。

我可以像下面这样重写上面的查询，它也可以在不到 3 秒的时间内完成：

  select databasename 
from somedb.dbo.bigtable l where databasename ='someval' and source  <>'kt'
and not exists(select 1 from dbo.smalltable c where c.source=l.source
if @@rowcount >0 …

我在 PostgreSQL 9.6 查询计划方面遇到了麻烦。我的查询如下所示：

SET role plain_user;

SELECT properties.*
FROM properties
JOIN entries_properties
  ON properties.id = entries_properties.property_id
JOIN structures
  ON structures.id = entries_properties.entry_id 
WHERE structures."STRUKTURBERICHT" != ''
  AND properties."COMPOSITION" LIKE 'Mo%'
  AND (
    properties."NAME" LIKE '%VASP-ase-preopt%'
    OR properties."CALCULATOR_ID" IN (7,22,25)
  )
AND properties."TYPE_ID" IN (6)

我为上面使用的表启用了行级安全性。

• 用set enable_nestloop = True，查询规划运行嵌套循环用约37秒的总运行时间加入：https://explain.depesz.com/s/59BR

• with set enable_nestloop = False，采用Hash Join方式，查询时间约0.3秒：https : //explain.depesz.com/s/PG8E

我VACUUM ANALYZE在运行查询之前做过，但没有帮助。

我知道这不是一个好的做法set enable_nestloop = False，对于计划者来说，还有任何其他类似的选择。但是我怎样才能“说服”规划器在不禁用嵌套循环的情况下使用散列连接？

重写查询是一种选择。

如果我在绕过 RLS 的角色下运行相同的查询，那么它的执行速度非常快。行级安全策略如下所示：

CREATE POLICY properties_select …

我们有一个大约 1TB 的大型数据库，在强大的服务器上运行 SQL Server 2014。几年来，一切都运行良好。大约 2 周前，我们进行了全面维护，其中包括： 安装所有软件更新；重建所有索引和压缩 DB 文件。但是，我们没想到在某个阶段，在实际负载相同的情况下，DB 的 CPU 使用率会增加超过 100% 到 150%。

经过大量的故障排除，我们将其缩小到一个非常简单的查询，但我们找不到解决方案。查询非常简单：

select top 1 EventID from EventLog with (nolock) order by EventID

它总是需要大约 1.5 秒！但是，使用“desc”的类似查询总是需要大约 0 毫秒：

select top 1 EventID from EventLog with (nolock) order by EventID desc

PTable 大约有 5 亿行；EventID是ASC数据类型为 bigint（身份列）的主聚集索引列（ordered ）。顶部有多个线程向表中插入数据（较大的 EventID），底部有 1 个线程删除数据（较小的 EventID）。

在 SMSS 中，我们验证了两个查询始终使用相同的执行计划：

• 聚集索引扫描；

• 估计行数和实际行数均为1；

• 估计和实际执行次数均为1；

• 估计I/O成本是8500（好像有点高）

• 如果连续运行，则两者的查询成本相同 50%。

我更新了索引统计with fullscan，问题依旧；我再次重建索引，问题似乎消失了半天，但又回来了。

我打开了 IO 统计：

set statistics io on …

我们在 Windows Server 2008 R2 上运行 MySQL 5.1。

我们最近一直在对我们的数据库进行一些诊断，并发现了一些我们无法解释的令人不安的伪影。当我们有需要很长时间（> 2000 毫秒）的查询时，我们添加了一些代码来记录。结果令人惊讶（并且可能是对我们僵局的解释）。

有时，通常只需要很少时间（<10 毫秒）的查询需要 4 到 13 秒。需要明确的是，这些是持续运行（每秒数次）并且不会受到这些查询时间峰值影响的查询。

我们已经检查了我们的索引，寻找任何明显的错误，但运气不佳。

更新

人表：

| people | CREATE TABLE `people` (
`people_id` bigint(20) NOT NULL AUTO_INCREMENT,
`company_id` bigint(20) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`password` varchar(255) DEFAULT NULL,
`temp_password` varchar(10) DEFAULT NULL,
`reset_password_hash` varchar(255) DEFAULT NULL,
`email` varchar(255) DEFAULT NULL,
`phone` varchar(32) DEFAULT NULL,
`mobile` varchar(32) DEFAULT NULL,
`iphone_device_id` varchar(160) DEFAULT NULL,
`iphone_device_time` datetime DEFAULT NULL,
`last_checkin` datetime DEFAULT NULL, …

给定一个简单的三表连接，当包含 ORDER BY 时，即使没有返回行，查询性能也会发生巨大变化。实际问题场景需要 30 秒才能返回零行，但在不包括 ORDER BY 时是即时的。为什么？

SELECT * 
FROM tinytable t                          /* one narrow row */
JOIN smalltable s on t.id=s.tinyId        /* one narrow row */
JOIN bigtable b on b.smallGuidId=s.GuidId /* a million narrow rows */
WHERE t.foreignId=3                       /* doesn't match */
ORDER BY b.CreatedUtc          /* try with and without this ORDER BY */

我知道我可以在 bigtable.smallGuidId 上建立索引，但是，我相信在这种情况下这实际上会使情况变得更糟。

这是创建/填充表以进行测试的脚本。奇怪的是，smalltable 有一个 nvarchar(max) 字段似乎很重要。我使用 guid 加入 bigtable 似乎也很重要（我猜这使它想要使用哈希匹配）。

CREATE TABLE tinytable
  (
     id        INT PRIMARY KEY IDENTITY(1, 1),
     foreignId …

我被要求创建一些东西来跟踪每天收取的帐户成本，我正在尝试找出一个支持这一点的数据库表模式。

这是我所知道的

• 公司拥有超过 250 万个账户
• 其中，他们目前平均每月工作 200,000 人（随着人员配备水平而变化，目前处于较低水平）
• 他们有 13 种不同的成本类型要跟踪，并且警告说将来可能会增加更多
• 他们希望每天跟踪成本
• 成本不会在整个库存中分摊。它们要么分布在每月工作的帐户数量 (200,000) 中，要么用户可以输入帐户标识符以将成本应用于一组帐户，或者他们可以简单地指定将成本应用于哪些帐户。

我的第一个想法是标准化数据库：

帐户ID
日期
成本类型 ID
数量

我的问题是，做数学。这张桌子很快就会变大。假设所有 13 种成本类型都应用于当月的所有工作帐户，即每月200k * 13 * N days in month大约 75-8000 万条记录，或接近每年 10 亿条记录。

我的第二个想法是对其进行非规范化

帐户ID
日期
总消耗
成本类型 1
成本类型2
成本类型 3
成本类型 4
成本类型5
成本类型 6
成本类型7
成本类型8
成本类型9
成本类型10
成本类型11
成本类型12
成本类型13

这种方法更加非规范化，每月最多可创建 600 万条记录 ( 200k * N days in month)，或每年约 7200万条。它比第一种方法少很多，但是如果公司将来决定使用新的成本类型，则需要添加另一个数据库列。

在这两种方法中，您更喜欢哪种方法？为什么？您是否可以想到另一种替代方法可以更好地处理此问题？

我对报告绩效最感兴趣，包括总结报告和详细报告。将成本分摊到帐户的工作将在无人在场的情况下每晚运行。次要问题是数据库大小。现有的数据库已经接近300GB，我相信磁盘空间在500GB左右。

数据库是 SQL Server 2005

这个问题是关于 SQL Server 索引性能，a varchar(2000)as an INCLUDEin a coverage index。

我正在尝试提高缓慢且不稳定的数据库应用程序的性能。在某些情况下，数据是通过大VARCHAR字符串来访问的，与查询包括像multple字符串操作SUBSTRING()，SPACE()和DATALENGTH()。这是访问的简化示例；

update fattable set col3 =  
   SUBSTRING(col3,1,10) + '*' + 
   SUBSTRING(col3,12,DATALENGTH(col3)-12)
from fattable where substring(col3,10,1) = 'A' and col2 = 2

架构如下所示：

CREATE TABLE [dbo].[FatTable]( 
    [id] [bigint] IDENTITY(1,1) NOT NULL, 
    [col1] [nchar](12) NOT NULL, 
    [col2] [int] NOT NULL, 
    [col3] [varchar](2000) NOT NULL, ... 

定义了以下索引，在大文本列上有一个覆盖字段。

CREATE NONCLUSTERED INDEX [IndexCol2Col3] ON [dbo].[FatTable]  ( [col2] ASC ) 
    INCLUDE( [col3] )

从我读过的内容来看，将大数据字段放在索引中是很糟糕的。我一直在阅读几篇文章，包括http://msdn.microsoft.com/en-us/library/ms190806.aspx，其中讨论了分页和磁盘大小对索引性能的影响。话虽如此，查询计划肯定会使用覆盖索引。我没有足够的信息来确定这在系统负载方面实际上给我带来了多少成本。我确实知道总体而言，系统性能不佳，我担心这是问题之一。问题：

• 将此varchar(2000) …

我有两个几乎相同的查询在同一个 SQL Server 2005 实例上运行：

1. 第一个是SELECT由 LINQ 生成的原始查询（我知道，我知道......我不是应用程序开发人员，只是 DBA :)。
2. 第二个和第一个完全一样，OPTION (RECOMPILE)在最后加了一个。

没有其他任何改变。

第一个每次运行需要 55 秒。
第二个需要 2 秒。

两个结果集是相同的。

为什么这个提示会产生如此显着的性能提升？

在线图书条目RECOMPILE没有提供非常详细的解释：

指示 SQL Server 数据库引擎在执行后放弃为查询生成的计划，强制查询优化器在下次执行相同查询时重新编译查询计划。在不指定 RECOMPILE 的情况下，数据库引擎会缓存查询计划并重用它们。编译查询计划时，RECOMPILE 查询提示使用查询中任何局部变量的当前值，如果查询在存储过程中，则将当前值传递给任何参数。

RECOMPILE 是创建使用 WITH RECOMPILE 子句的存储过程的一种有用的替代方法，当必须重新编译存储过程中的查询子集而不是整个存储过程时。有关详细信息，请参阅重新编译存储过程。RECOMPILE 在您创建计划指南时也很有用。有关更多信息，请参阅使用计划指南优化已部署应用程序中的查询。

由于我的查询有很多局部变量，我的猜测是当我使用OPTION (RECOMPILE)查询提示时，SQL Server 能够（认真地）优化它。

我所看到的每个地方都有人说OPTION (RECOMPILE)应该避免这种情况。对此的解释通常是使用此提示 SQL Server 无法重用此执行计划，因此每次都必须浪费时间重新编译它。
（但是）考虑到巨大的性能优势，我倾向于认为这次使用这个查询提示会是一件好事。

我应该使用它吗？如果没有，有没有一种方法可以强制 SQL Server 使用更好的执行计划而无需此提示且无需更改应用程序？