我正在运行需要一些 mysql 优化的 wordpress,我有一个缓慢的查询,我想摆脱“使用临时;使用文件排序”
询问:
解释 SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts 内部连接 wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND ( wp_term_relationships.term_taxonomy_id IN (1,3,4,5) ) AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private') 按 wp_posts.ID 分组 ORDER BY wp_posts.post_date DESC 限制 0, 10;
+----+--------------+------------------------------+------ +---------------------------------+------------------+--- ------+----------------+------+------- ---------------------------+ | 身份证 | 选择类型 | 表| 类型 | 可能的密钥| 关键| 密钥长度 | 参考 | 行 | 额外 | +----+-------------+------------------------------+------ +---------------------------------+------------------+--- ------+----------------+------+------- ---------------------------+ | 1 | 简单 | wp_posts | …
我负责管理 SQL Server 200x 的一个实例,它不幸充当了一个用令人讨厌的性能问题编写的交钥匙应用程序的后端。它重复使用准备静态游标的模式,它只使用前几个条目,通常需要几十毫秒。在一个连续的流中有成千上万个这样的查询。
事情的真相是,由于应用程序数据完整性的奇怪设计,这些查询中的任何一个都根本不是问题,因此它们是静态的这一事实是悲惨的,因为如果它们是静态的,性能将提高大约 30 倍动态的。
在与供应商打交道数周后,我一无所获。事实上,我真正需要做的就是更改应用程序使用 sp_cursorprepexec 的方式中的一个参数。如有必要,我什至可以在整个服务器上以全局方式执行此操作。
我正在研究任何和所有解决方案,无论是使用 SQL Server 200x 中我无法找到的功能,编写一个位于 SQL Server 和客户端之间并修改数据的小应用程序(尽管我不会期待弄清楚如何以这种方式处理 TDS 协议),或者以某种方式重命名 sp_cursorprepexec 并用包装器替换它。
天空是极限。
(仅供参考,我们现在正在运行 SQL Server 2005,但如果有令人信服的理由支付额外的钱来升级许可证,它可能会发生。)
我需要一种快速、同步、持续时间最短的插入表的方法。我试过的(“盲”)是:
我使用的测试场景由 100 个连接组成,每个连接都运行一个 INSERT,然后等待 0.1 秒,然后无限期地再次等待。每个“插入器”记录执行时间。
查看执行时间,我有时会在插入时看到 1.5 秒甚至 10 秒(作为例外情况),否则我看到的是典型的 0.2 秒。
进一步的背景:
我应该在哪里寻找对此类流程性能的进一步改进?
我的数据库非常大,并且以每天约 2000 万行的速度增长。我有很重要的时间戳数据,但大多数报告都是基于日期范围和周与周或月与月的比较。时间偶尔会显示在结果集中,但从未用作标准。鉴于此,我想我会通过单独的日期索引与组合的日期时间字段来节省大量的存储空间。我不确定我是否也会在我的选择中看到性能提升,或者拆分为 2 个字段是否有任何缺点。
我正在尝试存储大量在存储为INT值时会被截断的大数。不幸的是,它们对于这种类型来说太大了。
我正在考虑使用Base36编码来实现这一点。有没有其他方法可以解决这个问题?
为什么下面的查询很慢?
select count(*)
from [dbo].[mt_dispatch_link]
, [dbo].[_mt_dispatch] [_mt_dispatch]
where (mt_dispatch_link.contract_id_1 = _mt_dispatch.contract_id
and mt_dispatch_link.dispatch_id_1 = _mt_dispatch.dispatch_id)
or (mt_dispatch_link.contract_id_2 = _mt_dispatch.contract_id
and mt_dispatch_link.dispatch_id_2 = _mt_dispatch.dispatch_id)
Run Code Online (Sandbox Code Playgroud)

这需要 10 多分钟,然后我倾向于在那个时候停止它。我的问题更多是关于如何理解查询计划。
查看查询计划,我可以看到底部聚集索引扫描返回大约 250000 条记录,但成本为 0% 并且它正在放入临时表中。
顶部索引扫描大约是 25000 条记录。
但是 95% 的成本来自嵌套连接。我应该从中得出什么结论?
上面的查询计划显示了两次索引扫描,是说它在做 25000 + 250000 次索引扫描,还是说它在做 25000 * 250000 次索引扫描?
如果我将查询更改为此(添加FORCESEEK):
select count(*)
from [dbo].[mt_dispatch_link]
, [dbo].[_mt_dispatch] [_mt_dispatch]
WITH (FORCESEEK)
where (mt_dispatch_link.contract_id_1 = _mt_dispatch.contract_id
and mt_dispatch_link.dispatch_id_1 = _mt_dispatch.dispatch_id)
or (mt_dispatch_link.contract_id_2 = _mt_dispatch.contract_id
and mt_dispatch_link.dispatch_id_2 = _mt_dispatch.dispatch_id)
Run Code Online (Sandbox Code Playgroud)
我最终得到了一个更好的计划,查询立即运行:

