标签: performance

假设我们有一个包含四列(a,b,c,d)相同数据类型的表。

是否可以选择列中数据中的所有不同值并将它们作为单个列返回，或者我是否必须创建一个函数来实现这一点？

如何消除执行计划中的 Key Lookup (Clustered) 运算符？

表tblQuotes已经有一个聚集索引 (on QuoteID) 和 27 个非聚集索引，所以我不想再创建了。

我将聚集索引列QuoteID放在我的查询中，希望它会有所帮助 - 但不幸的是仍然相同。

执行计划在这里。

或查看它：

这是 Key Lookup 运算符所说的：

询问：

declare
        @EffDateFrom datetime ='2017-02-01',
        @EffDateTo   datetime ='2017-08-28'

SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

IF OBJECT_ID('tempdb..#Data') IS NOT NULL
    DROP TABLE #Data 
CREATE TABLE #Data
(
    QuoteID int NOT NULL,   --clustered index

    [EffectiveDate] [datetime] NULL, --not indexed
    [Submitted] [int] NULL,
    [Quoted] [int] NULL,
    [Bound] [int] NULL,
    [Exonerated] [int] NULL,
    [ProducerLocationId] [int] …

我在这场辩论的双方都阅读了很多内容：仅使用存储过程而不是原始查询是否会显着提高性能？我对 SQL Server 特别感兴趣，但对任何和所有数据库都感兴趣。

作为一名软件开发人员和一名有抱负的 DBA，我在设计 SQL Server 数据库时尝试结合最佳实践（我的软件 99% 的时间位于 SQL Server 之上）。我在开发之前和开发过程中做出最好的设计。

但是，就像任何其他软件开发人员一样，存在需要更改/创建的数据库对象的附加功能、错误和需求更改。

我的问题是，查询优化应该是主动的还是被动的？换句话说，在一些大量的代码/数据库修改几周后，我是否应该留出一天来检查查询性能并根据它进行调整？即使它似乎运行正常？

或者我应该知道低于平均水平的性能应该是数据库检查并回到众所周知的黑板？

查询调优可能会占用大量时间，并且取决于初始数据库设计，它可能是最小的好处。我对公认的作案手法感到好奇。

它使用的时候可能pgadmin还是plsql获得查询计划的搁置了内部执行SQL语句ü SER d efined ˚F油膏（UDF）使用EXPLAIN。那么我如何掌握 UDF 的特定调用的查询计划呢？我看到 UDF 抽象为F()pgadmin 中的单个操作。

我查看了文档，但找不到任何内容。

目前我正在提取语句并手动运行它们。但这不会减少大型查询。

例如，考虑下面的 UDF。这个 UDF，即使它能够打印出它的查询字符串，也不能使用复制粘贴，因为它有一个本地创建的临时表，当你粘贴和执行它时它不存在。

CREATE OR REPLACE FUNCTION get_paginated_search_results(
    forum_id_ INTEGER,
    query_    CHARACTER VARYING,
    from_date_ TIMESTAMP WITHOUT TIME ZONE DEFAULT NULL,
    to_date_ TIMESTAMP WITHOUT TIME ZONE DEFAULT NULL,
    in_categories_ INTEGER[] DEFAULT '{}')
RETURNS SETOF post_result_entry AS $$
DECLARE
    join_string CHARACTER VARYING := ' ';
    from_where_date CHARACTER VARYING := ' ';
    to_where_date CHARACTER VARYING := ' ';
    query_string_ CHARACTER VARYING …

我目前正在研究一个 MySQL 数据库，我们看到查询缓存中有大量无效，主要是因为在许多表上执行了大量的 INSERT、DELETE 和 UPDATE 语句。

我要确定的是，允许将查询缓存用于针对这些表运行的 SELECT 语句是否有任何好处。由于它们很快就失效了，在我看来，最好的办法是在这些表的 SELECT 语句上使用 SQL_NO_CACHE。

频繁失效的开销值得吗？

编辑：应以下用户@RolandoMySQLDBA 的要求，这里是有关 MyISAM 和 INNODB 的信息。

数据库

• 数据大小：177.414 GB
• 索引大小：114.792 GB
• 表大小：292.205 GB

我的ISAM

• 数据大小：379.762 GB
• 索引大小：80.681 GB
• 表大小：460.443 GB

附加信息：

• 版本：5.0.85
• 查询缓存限制：1048576
• query_cache_min_res_unit：4096
• 查询缓存大小：104857600
• query_cache_type：开启
• query_cache_wlock_invalidate：关闭
• innodb_buffer_pool_size: 8841592832
• 24GB 内存

情况 我有一个 postgresql 9.2 数据库，它一直都在大量更新。因此系统受 I/O 限制，我目前正在考虑进行另一次升级，我只需要一些关于从哪里开始改进的指导。

以下是过去 3 个月情况的图片：

如您所见，更新操作占磁盘利用率的大部分。这是另一张更详细的 3 小时窗口中情况的图：

如您所见，峰值写入速率约为 20MB/s

软件 服务器运行 ubuntu 12.04 和 postgresql 9.2。更新类型通常在由 ID 标识的单个行上进行小更新。例如UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id。我已经尽可能多地删除和优化了索引，并且服务器配置（linux 内核和 postgres conf）也非常优化。

硬件 硬件是一个专用服务器，带有 32GB ECC ram、RAID 10 阵列中的 4 个 600GB 15.000 rpm SAS 磁盘，由带有 BBU 的 LSI RAID 控制器和英特尔至强 E3-1245 四核处理器控制。

问题

• 对于这种口径（读/写）的系统，图表所看到的性能是否合理？
• 因此，我应该专注于进行硬件升级还是深入研究软件（内核调整、confs、查询等）？
• 如果进行硬件升级，磁盘数量是性能的关键吗？

- - - - - - - - - - - - - - - 更新 …

有人正在审查我用于创建表的 DDL 代码并建议，当他们看到我看到使用VARCHAR(256)文本字段时，我希望它非常小，比如名字或其他什么，我应该总是只使用VARCHAR(MAX)和链接为什么使用 varchar(max )。我读过它，但它似乎过时了，因为它专注于 2005 年，并且似乎没有提供任何真正的理由来在所有文本字段上每行分配最多 2 GB。

从性能、存储等角度来看，应该如何决定是使用VARCHAR(MAX)SQL Server 的现代版本还是使用更小更具体的类型？（例如，2008、2012、2014）

假设我们有一个像这样的表定义：

CREATE TABLE MyTab (
    ID INT IDENTITY(1,1) CONSTRAINT PK_MyTab_ID PRIMARY KEY
    ,GroupByColumn NVARCHAR(10) NOT NULL
    ,WhereColumn DATETIME NULL
    )

还有一个过滤的非聚集索引，如下所示：

CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn ON MyTab 
    (GroupByColumn)
WHERE (WhereColumn IS NULL) 

为什么这个索引没有“覆盖”这个查询：

SELECT 
    GroupByColumn
    ,COUNT(*)
FROM MyTab
WHERE WhereColumn IS NULL
GROUP BY GroupByColumn

我得到这个执行计划：

KeyLookup 用于 WhereColumn IS NULL 谓词。

这是计划：https : //www.brentozar.com/pastetheplan/?id=SJcbLHxO7

为什么仅使用索引无法实现性能改进，因此需要其他技术（如表分区）？问题只与性能有关，当然不同的分区可以放入不同的表空间，这具有索引无法实现的其他效果。

或者换句话说，只有在性能方面：是否可以通过索引实现与表分区相同的性能改进？