问题标签 [indexing]

我记得有一次读到，索引具有低基数（少量不同值）的字段并不值得做。我承认我对索引的工作原理知之甚少，无法理解为什么会这样。

那么，如果我有一个包含 1 亿行的表，并且我正在选择位字段为 1 的记录，该怎么办？假设在任何时间点，只有少数记录位字段为 1（而不是 0）。是否值得索引该位字段？为什么？

当然我可以测试它并检查执行计划，我会这样做，但我也很好奇它背后的理论。基数什么时候重要，什么时候不重要？

为什么数据库不根据查询频率自动索引表？是否存在任何工具来分析数据库及其接收的查询，并自动创建或至少建议创建哪些索引？

我对 MySQL 特别感兴趣，但我也对其他数据库感到好奇。

我在一个表上创建了一个多列数据存储，它允许我对表进行全文索引。我需要做的是对每一列进行不同的加权并将分数加在一起。

以下查询有效，但速度很慢：

经过相当多的谷歌搜索，人们提出了解决方案：

上面的查询比它的前任更快，但它并没有解决实际问题。在这种情况下，如果在 documentTitle 中找到关键字，则不会搜索 documentText（它使用 OR 运算符）。我真正需要的是把这两个分数加在一起，这样如果一个关键字出现在标题和文本中，它的分数就会比它只出现在标题中的分数高。

那么，如何在一个 CONTAINS 子句中添加加权列的分数？

我似乎无法在普通 Windows 窗体中以编程方式在 WPF 中滚动我会使用下面的代码，但 WPF 中不存在该属性。

有没有其他方法可以做到这一点？

I am synchronizing tables using a stored PL/SQL procedure as part of a web application - when they hit a button it does the sync. The PL/SQL is executing as user A, but needs to disable indexes and sync a couple of tables in schema B. I can't get user A to 'alter index B.indexName unusable' despite granting it 'alter any index', and in desperation even DBA. The error is ORA-01418: specified index does not exist. This is working on another developer's sandbox but I can't figure out why. Any suggestions will be appreciated.

在保持旧的 id 系统的同时将几个重叠的 id 系统统一为一个统一的系统的最佳方法是什么。

我的网站上有几个不同的 id...（例如 /publisher/1234 和 /designer/1234） 我想将这些 id 统一到一个新系统中，但想保留旧系统的功能。

Lucene 是一个优秀的搜索引擎，但是 .NET 版本落后于官方 Java 版本（.NET 最新的稳定版本是 2.0，但是最新的 Java Lucene 版本是 2.4，它有更多的功能）。

你如何解决这个问题？

“我们应该忘记小的效率，比如大约 97% 的时间：过早的优化是万恶之源。” （唐纳德·克努斯）。我的 SQL 表不太可能每个包含超过几千行（这些都是大行！）。SQL Server 数据库引擎优化顾问认为数据量无关紧要。所以我什至不应该考虑在这些表上放置显式索引。正确的？

I have a query on my database as such:

I have added an index to the table on both the user_id and dated_on columns. When I inspect the indexes using SHOW INDEXES FROM expenses, there are two lines -- one with a seq_in_index value of 1, the other with a seq_in_index value of 2.

My question is, if I then submit a query which uses only one of the two WHERE clauses, e.g.:

Is there any benefit to creating another index which solely indexes the user_id column, or will the user_id/dated_on index described above be used just as efficiently?

Finally, how about if use the query:

How does the seq_in_index value of 2 affect index use and performance in this situation?

为了摆脱重建和碎片整理留下的一些碎片，我们认为我们会删除并创建索引，所以我开始编写一个脚本。

它识别需要工作的聚集索引并删除索引和主键并重建表的索引和主键。

这是我遇到的问题：SQL Server 使用自己独特的命名系统根据统计信息创建了很多自己的索引。

问题：我只想删除和创建我们创建的索引，还是我想删除所有索引并只创建我们创建的索引，或者我们想删除所有索引，包括 SQL Server 制作的索引，并创建所有索引，包括SQL Server 制作的那些？