【问题标题】:Why TRY_PARSE its so slow?为什么 TRY_PARSE 这么慢?
【发布时间】:2021-03-26 08:46:42
【问题描述】:

我有这个查询,基本上(现在)只返回 10 行结果:

select *
FROM Table1 as o
inner join Table2 as t on t.Field1 = o.Field2
where Code = 123456 and t.FakeData is not null

现在,如果我想解析 FakeData 字段(不幸的是,它可以包含不同类型的数据,从 DateTime 到 Surname/etc;即 nvarchar(70)),用于数据显示和/或过滤:

select *, TRY_PARSE(t.FakeData as date USING 'en-GB') as RealDate
FROM Table1 as o
inner join Table2 as t on t.Field1 = o.Field2
where Code = 123456 and t.FakeData is not null

执行查询需要 x10 倍。

我哪里错了?我怎样才能加快速度?

我无法编辑数据库,我只是读取数据的客户。

【问题讨论】:

  • 你看过执行计划了吗?
  • 包含不同类型数据的列表明存在架构设计缺陷,您可能会在查询中付出代价。
  • 哪个表包含 where 子句中使用的code? (提示:始终包含别名)

标签: sql-server performance datetime parsing


【解决方案1】:

TRY_PARSE 的 TSQL 文档进行了以下观察:

请记住,解析字符串值会有一定的性能开销。

注意:我假设您的典型日期格式是 dd/mm/yyyy。

以下内容可能会有所帮助。通过逐步评估nvarchar 列是否是候选日期,可以减少该函数的使用次数。请注意,在一个应用中建立的数据点可以在后续应用中引用:

CREATE TABLE mytable(
   FakeData NVARCHAR(60) NOT NULL
);
INSERT INTO mytable(FakeData) VALUES (N'oiwsuhd ouhw dcouhw oduch woidhc owihdc oiwhd cowihc');
INSERT INTO mytable(FakeData) VALUES (N'9603200-0297r2-0--824');
INSERT INTO mytable(FakeData) VALUES (N'12/03/1967');
INSERT INTO mytable(FakeData) VALUES (N'12/3/2012');
INSERT INTO mytable(FakeData) VALUES (N'3/3/1812');
INSERT INTO mytable(FakeData) VALUES (N'ohsw dciuh iuh pswiuh piwsuh cpiuwhs dcpiuhws ipdcu wsiu');

select
      t.FakeData, oa3.RealDate
from mytable as t
outer apply (
    select len(FakeData) as fd_len
    ) oa1
outer apply (
    select case when oa1.fd_len > 10 then 0
                when len(replace(FakeData,'/','')) + 2 = oa1.fd_len then 1
                else 0
           end as is_candidate
    ) oa2
outer apply (
    select case when oa2.is_candidate = 1 then TRY_PARSE(t.FakeData as date USING 'en-GB') end as RealDate
    ) oa3
FakeData RealDate
oiwsuhd ouhw dcouhw oduch woidhc owihdc oiwhd cowihc null
9603200-0297r2-0--824 null
12/03/1967 1967-03-12
12/3/2012 2012-03-12
3/3/1812 1812-03-03
ohsw dciuh iuh pswiuh piwsuh cpiuwhs dcpiuhws ipdcu wsiu null

db小提琴here

【讨论】:

  • 代码不应被引用。
  • 真的吗?我不知道降价会受到这种不灵活的影响。值得注意的是,降价是由 db-fiddle 提供的。
  • 10 行上的 try_parse 可以忽略不计。问题的根源应该是对整个表执行,然后只保留了想要的10行,这不是try_parse真正引起的问题。
  • 是的。正是为什么我提出了一种减少调用次数但没有测试的方法,当然我不能保证会有所改进。
猜你喜欢
  • 2021-09-03
  • 2016-09-28
  • 2020-02-08
  • 2012-07-17
  • 2011-11-07
  • 2015-08-24
  • 2013-08-06
  • 2014-07-16
  • 2011-01-02
相关资源
最近更新 更多