我正在建立一个速度至关重要的预测拨号器。要拨打该号码，我从表格中提取客户信息并构建呼叫文件，以便pbx进行操作。
目前我有一个表格用于每个区号，我们一次拨打一个区号，但我们正在切换到一个型号，我们根据跨越多个邮政编码的区域进行拨号。一些区号存在于多个邮政编码中。每个表都有每月添加的新号码，并通过与数百万个号码的拒绝呼叫列表进行比较来清除。
所以我的问题是，我应该如何最有效地组织这些数据？
一个大表似乎反效果，因为我们正在谈论数百万个擦洗数据记录。
我目前的推理方法是维护用于导入和清理的区号表，然后将清理后的记录复制到区域表，通过在区域代码表中搜索区域中的邮政编码来创建。
我目前通过auto_incremented INT主键，唯一的电话号码以及跟踪已经被呼叫的号码或者在拒绝呼叫列表中的状态来索引表。构建调用文件时，我将记录标记为已排队，然后根据调用完成后的调用方式对其进行标记，因此对于每个调用，都会进行搜索和两次更新。
搜索在区域代码表中查找特定状态。更新基于记录ID进行。
问题的关键在于：通过邮政编码和按状态搜索是否更快，或者按地区代码组织并按状态和邮政编码搜索？或者更好的选择是每次我们设置从区号表建立的区域时创建一个新表？
请原谅我，如果这看起来像一个愚蠢的问题，我一直在自学SQL，因为我一直在构建这个，数据库设计和性能的细微差别有点超出我的技能。
表的总大小为200万行且不断增长。
答案 0 :(得分：2)
问题的关键在于：通过邮政编码和按状态搜索是否更快，或者按地区代码组织并按状态和邮政编码搜索？或者，每次我们设置从区号表构建的区域时，最好是创建一个新表吗？
答案：除非你真的知道自己在做什么，否则不要做任何这些。而是创建一个表来保存这个实体的所有行，使用列值来区分各种邮政编码和地区。可能会创建zipcodes和territory表，并添加引用它们的外键。
基于属性值创建单独的表不是典型的解决方案，并且会引入许多其他困难（例如，如果按邮政编码组织表格，如何按地区搜索所有邮政编码？）
更常见的解决方案和数据库擅长的解决方案是使用索引。使用多个索引，数据库可以提供对表的快速访问，以便在多个不同的列上进行搜索。
所以我建议的基本策略是：
explain <query>非常方便同样重要的是要注意，对于MySQL来说，200万行并不是一个巨大的数额（当然，这取决于负载）。最重要的是，优化是一个非常棘手的主题，其答案取决于您的具体情况。
答案 1 :(得分：1)
如果您想要速度，请将数据标准化不是您想要的。数据增长时速度性能会降低。
在这种情况下的性能将与硬盘的速度相关联，ssd可能会大幅提升性能，但是你会遇到空间问题并且更加昂贵
权衡可以使用旋转磁盘而不是规范化数据。索引用于搜索的字段。
其他策略（更聪明）可以使用整数代码来表示可以在数据集上重复的数据，并使用内存中的邮政编码，城市等的实际值（邮政编码，国家名称，城市是数据）这是不可变的，但这种方法为问题增加了新的依赖关系。
我有一个包含2.5亿行的表格，此信息标有国家和城市，邮政编码和ISP。我有ssd存储主要数据，地理数据存储到memcached中，当我需要进行一些搜索时，我有一个逻辑层来进行查找并在数据库中进行代码转换。
答案 2 :(得分：0)
TaoNonnanes，territory每次都不需要创建area code table表。
只使用area code table的外键只创建了一个区域表，只需为区域和区号代码表创建索引，并尝试将整个数据库规范化至少3NF。我不知道你的整个数据库规范化是什么。