我在两个表上运行了更新统计信息。可惜没修好。表设计不是很好,所以我认为 SQL Server 并不真正理解,因此提出了一个糟糕的查询计划。有关 …
我有一个包含 600,000 条记录的交易表,我需要在财政年度的基础上列出仪表板的计数。使用的表是 MyISAM。我尝试为交易日期 ( tran_date)添加索引。即使它正在使用索引,它也会创建临时表,由于临时表和文件排序需要更多时间。有什么办法可以优化查询以提高查询时间?
SELECT COUNT( * ) AS cnt, CASE WHEN MONTH( tran_date ) >=3 THEN concat( YEAR( tran_date ) , '-', YEAR( tran_date ) +1 ) ELSE concat( YEAR( tran_date ) -1, '-', YEAR( tran_date ) ) END AS 财务年 从`交易1` WHERE tran_date >= '2010-06-01' 按财务年分组 显示第 0 - 4 行(共 5 行,查询耗时 1.2095 秒)
id select_type table type possible_keys key key_len ref rows Extra 1 简单交易 1 范围 PRIMARY,tran_date tran_date 8 NULL 346485 使用 …
mysql mysql-5 performance optimization mysql-5.5 query-performance
我们正在使用基于 SQL Server 2005 的专有应用程序,它有许多基于 HEAP 的表(即没有聚集索引)。多年来,这些表变得非常碎片化(例如 99% 碎片化)。我需要对它们进行碎片整理。
现在,在 SQL Server 2005 中,没有办法直接做到这一点。我可以:
现在,这是一个由供应商编写的大型应用程序——一个巨大的黑匣子。我并不急于弄乱他们的东西。我不太了解这些表是如何使用的。这样做的影响最小的方法是什么?
而且,作为后续:有许多这些基于 HEAP 的表,应用程序使用了十多个数据库。有没有办法自动选择 #2 或 #3?或者,我应该如何选择要修改的表?
更新:
回答(非常有帮助的)回复提出的问题:
简而言之,客户支持团队已经明确表示:您必须对表格进行碎片整理,如何做是您的事。
至于未来的版本:是的,新版本正在开发中,最终会迁移到 SQL Server 2012。但是他们今天需要性能解决方案。
最后,至于碎片整理时间太长:没关系。他们有 99% 碎片化的巨型表;该应用程序不在夜间使用;我可以轻松地一次花费数小时对它们进行碎片整理。
performance sql-server optimization clustered-index index-tuning
考虑这些查询(SQL Fiddle):
查询 1:
SELECT * INTO #TMP1 FROM Foo
UNION
SELECT * FROM Boo
UNION
SELECT * FROM Koo;
Run Code Online (Sandbox Code Playgroud)
查询 2:
SELECT * INTO #TMP2 FROM Foo
UNION
SELECT * FROM Boo
UNION ALL
SELECT * FROM Koo;
Run Code Online (Sandbox Code Playgroud)
请注意,Koo 与 Boo/Foo 不重叠,因此最终结果是相同的。问题是为什么第一个UNION / UNION组合没有合并成单个 SORT 操作?
我正在使用一个表,该表的所有字符类型都设置为nvarchar其中一些是nvarchar(max). 我们正在将所有这些转换为varchar并根据生产中的实际使用指定字符宽度。对于任何给定的列,生产数据使用 2 个字符到 900 个字符的实际使用宽度范围。我们将在适用时添加 10% 的填充。
-- Insert statements for procedure here
UPDATE Listings WITH (ROWLOCK)
SET [SubType] = 'S'
WHERE @idSettings = idSettings AND
(@idRetsClass = 0 OR idRetsClass = @idRetsClass)
AND (@idRetsSetting = 0 OR idRetsSetting = @idRetsSetting)
AND IsNew = 1 AND ([SubType] LIKE '%Single Family Home%' OR [SubType] LIKE '%Modular%' OR [SubType] LIKE '%Mobile Home%'
OR [SubType] LIKE '% Story%' OR [SubType] = '' OR [SubType] = 'residential …Run Code Online (Sandbox Code Playgroud) optimization ×10
sql-server ×6
performance ×5
mysql ×3
datatypes ×1
index-tuning ×1
insert ×1
mysql-5 ×1
mysql-5.5 ×1
order-by ×1
query ×1
union ×1