索引布尔字段

Question

这可能是一个非常愚蠢的问题,但是在索引数据库表中的布尔字段会有很多好处吗？

给定一个常见的情况,比如被标记为非活动的"软删除"记录,因此大多数查询都包括在内WHERE deleted = 0,是否有助于将该字段单独编入索引,或者是否应将其与其他常用搜索字段组合在一起.不同指数？

Answer 1

没有.

您索引搜索的字段并具有高选择性/基数.布尔字段的基数几乎在任何表格中都被删除.如果有的话它会使你的写入速度变慢(通过一个很小的数量).

如果每个查询考虑到软删除,你可能会把它作为聚集索引中的第一个字段吗？

想象一本有数千页的大书.页面包含单个字母,"A"或"B"以及随机数.如果A和B页面没有混合,但是本书仅以A页开头,然后是B,那么您是否有机会找到某个随机数条目,您知道它位于其中一个"A"页面上？是的你会..所以我猜你错了.. (4认同)
考虑到现代数据库中的许多其他索引策略，我认为答案太简单了。例如，部分索引“WHERE field = false”，或通常特定于平台的某些其他非 btree 索引，提供了用于搜索布尔值的 btree 的替代方案。它还取决于您的搜索条件以及表的哪些部分是正确的，哪些部分是错误的。 (4认同)
你确定这是对的吗？例如，如果 99% 的情况下该值是“no”，而您只查询“yes”值，那么我可以很容易地看出这样的字段是有价值的。（EG 仅活动记录？） (2认同)
这个答案做出了一个奇怪的假设，并且在某些情况下是错误的。软删除系统可能会出现删除=1 与删除=0 的数量非常不平衡的情况。如果对数百万条记录执行查找，并且除了一千条记录之外的所有记录都已被删除，并且如果您有兴趣获取尚未删除的那一千条记录，那么 wheredeleted=0 将带来非常巨大的性能提升。对数百万条记录进行全表扫描会比仅查找 1000 条记录的快速索引慢得多。 (2认同)

Answer 2

什么是deleted_at DATETIME列？有两个好处.

您的查询可能如下所示:

SELECT * FROM xyz WHERE deleted_at IS NULL

Answer 3

我认为这会有所帮助,特别是在覆盖指数方面.

当然多少/几乎取决于您的数据和查询.

您可以获得有关索引的各种理论,但最终答案由数据库引擎在具有真实数据的数据库中给出.通常你会对答案感到惊讶(或者我的理论太糟糕了;)

检查查询的查询计划,确定是否可以改进查询,或者是否可以改进索引.改变指数并看出它有什么不同,这很简单