有关数据库索引的问题

Question

1. 当为字段上的唯一约束创建数据库索引或为多字段唯一约束创建多个索引时，在查询对象时，这些索引是否能够用于提高效率，这与任何方法相同使用其他数据库索引？我的猜测是，为唯一约束创建的索引与为提高效率而创建的索引相同，而且唯一约束本身是额外的约束，但我并不精通数据库。
2. 是否有可能通过长事务和高并发等以任何方式打破唯一约束，包括多字段约束（例如field_a和field_b是唯一的）？或者，唯一约束是否提供100％保护。

Answer 1

1. 是。唯一约束是索引（在SQL Server中），并且（可以）在查询计划中使用

2. 这是不可能的。无论事务时间或并发问题如何，都无法将数据存储在违反约束的表中（至少在SQL Server中）。顺便说一句，如果你的交易太长而你担心这个问题，你需要重新考虑你在这次交易中所做的事情。即使您不会因长事务操作而违反数据库约束，您也会遇到其他问题。

Answer 2

关于问题1：

是 - 这些索引与您定义的任何其他索引一样，并且在查询计划中用于例如性能提升......您可以定义唯一索引而无需定义“唯一约束”顺便提一下。

关于问题2：

是 - 只要数据库引擎符合ACID且可靠（即在这方面没有错误）并且只要您不暂时禁用约束，它就是100％保护。

Answer 3

您的问题的问题在于，它非常通用，不适合特定的实施。因此，任何答案都是非常通用的。

在这个想法中：

1. 每当数据库认为，通过索引进行访问可能会加快速度，它会这样做 - 这里不关心唯一性。如果一个表上存在许多indizes，体面的数据库将尝试使用“最佳”数据库 - 对“最佳”实际意味着什么的不同观点。 BUT 许多数据库只会使用一个索引来获取一行。因此，根据经验，DB通常会尝试使用indizes，其中查找会导致尽可能少的行。一个独特的指数非常擅长。 ： - ）

2. 实际上，这不是一点，而是两点不同：

   • 即使是长时间运行的事务或高并发性，体面的数据库也不会破坏您的索引。至少不是故意的。如果确实如此，那么数据库软件中的错误要么必须快速修复非常 - 否则数据库供应商可能会以非常激烈的方式遭受声誉损失。另一种可能性是，它不是一个体面的数据库，而只是一个持久的hashmap或类似的东西。如果数据真的很重要，那么高并发和长期交易就不是理由。

   • 多值唯一索引是一种野兽：数据库实现是不同的，当一个或多个关键列包含NULL时，它们认为是“唯一的”。例如，您可以查看关于这一点的PostgreSQL文档：http://www.postgresql.org/docs/9.1/interactive/indexes-unique.html

希望这能使事情变得清晰。