- 当为字段上的唯一约束创建数据库索引或为多个字段唯一约束创建多个索引时,这些相同的索引是否能够在查询对象时用于提高效率,就像任何其他数据库索引一样用来?我的猜测是,为唯一约束创建的索引与为提高效率而创建的索引相同,唯一约束本身是额外的,但我并不精通数据库。
- 是否有可能通过长事务和高并发等以任何方式打破唯一约束,包括多字段约束(例如 field_a 和 field_b 是唯一的)?或者,唯一约束是否提供 100% 的保护。
3 回答
是的。唯一约束是索引(在 SQL Server 中),将(可以)用于查询计划
这是不可能的。无论事务时间或并发问题如何,您都不能将数据存储在违反约束的表中(至少在 SQL Server 中)。顺便说一句,如果您的交易时间太长以至于您对此感到担心,那么您需要重新考虑在此交易的背景下您在做什么。即使您不会通过长事务操作违反数据库约束,您也会遇到其他问题。
关于问题1:
是的 - 这些是您定义的任何其他索引的索引,并用于查询计划中,例如用于提高性能......您可以定义唯一索引而不定义“唯一约束”顺便说一句。
关于问题2:
是的 - 只要数据库引擎符合 ACID 且可靠(即在这方面没有错误)并且您不暂时禁用约束,它就是 100% 的保护。
您的问题的问题是,它非常笼统,不适合特定的实现。因此,任何答案都将是非常通用的。
在这个想法中:
每当数据库认为通过索引进行访问可能会加快速度时,它就会这样做——这里不关心唯一性。如果一个表上存在许多索引,那么一个体面的数据库将尝试使用“最佳”的一个 - 对于“最佳”的实际含义有不同的看法。但是 许多数据库只会使用一个索引来获取一行。因此,根据经验,数据库通常会尝试使用 indizes,其中查找会导致尽可能少的行。唯一索引非常擅长这一点。:-)
其实这不是一点,而是两个不同的点:
即使是长时间运行的事务或高并发,一个体面的数据库也不会破坏您的索引。至少不是故意的。如果是这样,要么是数据库软件中的一个错误,必须非常迅速地修复 - 否则数据库供应商可能会以非常严重的方式遭受声誉损失。另一种可能性是,它不是一个像样的数据库,而只是一个持久的哈希图或类似的东西。如果数据真的很重要,那么高并发和长时间运行的事务就不是借口了。
多值唯一索引是一头野兽:数据库实现略有不同,当一个或多个键列包含
NULL
. 例如,您可以查看有关这一点的 PostgreSQL 文档:http ://www.postgresql.org/docs/9.1/interactive/indexes-unique.html
希望这能让一些事情变得清楚。