在 SQLite 的低基数列上选择多行答案

【问题标题】：Select many rows on low-cardinality column in SQLite在 SQLite 的低基数列上选择多行
【发布时间】：2019-10-26 03:43:11
【问题描述】：

我在 SQLite 中有一个包含很多行的表，并且我经常需要基于几乎均匀拆分的二进制列选择所有行（例如男性/女性）。查询中没有其他必须满足的条件。我知道在这种情况下索引不好，但是有没有其他方法可以使这个速度变快？像排序表之类的东西？我猜除了制作两个单独的表格。

编辑：如果 SQLite 中没有，是否可以在另一个基于 SQL 的 RDBMS 中使用？

【问题讨论】：

呃...索引“就像对表格进行排序”。要么忽略之前的建议，要么提供一个很好的参考来说明为什么在这种情况下索引是一个坏主意。此外，表格内容是否变化很大，还是主要是静态的？我无法想象强迫系统在每个查询中重新扫描整个表比使用不太理想的索引要好。两张表听起来像是一个非常烦人的选择，尤其是如果您确实有其他查询。我不明白为什么必须做 UNIONS 和跳过其他箍会比索引更好。
在 SQLite 和另一个基于 SQL 的 RDBMS 之间做出决定可能应该基于many other factors，而不仅仅是是否索引一个表。特别是因为 SQLite 是一个嵌入式数据库，专为满足本地、无服务器数据库的特定需求而设计，而大多数其他 SQL RDBMS 将是服务器并满足其他需求。
当然，基于这些因素，我选择了 SQLite（无服务器是一个很大的好处，主要是只读数据库，用户很少）。虽然大小很大，但我的印象是 SQLite 的查询速度与其他系统一样快（可能更快，因为没有服务器层并且数据库太大而无法保存在内存中）。无论如何，我还是缺少 SQLite 中的一些功能，例如物化视图，因此如果有其他优势，可以选择切换。
我还发现，由于许多索引查找效率较低的各种原因，有这样的“低基数”索引比没有索引更糟糕。对于外键的 lookup 或辅助搜索（例如，在其他索引用于主排序之后），也许这是真的。但是如果这样的索引用于简单的选择，一个好的优化器可以将表划分为行块以进行有效处理，而不是查询每一行的索引。老实说，我不准备为 sqlite 争论一种或另一种方式，但我认为忽略/忽略是不好的。测试一下。

标签： sqlite select cardinality

【解决方案1】：

我了解到这种情况下索引不好

在这些事情上总是有利弊需要考虑，所以真正重要的是你对它们的重视程度。换句话说，通常建议自己进行尽职调查，而不是依赖别人的经验法则。

在我对具有 100 万行且二进制列在 0 和 1 之间均匀拆分的 SQLite 数据库的计时中，SELECT COUNT(*) WHERE binary = 0; 使用索引显着加快了速度。以下是 u+s 次：

   without an index: 0.06 secs
   with an index:    0.04 secs

对于 10m 行，差异更加明显。

【讨论】：