SQL Server大型表查询优化

我目前正在尝试执行关于许可的一些SAP分析。我想通过他们拥有的角色将用户链接到交易，并根据他们的交易获取所需的许可证。此分析跨多个SAP服务器执行，每个服务器包含多个SAP实例。在这个分析的某一点上，由于查询永远不会结束（我运行了更多的10个小时（尽管我有128 GB的RAM和大CPU性能），但我仍然在使用大型表和查询优化。有关这些表我根据我的查询：SQL Server大型表查询优化

SAP_LICENSING.DBO.calc_2_USER_ROLES其中包含100万行，并通过那些列定义：DTT_ID（SAP服务器名称），MANDT（SAP实例名称），UNAME（用户名），ASSIGNED_ROLE（他分配给的角色，例如：accoutant）。该表存储分配给用户的角色
SAP_LICENSING.DBO.raw_AGR_1251其中包含2M （SAP服务器名称），MANDT（SAP实例名称），AGR_NAME（角色），LOW（事务范围开始），HIGH（事务范围结束）
SAP_LICENSING.DBO.param_LICENSING_RULES包含140K行，并且由这些列定义：
1. SAP_LICENSING.DBO：TRANSAC（事务），LICENSE（对于相关的交易所需的许可证）
我已经设置在每个这些表的聚簇索引。 calc_2_USER_ROLES：DTT_ID，MANDT，UNAME，ASSIGNED_ROLE上的索引
SAP_LICENSING.DBO.raw_AGR_1251：指数上DTT_ID，MANDT，AGR_NAME，低，高
SAP_LICENSING.DBO.param_LICENSING_RULES：指数上TRANSAC

这里是我的响应时间，在每个子查询中的选择：

关于UR别名子查询：30秒
关于第t别名子查询：2分钟30秒
关于LR别名子查询：5秒

请注意以下几点：

运行此查询时，我看到的10％的CPU和RAM的30％，最大使用量
的查询工作迅速在SAP服务器的一个子集（1个SAP服务器名称过滤器）
第二子查询来变换SAP交易范围与同一个JOIN BETWEEN关键字
的LEFT JOIN的使用，因为我想保持无与伦比的交易进行进一步的分析兼容搜索交易

这是我与挣扎的相关查询：

INSERT INTO SAP_LICENSING.DBO.calc_3_USER_ROLES_TRANSACTIONS 
SELECT UR.DTT_ID,UR.MANDT,UR.UNAME,UR.ASSIGNED_ROLE, 
TRANSAC_FROM,TRANSAC_TO,SAP_TRANSAC_RANGE,LR.TRANSAC,LR.LICENSE 
--Get User Role Assignments 
FROM 
    (
    SELECT DISTINCT UR.DTT_ID,UR.MANDT,UR.UNAME,UR.ASSIGNED_ROLE 
    FROM SAP_LICENSING.DBO.calc_2_USER_ROLES UR 
    )UR 
--Join on transactions and Convert SAP Transaction ranges into SQL searchable ranges 
JOIN 
    (
    SELECT T.DTT_ID,T.MANDT,T.AGR_NAME,T.AUTH, 
    replace(replace(T.LOW,'*',' '),'$',' ') AS TRANSAC_FROM, 
    replace(replace(coalesce(T.HIGH,T.LOW),'*',left('ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ',41-len(coalesce(T.HIGH,T.LOW)))),'$','Z') AS TRANSAC_TO, 
    CONCAT(T.LOW,' TO ', isnull(T.HIGH,'')) as SAP_TRANSAC_RANGE 
    FROM SAP_LICENSING.DBO.raw_AGR_1251 T 
    )T 
ON UR.ASSIGNED_ROLE=T.AGR_NAME and UR.MANDT=T.MANDT and UR.DTT_ID=T.DTT_ID 
--Join on transactions requiring a license 
LEFT JOIN SAP_LICENSING.DBO.param_LICENSING_RULES LR 
ON LR.TRANSAC between T.TRANSAC_FROM and T.TRANSAC_TO;

非常感谢任何帮助你能给。最简单方面

来源

2017-03-02 APL

当发布需要调整的查询时，只有当您发布最少的repro以供其他人测试时才是好的（可以是可以回答的）。这里是一个很好的例子，生成表格模式，其他人的统计数据可以复制。看看我的问题DBA.SE获取更多信息：http：//dba.stackexchange.com/questions/157353/wrapping-query-in-if-exists-makes-it-very-slow – TheGameiswar

您对最大的表执行一些代价高昂的字符串转换，并使用JOIN条件中的结果。这肯定是低效的。默认情况下，SQL Server Optimiser会将最大的表放在最后，所以T将通过这些转换的字符串将JOIN编成UR和LR。

的一种方法是首先建立一个临时表T，其他 - 创建与TRANSAC_FROMTRANSAC_TO和计算字段为聚簇索引的一部分上SAP_LICENSING.DBO.raw_AGR_1251索引视图。

如果您将T移动到FROM子句的前面，并将其余表格移动到JOIN的前面，那么您也可能会对优化程序感到幸运。值得尝试OPTION (FORCE ORDER)。

发布当前的执行计划也有助于给出适当的建议。

来源

2017-03-02 11:19:48

i）是否有可能删除不同？
II）去批量插入
iii）将覆盖索引/过滤指数
IV）评论插件，并选择
V），如果指数没有被使用，那么你HV使用操作提示
您忘记使用（nolock）

来源

2017-03-02 11:42:52 KumarHarsh

SQL Server大型表查询优化

回答

相关问题