Question

我有一个现有的桌面数据库，正在mysql服务器中复制。当前数据库具有一个客户表，并且其中一个字段表示公司服务的区域。区域如下：1A，1B，2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17。

要进行设置以匹配其现有数据集，我设置了一个参考表（customer_zones），其中区域以一对多关系链接到Customers表。每个区域可以有许多客户。每个客户只有一个区域。

问题是“ 1A”和“ 1B”区域不允许我在customer_zones表上设置int主键。我必须使用varchar（2）作为主键。这是好习惯吗？或最佳解决方案？

Answer 1

主键是聚簇索引，表中数据的物理表示是因为主键和数字搜索比字符串快。

根据您的情况，以下是方法。

方法A

如果您为表varchar(2)中的主键字段选择区域ID作为customer_zones，则可以将其引用到customer表中的外键字段，这可能是解决。

方法B

如果您将主键用作表integer中的customer_zone，则要存储1A，1B等区域，您需要再有一个字段，并且在该字段上，您需要唯一键还可以避免数据重复。

如果您遵循方法A，则更好，因为对于相同的功能，一个约束会更简单。

Answer 2

我主张使用PRIMARY KEY(zone)和VARCHAR(2)，而不是替代AUTO_INCREMENT：

与算术/字符串比较/函数/等的详细信息相比，查询触及的行数是影响性能的重要因素。
即使有数百万行，“数字快于字符串”也不太可能引起人们的注意。
如果更改为代理人会涉及额外的JOIN，那就是额外的开销。
（手动查看数据时）查看“ 1A”和“ 16”等更为方便。
我发现3分之二的人使用“自然” PRIMARY KEY，而不是“替代”（AUTO_INCREMENT）。对于多对多映射表，使用复合PK代替代理显然更有效率。

在您的情况下，我建议进行次要优化：

 VARCHAR(2) CHARACTER SET ascii

这避免了utf8的次要开销。

我为GUID，UUID，sha1，md5，ip_address，country_code，postal_code，邮政编码电话号码等设置了类似的参数。对于真正固定长度的字段（例如2个字母的country_code），请使用CHAR(2)而不是{ {1}}。