作者： Ka Ming Ng

发布于

如何为SQL Server调优子查询中带有OR条件的SQL语句？

下面示例显示带有EXISTS子查询的SQL语句。如果在DEPARTMENT表的子查询中满足OR条件，SQL会对EMPLOYEE表中的记录进行计数。

select countn(*) from employee a where
exists (select ‘x’ from department b
   where a.emp_id=b.dpt_manager or a.emp_salary=b.dpt_avg_salary
    )

下面是Tosska专有的树结构执行计划，它需要4分29秒才能完成。

该执行计划显示了从EMPLOYEE到全表扫描DEPARTMENT表的嵌套循环，这是整个执行计划的主要问题。因为 SQL Server 无法通过其他连接操作来解决这个OR条件“a.emp_id=b.dpt_manager or a.emp_salary=b.dpt_avg_salary”。

下面我将子查询中的OR条件改写为UNION ALL子查询，子查询中UNION ALL的第一部分表示“a.emp_id=b.dpt_manager”条件，第二部分表示“a.emp_salary=b.dpt_avg_salary”条件，但排除已经满足第一个条件的数据。

select count(*)
from  employee a
where exists ( select ‘x’
        from   department b
        where a.emp_id = b.dpt_manager
        union all
        select  ‘x’
        from   department b
        where ( not ( a.emp_id = b.dpt_manager )
           or b.dpt_manager is null )
           and a.emp_salary = b.dpt_avg_salary )

下面是改写后SQL的执行计划，看起来有点复杂，但现在性能很好，只需要0.447秒。有两个散列匹配连接用于替换原来从EMPLOYEE表到全表扫描DEPARTMENT表的嵌套循环。

虽然最终改写的步骤有点复杂，但这种改写可以由Tosska SQL Tuning Expert for SQL Server自动完成，这表明该改写SQL比原始SQL快了600多倍。

Tosska SQL Tuning Expert (TSES™) for SQL Server® – Tosska Technologies Limited

发布于

如何让SQL语句运行得更慢…但让用户的体验更好(Oracle)？

您的最终用户可能会不断抱怨他们的数据库应用程序的某些功能运行缓慢，但您可能会发现，在当前的Oracle和硬件配置中，这些SQL语句已经达到了它们的最大速度。除非您愿意升级硬件，否则可能没有办法改进SQL。有时，为了让用户感觉更好，您不必调优SQL以使其运行得更快，而只需调优SQL以使某些应用程序的SQL语句运行得更慢。

这是一个示例，该SQL用于显示表Emp_sal_hist和表Employee在满足某些条件后的信息。该SQL是在线查询执行的，用户必须等待至少5秒，才能在单击鼠标后在屏幕上显示任何数据。

select * from employee a,emp_sal_hist c
where a.emp_name like ‘A%’
 and a.emp_id=c.sal_emp_id
 and c.sal_salary<1800000
order by c.sal_emp_id

下面是SQL的执行计划和执行统计，提取全部79374条记录花费了10.41秒，第一条记录返回的反应时间为5.72秒。该查询显示了EMPLOYEE和EMP_SAL_HIST表的MERGE JOIN，在将其合并到最终结果之前，对两个相对应的表进行排序操作。这就是用户必须等待至少5秒才能看到屏幕上显示的内容的原因。

作为条件“a.emp_id = c.sal_emp_id”，我们知道“ORDER BY c.sal_emp_id”和“ORDER BY a.emp_id”是等效的，因为SQL语法改写不能强制对该SQL的执行计划进行指定的操作，所以我添加了一个优化器提示/*+ INDEX(@SEL$1 A EMPLOYEE_PK) */来减少“order by a.emp_id”的排序时间。

SELECT   /*+ INDEX(@SEL$1 A EMPLOYEE_PK) */ *
FROM   employee a,
     emp_sal_hist c
WHERE  a.emp_name LIKE ‘A%’
   AND a.emp_id = c.sal_emp_id
   AND c.sal_salary < 1800000
ORDER BY c.sal_emp_id

虽然在新的执行计划中，总体运行时间增加了3秒，但响应时间从5.72秒减少到1.16秒，因此用户可以更快的看到屏幕上第一页信息。我相信大多数用户不在乎是否还有3秒可以返回所有79374条记录。这就是为什么在管理用户期望时，SQL调优更像一门艺术而不是科学。
这种改写可以由Tosska SQL Tuning Expert Pro for Oracle自动实现。

https://www.tosska.cn/tosska-sql-tuning-expert-pro-tse-pro-for-oracle-zh/

发布于

Tosska SQL Tuning Expert (TSEM5™) for MySQL (5.1-5.5)® – 系统需求

在安装 Tosska SQL Tuning Expert (TSEM5™) for MySQL (5.1-5.5)® 之前, 请确保您的系统满足以下最低硬件和软件要求:

CPU 1.8 GHz Processor
Memory 2 GB of RAM minimum, 4 GB of RAM recommended
Hard Disk Space 400 MB of disk space for 64-bit installation
Operating System Microsoft Windows® 7 64-bit
Microsoft Windows® 10 32-bit 64-bit
.NET Framework Microsoft .NET Framework 4.5.2
Database Server MySQL® database 5.1 to 5.5
发布于

Tosska SQL Tuning Expert (TSES™) for SQL Server® – 系统需求

在安装 Tosska SQL Tuning Expert (TSES™) for SQL Server® 之前, 请确保您的系统满足以下最低硬件和软件要求:

