1

我正在构建一个速度至关重要的预测拨号器。为了拨打这个号码，我从表格中提取客户信息并构建呼叫文件以供 pbx 采取行动。

目前，我为每个区号都有一个表格，我们一次拨打一个区号，但我们正在切换到一个模型，在该模型中，我们根据跨越多个邮政编码的领土进行拨号。一些区号存在于多个邮政编码中。每个表每月都会添加新号码，并通过与数百万个号码的请勿呼叫列表进行比较来清理。

所以我的问题是，我应该如何最有效地组织这些数据？

一张大表似乎适得其反，因为我们正在谈论数百万条已清理数据的记录。

我目前的推理是维护区号表以进行导入和清理，然后将清理后的记录复制到地区表中，通过在地区代码表中搜索该地区的邮政编码来创建。

我目前通过一个 auto_incremented INT 主键、一个唯一的电话号码和一个跟踪已被呼叫的号码的状态来索引这些表，或者在请勿呼叫列表中。在构建通话文件时，我将记录标记为排队，然后根据通话完成后的方式进行标记，因此对于每个通话，都会进行一次搜索和两次更新。

搜索在区域代码表中查找特定状态。更新基于记录 ID。

问题的核心是：按邮政编码组织并按状态搜索会更快，还是按区号组织它们并按状态和邮政编码搜索？或者每次我们建立一个从区号表构建的区域时，最好的办法是创建一个新表？

如果这似乎是一个愚蠢的问题，请原谅我，我一直在自学 SQL，因为我一直在构建它，并且数据库设计和性能的细微差别有点超出我的技能范围。

表的总大小为 200 万行并且还在增长。

4

3 回答 3

2

问题的核心是：按邮政编码组织并按状态搜索会更快，还是按区号组织它们并按状态和邮政编码搜索？或者每次我们建立一个从区号表构建的区域时，最好的办法是创建一个新表？

答：除非你真的知道自己在做什么，否则不要做任何这些。 相反，创建一个表来保存该实体的所有行，使用列值来区分各种邮政编码和地区。可能创建zipcodes和territory表，并添加引用它们的外键。

根据属性值创建单独的表格不是典型的解决方案，并且会引入许多额外的困难（例如，如果您按邮政编码组织表格，如何按地区搜索所有邮政编码？）

更常见的解决方案，也是数据库擅长的一种解决方案，是使用索引。使用多个索引，数据库可以提供对表的快速访问，以便在多个不同列上进行搜索。

所以我推荐的基本策略：

  1. 创建逻辑数据模型
  2. 实现物理数据模型
  3. 分析性能
    • explain <query>很方便
    • 如果还不够好，请考虑添加更多索引、改进现有索引的使用（阅读聚集索引和覆盖索引）或选择性非规范化
    • 选择和插入之间的平衡是什么？索引可以减慢插入速度

同样重要的是要注意，200 万行对于 MySQL 来说并不是一个巨大的数字（当然，这取决于负载）。底线是优化是一个非常棘手的主题，其答案取决于您的具体情况。

于 2012-04-30T17:54:05.623 回答
1

如果你想要速度，规范化数据不是你想要的。当数据增长时，速度性能会降低。

这种情况下的性能将与硬盘的速度有关，ssd 可能会大大提高性能，但是您会遇到空间问题并且价格更高

权衡可以使用旋转磁盘而不是规范化数据。索引用于执行搜索的字段。

其他策略（更聪明）可以对可以在数据集上重复的数据使用整数代码，并使用来自 memcache 的邮政编码、城市等的真实值（邮政编码、国家名称、城市是不是可变的），但这种方法为问题增加了新的依赖关系。

我有一个包含 2.5 亿行的表，这些信息用国家和城市、邮政编码和 ISP 标记。我有 ssd 来存储主要数据，地理数据存储在 memcached 中，当我需要进行一些搜索时，我有一个逻辑层来进行查找并转换为数据库中的代码。

于 2012-05-02T14:09:16.763 回答
0

TaoNonnanes，不需要territory每次都为area code table.

只制作了一张外键area code table为区域和区号表的索引的区域表，并尝试将整个数据库标准化至少到 3NF。我不知道您的整个数据库规范化是什么。

于 2012-04-28T04:59:42.460 回答