当标识 唯一行时，它的用途是什么？ 为什么人们使用标识列作为主要键？ 任何人都可以简单地描述答案吗？
答案 0 :(得分：2)
主键是一个逻辑概念 - 它是您唯一标识表中每条记录的方法。有几种类型的主键 - 自然键使用来自业务域的数据属性，该属性保证具有主键（唯一，非空，不变性）的要求，例如社会安全号，复合键是密钥由多个列组成（通常用于＆＃34;父子和＃34;关系），并且系统创建代理键;它可以是自动增量或标识列。
身份是一种数据类型。它用作代理主键非常有用，因为它具有所需的所有属性。您不太可能将身份类型用作主键之外的目的，但没有什么可以阻止您这样做。
因此，并非所有主键都使用标识数据类型，并非所有标识列都是主键。
答案 1 :(得分：1)
主键是一种唯一键。事实上，它是一个限制（约束），特定列（或者，通常情况下，列集）的值在不同的行中不能相同（即使使用插入/更新手动/显式设置为相同的值）
主/唯一键不需要是自动递增的。事实上，它根本不需要是整数 - 它可以是文本或其他类型。
主键比通常的唯一键更严格，因为它通常意味着NOT NULL，除此之外，每个表只允许一个主键（除了每个表允许几个唯一键）主键）。
创建主/唯一键通常会隐式创建一个索引，以便更快地对该列进行搜索和约束检查。
E.g。如果my_column的{{1}}列被标记为主键或唯一键，则无法执行此操作：
my_table标识是其他RDBMS可以调用 auto_increment 或 serial 的内容。这只是一个特性，在行插入操作期间，特定列在未明确设置为某个值时会自动初始化为（最常见的）连续整数值。
E.g。如果INSERT INTO my_table (my_column, other_column, third_column)
VALUES (10, …, …);
INSERT INTO my_table (my_column, other_column, third_column)
VALUES (10, …, …); -- the same value for my_column again
的{{1}}列标记为auto_increment / serial / identity，则可以执行以下操作：
my_columnAuto_increment / serial / identity通常不保证严格自动值的结果（特别是在中止事务的情况下）。
具体而言documentation for TRANSACT-SQL表示身份并不能保证：
更新：作为a_horse_with_no_name suggested，“identity”似乎不仅是特定RDBMS（例如Microsoft SQL Server）中常见的auto_increment / serial / identity功能的名称，而且由ANSI SQL标准定义的名称。
AFAIK，它与我上面描述的非常（关于实现中常见的auto_increment / serial / identity功能）。我的意思是它使列值自动用整数序列初始化，但不保证唯一性和严格的结果。
但是，我认为，与MySQL / PostgreSQL中的auto_increment / serial列不同，ANSI-SQL标准my_table列不允许在INSERT或UPDATE中手动设置其值（仅限 自动）。
答案 2 :(得分：0)
主键所需的唯一编号和主键值不能为null，可以通过标识获取，我们不需要手动添加每个添加到表中的新记录。
当记录由于某种原因而在表中插入失败时，sql server中的时间也会增加。
答案 3 :(得分：0)
In a database table, every row should be unique, and you need to be able to identify a particular row uniquely.
A given table may have one or more columns which have unique values, so any of these columns can do the job. There may also be two or more columns which, while not unique of themselves, form a unique combination. That will also do.
Any column, or combination of columns, which can uniquely identify a row is called a candidate key. In principle, you can choose any key that you like, but you need to ensure that uniqueness is enduring. For example, in a small table of persons, the given name may be unique, but you run the risk of blowing that with the next additional person.
A primary key is the candidate key you nominate as your preferred key. For example, a table of persons may have a number of unique attributes such as email address, mobile phone number and others. The primary key is the attribute you choose in preference to the others.
The following is not strictly required, but is good practice for a good Primary Key:
For this reason, a Primary Key shouldn’t have any real meaning, so there should never be a reason to change or reuse it. As a result, the primary key is often an arbitrary code whose only real meaning is that it identifies the row. If the key is purely used for identification and has no other meaning, it is often referred to as a Surrogate Key.
You can put some effort into generating arbitrary codes. Sometimes they follow complex patterns which can be used to check their validity.
If you want to take a lazier approach, you can use a sequence number. Contrary to my previous advice, though, it does sort of have a meaning: it is strictly sequential, so you can learn which row was added after another, but not exactly when. However, that fact won’t change — it will not change in value, and will not be reused — so it’s still pretty stable.
An identity column is, in fact, a sequence number. It is auto-generated, and very useful if you want an arbitrary code for your primary key. Unfortunately it is relatively late to the very slow moving standards, so every DBMS had its own non-standard variation:
AUTO_INCREMENTAUTOINCREMENTAUTONUMBERSERIALand each has its own quirks.
More recently, (2003, I belive) it has been added to the standards in the form of:
int generated by default as identity
but this has only just started to appear in PostgreSQL and Oracle. This use of IDENTITY behaves differently to Microsoft’s.