string作为SQL数据库中的主键
我不太了解数据库和他们工作背后的理论。 从性能的angular度来看（插入/更新/查询）使用主键的string比整数慢吗？
技术上是的，但如果一个string是有意义的主键，那么你应该使用它。 这一切都取决于你所做的表的大小和将成为主键的string的长度（较长的string==难以比较）。 我不一定会使用具有数百万行的表的string，但是通过在较小的表上使用string来获得性能下降的数量对于令人头痛的问题来说是微不足道的，这与数据无关。
使用string作为主键的另一个问题是，因为索引是不断按顺序排列的，所以当一个新键被创build时，索引必须被重新sorting…如果你使用自动数字整数，新的关键字刚刚添加到索引的末尾。
插入到具有在序列中间插入的聚集索引的表格不会导致索引被重写。 它不会导致组成数据的页面被重写。 如果在该行所在的页面上有空间，则将其放置在该页面中。 单个页面将被重新格式化，以将该行放置在页面的正确位置。 当页面已满时，将会发生页面拆分，页面上的一半行将转到一页，另一半转到另一页。 这些页面然后被重新链接到包含具有聚集索引的表格数据的页面的链接列表中。 最多只能写2页的数据库。
string在连接中速度较慢，在现实生活中，它们很less是非常独特的（即使它们应该是）。 唯一的好处是，如果你join到主表只是为了获得名字，他们可以减less连接的数量。 然而，string也经常发生变化，从而造成当公司名称改变或结婚时必须修复所有相关logging的问题。 这可能是一个巨大的性能影响，如果所有应该相关的表都不相关（这比你想象的更频繁），那么你也可能有数据不匹配。 从数据完整性angular度以及从性能angular度来看，在整个logging生命周期中永远不会改变的整数是更安全的select。 自然键通常不太适合维护数据。
我也想指出，两个世界的最好的经常是使用一个自动增量密钥（或在一些特殊情况下，一个GUID）作为PK，然后把一个唯一的索引在自然键上。 你得到更快的连接，你不会得到重复的logging，并且你不必更新一百万个子logging，因为公司名称已经改变。
只要它是唯一的，不pipe你用什么主键。 如果您关心速度或数据库devise，请使用int，除非您计划复制数据，然后使用GUID。
如果这是一个访问数据库或一些小应用程序，那么谁真正关心。 我认为，我们大多数开发人员在前面拍拍旧的int或guid的原因是因为项目有一种在我们身上成长的方式，而且你想让自己成长的select。
variables太多。 它取决于表的大小，索引，string关键域的性质…
一般来说 ，整数会更快。 但是这个差别足够大吗？ 这很难说。
另外，你selectstring的动机是什么？ 数字自动递增键通常也非常容易 。 它是语义吗？ 方便？ 复制/断开的担忧？ 你的答案可能会限制你的select。 这也让人想起你忘记的第三个“混合”选项：Guids。
不要担心性能，直到你有一个简单和完善的devise，符合数据描述的主题，并符合数据的预期用途。 那么，如果性能问题出现，你可以通过调整系统来处理它们。
在这种情况下，使用string作为自然主键几乎总是更好，只要您信任它即可。 不要担心，如果它是一个string，只要string是相当短的，说大约25个字符。 在性能方面你不会付出太多的代价。
数据录入人员或自动数据源是否总是为所假定的自然键提供一个值，或者有时被忽略？ input数据偶尔会出错吗？ 如果是这样，那么如何检测和纠正错误？
指定查询的程序员和交互式用户是否可以使用自然键来获得他们想要的？
如果你不能相信自然的钥匙，发明一个代理人。 如果你发明一个代理人，你也可以发明一个整数。 那么你不得不担心是否隐瞒用户社区的代理人。 一些没有隐藏代理键的开发者后悔了。
是的，但除非您希望有数百万行，不要使用基于string的键，因为速度较慢通常是“不成熟的优化”。 毕竟，string以大号存储，而数字键通常以小号存储。
不过要注意的一点是，如果你在任意键上都有聚簇索引，并且在索引中做了大量的非顺序插入操作。 每行写入都会导致索引重新写入。 如果你正在做批量插入，这可以真正减慢进程。
指数意味着大量的比较。
通常情况下，string比整数长，整理规则可能被用于比较，所以比较string通常比计算整数的计算密集型任务。
但有时，使用string作为主键比使用string进行额外连接更快。
使用PK列整数的两个理由：
-
我们可以设置自动递增的整数字段的标识。
-
当我们创buildPK时，数据库会创build一个索引（集群或非集群），在数据存储在表中之前对其进行sorting。 通过在PK上使用标识，优化器在保存logging之前不需要检查sorting顺序。 这可以提高大表的性能。
你有什么理由把string作为主键？
我只是将主键设置为自动递增整数字段，并在string字段上放置一个索引。
这样，如果你在桌面上进行search，他们应该是相对较快，所有的联接和正常的查找速度将不受影响。
您还可以控制获取索引的string字段的数量。 换句话说，如果你觉得足够的话，你可以说“只索引前5个字符”。 或者如果你的数据可以比较相似，你可以索引整个领域。
从性能angular度来看 – 与使用整数（PK）（其中PK —>主键）相比，是string（PK）会降低性能。
从要求的angular度来看 – 虽然这不是你问题的一部分，但我还是要提一下。 当我们处理跨越不同表的大量数据时，我们通常会查找可以为特定表设置的可能键集。 这主要是因为有很多表格，大多数表格都是通过某种关系（一个外键的概念）与另一个表格相关联的。 因此，我们实际上不能总是select一个整数作为主键，而是将3,4或5个属性组合为主键。 当我们将logging与其他表关联起来的时候，这些键可以作为外键使用。 这使得在需要时将logging跨不同的表进行关联是很有用的。
因此，为了最佳使用 – 我们总是将1或2个整数与1或2个string属性组合在一起，但是只有在需要的时候也是如此。
数据库中的string可能会有一个很大的误解。 几乎每个人都认为数字的数据库表示比string更紧凑。 他们认为在db-s中的数字表示在内存中。 但事实并非如此。 在大多数情况下，数字表示更接近像其他字符一样的表示。
使用数字或string的速度更依赖于索引，然后是types本身。
默认情况下ASPNetUserIds是128个string，性能performance还不错。
如果密钥HAS在表中是唯一的，那么它应该是密钥。 这是为什么;
主键string键=正确的数据库关系，1个string键（主键）和1个string索引（主键）。
另一个选项是一个典型的int Key，但是如果stringHAS是唯一的，你可能还需要添加一个索引，因为不停的查询来validation或检查它的唯一性。
所以使用一个int标识键=不正确的数据库关系，1个int键（主键），1个int索引（主键），可能是一个唯一的string索引，并手动必须validation相同的string不存在）。
为了获得更好的性能使用主键string的整数，当string必须是唯一的，这将是一个非常奇怪的情况。 我一直喜欢使用string键。 作为一个好的经验法则，在你需要的时候不要去规范数据库。