CPU 1.8 GHz Processor
Memory 2 GB of RAM minimum, 4 GB of RAM recommended
Hard Disk Space 500 MB of disk space for 64-bit installation
Operating System Microsoft Windows® 7 64-bit
Microsoft Windows® 10 64-bit
.NET Framework Microsoft .NET Framework 4.5.0
Database Server SQL Server database 2005 or higher
发布于

Tosska SQL Tuning Expert (TSEM™) for MySQL® – 系统需求

在安装 Tosska SQL Tuning Expert (TSEM™) for MySQL® 之前, 请确保您的系统满足以下最低硬件和软件要求:

CPU 1.8 GHz Processor
Memory 2 GB of RAM minimum, 4 GB of RAM recommended
Hard Disk Space 200 MB of disk space for 32-bit installation
400 MB of disk space for 64-bit installation
Operating System Microsoft Windows® 7 32-bit and 64-bit
Microsoft Windows® 10 32-bit and 64-bit
.NET Framework Microsoft .NET Framework 4.5.2
Database Server MySQL® database 5.6 or higher
发布于

如何调优SQL Server性能不好并且设置返回行数的SQL语句？

在设置返回行数或者使用Top关键字后，某些SQL语句会运行的非常慢。设置返回行数和使用Top关键字会告诉SQL Server从SQL语句中选择特定行数而不是提取所有记录。没有多少人知道在设置返回行数或者使用Top关键字后SQL Server会尝试重新优化您的SQL语句，重新优化后的SQL语句产生的执行计划通常可以更快的检索前几条记录，但是也可能适得其反。

设置返回行数重新优化查询的好示例
下面是一个示例，显示了该SQL从数据库中检索217500行记录需要6.78秒。这是一个好的执行计划，因为它对[DEPARTMENT]和[EMPLOYEE]的两个表扫描进行哈希匹配。

下面屏幕显示了设置返回行数为1后新的执行计划把哈希匹配改为嵌套循环。嵌套循环操作通常提供更快的前几条记录检索时间，但在某些情况下可能不利于整体记录的提取。很高兴看到SQL Server提取此SQL的第一行记录仅用了0.013秒。

设置返回行数重新优化查询的坏示例
让我们来看一个坏示例，它展示了在使用设置返回行数为1后，SQL Server如何将一个好的执行计划变成一个糟糕的执行计划。下面一个示例显示，该SQL从数据库中检索1613行记录花费了0.118秒，虽然该执行计划有点复杂，但对于检索完所有行来说是一个很好的执行计划。

下面屏幕显示了设置返回行数为1后生成的新执行计划，该执行计划现在更改为带有两次表扫描的嵌套循环。新的执行计划提取第一条记录需要1.312秒，比从数据库提取所有行所用的0.118秒还要慢。

如何解决这个问题呢？
我们可以使用提示注入或者SQL语法改写来影响SQL Server为设置返回行数或者Top关键字操作改回原始的执行计划或者生成更好的执行计划。下面是提示注入生成的一个很好的执行计划，它比设置返回行数为1的原始SQL快了90倍。

Tosska SQL Tuning Expert (TSES™) for SQL Server® – Tosska Technologies Limited

发布于

如何调优SQL Server的冷缓存SQL语句？

对于不经常执行的SQL语句，相关的数据可能不在缓存区，冷缓存会显著的影响这类SQL语句的性能。 用于热缓存的高性能SQL语句在冷缓存环境中可能表现的不好。经验丰富的开发人员会调优他们的SQL, 使其在两种情况下都能得到良好运行。

下面是一个SQL示例：
select * from
EMPLOYEE A
 where A.EMP_ID IN (SELECT B.EMP_ID from EMP_SUBSIDIARY B
     where B.EMP_DEPT < ‘D’)

下面是Tosska的树结构执行计划，第一次执行因为缓存延迟需要8.024秒，第二次执行无需缓存延迟只需要3.7秒。

根据执行计划，您可能发现IO消耗最多的是[EMPLOYEE]表的表扫描。为了模拟冷缓存环境，我们可以在每次执行SQL语句前使用DBCC DROPCLEANBUFFERS命令来清除数据缓存。

让我为这条SQL添加OPTION(LOOP JOIN)提示,并尝试将执行计划的哈希匹配更改为嵌套循环连接。因此，将使用[EMPLOYEE]的EMP_ID(EMPLOYEE_PK)和RID查找，而不是使用表扫描。我希望RID查找可以从硬盘中选择较少的数据，同时在[EMPLOYEE]和[EMP_SUBSIDIARY]中匹配EMP_ID。

select *
from   EMPLOYEE A
where  A.EMP_ID in (select  B.EMP_ID
          from   EMP_SUBSIDIARY B
          where  B.EMP_DEPT < ‘D’) OPTION(LOOP JOIN)

根据下面的执行计划，携带数据缓存开销的执行时间从8.024秒减少到1.565秒，物理读也从190,621减少到39,044。如果您用SQL Server的EstimateIO乘以EstimiateExecutions来得到IO估计值，这是错误的。

下面的人工智能调优工具还提供了其它更好的调优解决方案：

Tosska SQL Tuning Expert (TSES™) for SQL Server® – Tosska Technologies Limited

下面带有提示的SQL语句生成一个更复杂的执行计划，最好的执行时间为0.7秒。该SQL是在冷缓存下进行调优的，每次执行SQL语句之前都会清除缓存数据。