问题标签 [indexing]

例如，我的查询使用 SQL Server 2005 如下所示：

我定义了一个全文索引以使用 SearchField 列，该列在使用时返回结果：

我相信 # 是一个特殊的字母，那么如何让 FREETEXT 对上述查询正常工作？

鉴于索引随着数据集大小的增加而变得如此重要，有人可以解释索引如何在与数据库无关的级别上工作吗？

有关对字段进行索引的查询的信息，请查看如何索引数据库列。

希望我能得到每个数据库服务器的答案。

有关索引如何工作的概述，请查看：数据库索引如何工作？

我有几个表，其唯一的唯一数据是唯一标识符（Guid）列。因为 guid 是非顺序的（并且它们是客户端生成的，所以我不能使用 newsequentialid()），所以我在这个 ID 字段上创建了一个非主索引、非聚集索引，而不是给表一个聚集主索引钥匙。

我想知道这种方法对性能的影响是什么。我见过一些人建议表应该有一个自动递增（“身份”）int作为集群主键，即使它没有任何意义，因为这意味着数据库引擎本身可以使用该值快速查找一行，而不必使用书签。

我的数据库在一堆服务器上进行了合并复制，所以我避开了 identity int 列，因为它们在复制中有点麻烦。

你怎么认为？表应该有主键吗？或者，如果没有合理的列以这种方式建立索引，那么没有任何聚集索引是否可以？

我刚刚在 WHERE 子句中遇到了这个问题：

这与以下相比如何：

或与：

我总是自己写后者，但显然其他人的想法不同。一个会比另一个表现更好吗？我知道使用<>或!=会破坏使用我可能拥有的索引的任何希望，但肯定上面的第一种方法会遇到同样的问题吗？

我有一个查询，我正在搜索一个字符串：

现在，这工作正常，但它不能很好地扩展，我需要优化它。我找到了一个类似于创建生成视图的选项，或者类似的东西，但我希望使用索引有一个更简单的解决方案。

我们正在使用 DB2，我真的想在 index 中使用表达式，但是这个选项似乎只在 z/OS 上可用，但是我们正在运行 Linux。我还是尝试了表达式索引：

但当然，它会在 UPPER(name) 上窒息。

有没有另一种方法可以以这种方式创建索引或类似的东西，这样我就不必重组现有查询以使用新生成的视图，或更改现有列或任何其他此类侵入性更改？

编辑：我愿意听取其他数据库的解决方案......它可能会延续到 DB2......

既然 aTable Scan和 aClustered Index Scan本质上都扫描表中的所有记录，那么为什么聚集索引扫描应该更好呢？

举个例子 - 当有很多记录时，以下之间的性能差异是什么？：

从我能找到的信息来看，它们都解决了相同的问题——更深奥的操作，如数组包含和交集（&&、@>、<@ 等）。但是，我会对有关何时使用其中一种（或两者都不可能）的建议感兴趣。PostgreSQL 文档有一些关于此
的信息：

• GIN 索引查找比 GiST 快大约三倍
• GIN 索引的构建时间大约是 GiST 的三倍
• GIN 索引的更新速度比 GiST 慢十倍左右
• GIN 索引比 GiST 大两到三倍

但是，我特别想知道当内存与索引大小的比率开始变小时（即索引大小变得比可用内存大得多）时是否会对性能产生影响？我在#postgresql IRC 频道上被告知 GIN 需要将所有索引保存在内存中，否则它不会有效，因为与 B-Tree 不同，它不知道从磁盘读取哪个部分一个特定的查询？问题是：这是真的吗（因为我也被告知相反的情况）？GiST 有同样的限制吗？在使用其中一种索引算法时，我还应该注意其他限制吗？

我有一个存储过程，它通过查询将 750K 记录放入临时表中，这是它的第一个操作之一。如果我在填充临时表之前在临时表上创建索引，则与填充表后索引时相比，该项目的运行时间大约是两倍。（索引是单列中的整数，被索引的表只有两列，每列一个整数。）

这对我来说似乎有点不对劲，但是我对引擎盖下发生的事情没有最坚定的理解。有人对此有答案吗？

我有一张有数百万行的表。我需要找到具有特定列值的所有行。该列不在索引中，因此会导致表扫描。

但是在头部添加一个索引（主键跟随），执行查询，然后删除索引会更快吗？

我无法永久添加索引，因为用户正在指定他们正在寻找的列。