标签: performance

SentryOne Plan Explorer是否像宣传的那样工作，是否合法？有什么问题或需要担心的事情吗？

与 SSMS 对估计执行计划视图的噩梦相比，它似乎以颜色显示了热路径。

我担心的是 - 它是否恶意或以其他方式修改任何数据？

编辑：我刚刚听说过它，以前从未听说过这家公司。

从我的另一个问题中可以看出，生成测试数据是我现在的主题。

在这一点上，我仍在手动生成我的测试数据。但是，此过程始终会生成少量数据（通常为 5-10 行），因为它是一个手动过程。

是否有任何工具可以自动执行此过程？特别是，我希望能够生成 100 万行以上。

我正在计划将 2TB 数据库实时迁移到分区表的过程。从广义上讲，该系统是一个文档存储，大部分空间分配给 50kb 到 500kb 之间的 LOB，一小部分在 500kb 到 1MB 范围内。部分迁移将涉及从旧数据库到新数据库的 BCPing 数据。

BCP 是首选方法，因为数据中的当前/历史鸿沟允许在最终切换之前分阶段（在较安静的时期）提取较旧的数据，从而最大限度地减少对实时系统的影响。数据量和存储可用性排除了对分区方案的原位重建。

由于 BLOB 内容，我怀疑通过尝试使用 KILOBYTES_PER_BATCH 而不是 ROWS_PER_BATCH 可能会获得一些性能提升。BCP文档中建议SQL可以根据这个值优化操作。

我找不到关于这些优化的性质或从哪里开始测试的任何指导。在没有建议的情况下，我将尝试在 4/8/16/32/64mb 边界处进行短期运行。

可能会从更改数据包大小（BCP -a 参数，而不是服务器级别设置）中获得一些收益，但我倾向于将其提高到最大 65535，除非有人有更公式化的方法。

我有一个电子邮件应用程序，它将被要求在每个页面加载时将给定用户的新消息数量传送到 UI。我在数据库级别上测试了一些变化，但所有内容都由存储的 proc 调用抽象。

我试图猛击数据库以查看断点（每秒请求数）是什么。

简而言之，我有一个表，比如这个 userId、newMsgCount，在 userId 上有一个聚集索引。SQL 应该能够每秒处理成百上千个这样的响应。我认为落后者是我的 .NET 应用程序。

我怎样才能使这个测试成为一个很好的测试来实现基于 SQL 性能的测试结果？

有没有一个工具，我可以给它一个存储的过程名称和参数，以便它打我的数据库？

我想看看数据库是否可以返回分钟。每秒 250 个响应。

我的工作场所正在进行一项运动，不再使用 #temp 表，而是使用带有 SPID 的永久物理表。每当人们以前将 INSERTed INTO #temp 表时，现在INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)都需要一个 - 以及DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPID在例如存储过程开头的一堆语句。此外，不用说，在使用这些“用于存储临时数据的永久表”的任何地方，都必须小心包含WHERE SPID = @@SPID.

转向这种做法背后的逻辑是，它将提高运行查询的服务器的整体性能（通过减少 tempdb 中的 I/O 和争用）。由于多种原因，我并不热衷于这种方法 - 它很丑陋，有潜在危险，并且似乎很可能会损害使用新方案的那些查询的性能。

有没有人有任何使用这种或类似方法来消除#temp 表的经验？

我有一个复杂的查询，它在查询窗口中运行 2 秒，但作为存储过程运行大约 5 分钟。为什么作为存储过程运行需要这么长时间？

这是我的查询的样子。

它需要一组特定的记录（由@id和标识@createdDate）和特定的时间范围（从 开始的 1 年@startDate），并返回发送的信件的汇总列表以及由于这些信件而收到的估计付款。

CREATE PROCEDURE MyStoredProcedure
    @id int,
    @createdDate varchar(20),
    @startDate varchar(20)

 AS
