通过添加索引列来优化SQL数据库

Question

说我看起来像这样的数据库;

Product with columns [ProductName] [Price] [Misc] [Etc] 
Order with columns [OrderID] [ProductName] [Quantity] [Misc] [Etc] 

ProductName是Product的主键，一些字符串类型和唯一的。
OrderID是主键和某种整数类型，而ProductName是外键。

假设我将产品的主键更改为整数类型的新列，即[ProductID]。

这会减少数据库大小并优化加入这两个表（以及类似的操作）的查找，还是这些优化是由（most/general/main）自动执行的SQL数据库实现？

从技术上讲，使用（字符串）产品名称为Product主键，一个数据库应该能够在Order实施ProductName列作为只是一个指向行中Product，并执行JOIN作为quicly作为一个有整数一个外键，这是一个实现SQL的标准方式。

更新： 这个问题是关于如何SQL服务器处理的外键，而不是产品是否表需要序列号，或者我如何处理与数据库中的产品名称更改。

Answer 1

字符串主键是一个坏主意，所以将其更改为INT将有助于提高性能。大多数数据库使用主键索引进行查找和比较，如果可能的话，选择一个简短的主键 - 一列。您可以使用主键列进行联接（根据联接列中的公共值将两个或多个表中的数据组合起来），查询检索以及对查询结果集进行分组或排序。索引条目比较简单，数据库可以执行查找和比较的速度更快。

更何况，如果产品名称发生变化，您如何处理？将包含产品名称的所有行更新为外键？

我不能说这更好，所以看看这个答案：Should I design a table with a primary key of varchar or int，从这个问题的答案报价：

使用VARCHAR（10）或（20）只使用 了太多的空间 - 10或20字节 而不是4，以及许多人 不知道 - 将在表上的每个非集群 索引上的每个索引 上重复聚簇键值 ，因此潜在可能， 你浪费了很多空间（不是 只是在磁盘上 - 这是便宜的 - b在SQL Server的主内存中也是 ）。此外， 因为它的变量（可能是4，可能 为20个字符），它是很难SQL服务器 正确地保持良好的指数 结构

Answer 2

整数列的作用不是字符串更好地加入

整数autoinc列作为主聚簇键是非常适合插入的

Answer 3

我不会减小数据库大小（大概你会保留产品名称字段），但应该明显提高查找性能。在大多数实现

Answer 4

整数数据类型，会比字符串（CHAR，VARCHAR等）少的大小，这会让你的索引大小。

此外，也有一些问题比较字符串：

1. 一些数据库，即MySQL，压缩字符串键，可以使搜索效率较低。

2. 使用自然语言标识符的字符串B-Trees倾向于比整数B-Trees更少的并发性平衡。由于自然语言单词不是均匀分布在整个字母表中，所以更多更新和插入操作将转到同一个块，从而增加页面拆分的次数并最终增加索引大小。要解决此问题，Oracle支持索引中的REVERSE子句。

3. 比较两个字符串时，应该考虑整理。通常情况下，这并不重要，但它确实会增加一些开销。

Answer 5

主键应该是唯一的，在创建行时存在并且尽可能不可变。海事组织，关于是否使用代理键的讨论应该是数据完整性问题的次要问题。

举例来说，如果一个产品有盖章的项目，其中有在被输入数据库中该行的时间存在一个序列号，并保证是唯一的，那么IMO将成为一个好主键。原因是这个值将被用作其他表中的外键，并且可以节省额外查找的费用来获取产品的序列号。额外的存储空间是无关紧要的，直到你进入数百万行。但是，如果序列号由其他制造商标记，因此您不能保证唯一性（“可能是独特的”不够好），那么代理是适当的。事实上，如果不是大多数“产品”表使用代理键，我甚至会说很好的一部分，因为没有保证在输入时可用的值，保证是唯一的并且将是相对不变的关键。

然而，使用代理键许多开发商忽略了需要一个每表具有代理键应该也有另一个密钥（即唯一性约束）。因此，就产品而言，即使您添加了一个整数主键，您仍然应该对产品名称有一个唯一的约束。产品名称的唯一约束创建了所谓的候选键，其中整数值是主键。

代理键的意图是幕后黑客。虽然整数键表现最好，而且易于创建，但它们有一个缺点：即使应用程序开发人员向用户显示关键价值，也很容易，甚至是很诱人。这是IMO的错误。用户不应该看到关键值，否则他们会依赖于值本身，如果您需要重新排列值（如说与数据库合并），或者如果您使用在由身份价值，他们依赖的价值观是顺序的。只要你从不向用户展示价值，使用整数PK就没有问题。