索引布尔型字段是否有任何性能提升?
我正要写一个包含WHERE isok=1
的查询。 顾名思义, isok
是一个布尔字段(实际上是根据需要设置为0或1的TINYINT(1) UNSIGNED
)。
索引这个领域有什么性能增益吗? 这个引擎(InnoDB在这种情况下)的performance会更好还是更差?
不是真的。 你应该像书一样思考。 如果一本书中只有三种词汇,并且索引了所有这些词汇,那么索引页面的数量与普通页面的数量相同。
如果一个值的logging相对较less,那么会有性能上的提升。 例如,如果您有1000个logging,其中10个为TRUE,那么使用isok = 1
search会很有用
正如迈克尔·达兰特(Michael Durrant)提到的那样,这也会使写入速度变慢
编辑:可能的重复: 索引布尔字段
这里解释说,即使你有一个索引,如果你有太多的logging,它也不会使用索引。 当检查= 1时,MySQL不使用索引,但是使用= 0
只是为了在这里提出一个更好的观点,因为根据我的经验,那些看到这样的问题的人和我们是一样的,我们都听说索引布尔字段是毫无意义的,然而…
我们有一个大约400万行的表格,每次只有大约1000个表格会有一个布尔开关标记,这就是我们search的内容。 在我们的布尔字段中添加一个索引的速度加快了几个数量级的查询速度,从大约9秒到几分之一秒。
这取决于实际查询和索引/查询组合的select性。
案例A :条件WHERE isok = 1
,没有别的:
SELECT * FROM tableX WHERE isok = 1
-
如果索引足够有select性(比方说你有1M行,只有1K有
isok = 1
),那么SQL引擎可能会使用这个索引,而且比没有它的索引更快。 -
如果索引没有足够的select性(比如你有1M行,而且
isok = 1
超过100k),那么SQL引擎可能不会使用这个索引并进行表扫描。
情况B :条件WHERE isok = 1
和更多的东西:
SELECT * FROM tableX WHERE isok = 1 AND another_column = 17
那么,这取决于你有什么其他的指标。 another_column
上的索引可能会比只有两个可能值的isok
索引更具有select性。 (another_column, isok)
或(isok, another_column)
上的索引会更好。
不,通常不是。
当他们有很高的select性/基数时,您通常会对search字段进行索引。 布尔字段的基数在大多数表中都很低。 这也会使你的写入速度变慢。
是的,一个索引将提高性能,检查EXPLAIN的输出和不索引。
从文档:
索引用于快速查找具有特定列值的行。 如果没有索引,MySQL必须从第一行开始,然后通读整个表来查找相关的行。 桌子越大,成本越高。 如果表中有相关列的索引,MySQL可以快速确定在数据文件中间寻找的位置,而无需查看所有数据。
我认为在这种情况下索引不会降低性能也是安全的,所以你只能从中获益。
其实这取决于你运行的查询。 但是,通常是的,以及索引任何其他types的字段。
这取决于数据的分布。
想象一下,我有一本有1000页精装页的书,而且我的书中唯一的字是反复重复的“是”和“否”。 如果我被要求圈出所有“是”的例子,那么书后面的索引会有帮助吗? 这取决于。
如果有半是随机分布的是和否,那么在索引中查找将无济于事。 这个指数会使书本变得更大,反正我会更快地从前面开始,在每个页面上查找所有“是”的实例并将它们圈起来,而不是查看每个项目然后将索引从索引条目引用到所引用的页面。
但是,如果在我的一千页的书里只有十个“是”的例子,而其他的只有几百万的没有,那么一个索引可以节省我大量的时间来find这十个“是”的例子,并把它们圈起来。
在数据库中是一样的。 如果是50:50的分布,那么索引是不会有帮助的 – 数据库引擎最好是从头到尾浏览数据(全表扫描),索引只会使数据库变大,编写和更新速度较慢。 但是,如果它是4000:1的分布(按照这个线程中的oucil ),那么索引search可以加速它,如果它是你正在寻找的4000个项目。