SET NOCOUNT ON

    -- Get the number of records * .7
    -- Only want to return records containing letters that were sent on 70% or more of the records
    DECLARE @limit int
    SET @limit = IsNull((SELECT Count(*) FROM RecordsTable WITH (NOLOCK) WHERE ForeignKeyId = @id AND Created = @createdDate), 0) * .07

    SELECT DateSent …

在维护工作期间，我试图获取碎片索引的列表。但查询速度极慢，执行时间超过 30 分钟。我认为这是由于对 sys.dm_db_index_physical_stats 的远程扫描。

有什么办法可以加快以下查询的速度：

SELECT
    OBJECT_NAME(i.OBJECT_ID) AS TableName,
    i.name AS TableIndexName
FROM
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat 
    INNER JOIN sys.indexes i 
        ON i.OBJECT_ID = phystat.OBJECT_ID AND i.index_id = phystat.index_id 
WHERE 
    phystat.avg_fragmentation_in_percent > 20 
    AND OBJECT_NAME(i.OBJECT_ID) IS NOT NULL
ORDER BY phystat.avg_fragmentation_in_percent DESC

我不是 DBA，可能在上面的查询中犯了一个明显的错误，或者可能有一些索引或统计信息会有所帮助？也许这只是数据库的大小（大约 20Gb，大约有 140 个表）。

我问的原因是我们只有一个非常小的夜间维护窗口，而这占用了大部分时间。

我用查询来计算记录

SELECT COUNT(col1) FROM table1 WHERE col1 LIKE '%something%'
SELECT COUNT(col1) FROM table1 WHERE col1 LIKE '%another%'
SELECT COUNT(col1) FROM table1 WHERE col1 LIKE '%word%'

对于每一个计数，mysql都需要遍历整个表，如果表很长，查询很多，这是一个大问题。

我想知道是否有一种方法可以在一个查询中进行所有计数。在这种情况下，当mysql遍历每一行时，它会处理所有计数，而无需一遍又一遍地扫描整个表。

从我目前所见，当我们定义一个表时，通常我们将主键作为第一列。如果存在所有表中通用的杂项列，则它们位于表定义的底部。例如：Id（pk）第一列和 IsActive 和底部的时间戳。

我想知道除了跨数据库的一致性之外，这种做法是否还有更多好处。列的顺序是否会影响性能？如何？我需要在团队中证明我的观点，即在表中随机放置主键和公共键（例如 IsActive（布尔列显示记录是否处于活动状态））不是一个好习惯！

开发人员在 Visual Studio 2010 中的实体模型中创建实体，如果他们向现有实体添加新属性，显然 VS 没有将它们按正确顺序排列。这是他们忽略表中列顺序的借口。它会影响性能吗？

我很欣赏你的想法。

在我的一个生产环境中，我们有两个实例在 RedHat 集群上运行，其中一个生产实例与该集群关联。

我们有 125G 主内存，24G InnoDB 缓冲池被 instance1 占用，12G 被 instance2 占用，这与 RedHat 集群无关。数据和事务日志都位于具有 ext3 文件系统的 LVM 磁盘分区上。

为了提高性能和更好的 I/O 吞吐量，我决定更改innodb_flush_method为O_DIRECT.

参考 MySQL 文档：

InnoDB 数据和日志文件位于 SAN 上，我们发现设置innodb_flush_method为O_DIRECT会使简单SELECT语句的性能降低三倍。

提到高性能 MySQL Ver 2 和 3，它表示 InnoDB 开发人员发现使用innodb_flush_method=O_DSYNC. O_SYNCandO_DSYNC类似于fsync()and fdatasync()：O_SYNC同步数据和元数据，而O_DSYNC只同步数据。

如果这一切看起来像是没有建议的很多解释，那么建议如下：

如果您使用类 Unix 操作系统并且您的 RAID 控制器具有电池供电的写入缓存，我们建议您使用O_DIRECT. 如果没有，O_DIRECT根据您的应用程序，默认值或可能是最佳选择。

通过谷歌搜索，我得到了这个基准报告：on O_DSYNCvsO_DIRECT

基准报告：
====================
1B …