【问题标题】:Sql Server select requests tuningSql Server 选择请求调优
【发布时间】:2019-03-22 03:34:48
【问题描述】:

我们有一个包含大约 6000 万条记录的 SQL Server 数据库表。这些是特定实体的名称和地址的记录。表包含以下列:

[Name] [nvarchar](425) NOT NULL,
[Street] [nvarchar](900) NULL,
[City] [nvarchar](900) NULL,
[State] [nvarchar](900) NULL,
[PostalCode] [nvarchar](100) NULL

我们要做到的是能够在 1 秒内执行特定的 select 语句。

我们应该能够根据“[姓名]”是否包含一个或多个输入的单词(不是“完全匹配”而不是“开头为”)来选择记录,然后应用下一个优先级逻辑:

  1. 显示位于给定 [州] 和 [城市] 的顶级记录
  2. 显示位于给定 [州] 但另一个城市的项目
  3. 显示位于其他州的项目

这是我们尝试过的:

  1. 我们尝试通过多种方式重建表,在不同的表中提取不同的列,不同的索引集,在单独的文件夹中提取每个单词作为标记
  2. SQL Server 全文搜索。 (使用“包含”功能匹配记录)
  3. Azure Cosmos DB。我们在那里迁移数据以评估我们是否可以足够有效地执行选择

问题始终是根据州+城市对记录进行优先级排序

问题是我们如何使用 SQL Server 或任何其他数据源(最好在 Azure 上提供)实现在 1 秒内执行选择的能力

【问题讨论】:

  • 你能让这些列变窄吗?地球上哪个城市和/或州有 900 个字符?还是 100 个字符的邮政编码?
  • 您在实验中尝试过列存储索引吗?对于需要按其他条件排序的 Name 谓词,您通常会得到多少结果?
  • @MartinSmith 是的,我做到了。实际上结果的数量是问题之一。可能是 200k+
  • 我不知道你是否可以稍微改变你的设计。 .如果是,那么你应该规范你的设计。 .将城市名称作为文本保留在地址表中是不合适的...您可以拥有一个城市表并引用地址表的外键..然后您就可以过滤城市的小表并将其与地址连接起来表..
  • @samantarighpeima 说得有道理,但您认为这有助于解决性能问题吗?

标签: sql-server azure nosql sql-tuning


【解决方案1】:

除了将CityStateZip 标准化并适当调整这些字段的大小之外,我唯一能想到的就是制作一个单词列表:

Create Table tbl_Entity
(
    [ID] [Int] Identity Not Null,
    [Name] [nvarchar](425) NOT NULL,
    [Street] [nvarchar](900) NULL,
    [City] [nvarchar](900) NULL,
    [State] [nvarchar](900) NULL,
    [PostalCode] [nvarchar](100) NULL
)

Create Table tbl_Entity_Name_Elements
(
    [ID] [Int] Identity Not Null,
    [Entity_ID] [Int] Not Null,   -- foreign key to tbl_Entity
    [Name_Element] [nvarchar](100) Null
)

通过解析tbl_Entity 中的行来生成bl_Entity_Name_Elements 的例程(可能是一项夜间工作)。在Name_Element 上索引tbl_Entity_Name_Elements,您应该能够相当快地获得包含所有给定单词列表的Entity_ID 值,并且应该可以进行SARG。这为您提供了您需要的 tbl_Entity 项目。这有意义吗?

【讨论】:

  • 这是个好主意。在其中一个实验中,我尝试过这种方法它确实带来了价值,但它仍然不够快。尤其是当有很多匹配项时,最具挑战性的部分是足够快地对结果进行优先排序(以显示给定州和城市的顶级记录,以及来自给定州但其他城市然后所有其他城市的顶级记录)
  • 你有没有看过一个评分函数,你得到一个匹配状态的分数,另一个匹配城市的分数,然后将Order by Proximity_Score Desc扔到你的查询中?另外,我不得不问:究竟是什么推动了亚秒级查询执行要求?这些数据是如何被消费的? SQL Server 查询性能真的是用户体验的瓶颈吗?
  • 你的评论让我重新审视了这个想法,经过进一步的架构改进后,我在这里取得了一些进展,所以我接受你的回答
  • 我很高兴听到这个消息,@Stanislav。如果您愿意分享,我很想知道您的查询运行速度有多快。
猜你喜欢
  • 2019-08-07
  • 1970-01-01
  • 2015-08-02
  • 1970-01-01
  • 2016-03-17
  • 1970-01-01
  • 2016-03-09
  • 2012-11-01
  • 1970-01-01
相关资源
最近更新 更多