最近学习了索引的神奇之处,性能有了很大的提升。但是,根据我所学到的一切,我似乎无法找到这个问题的答案。
索引很棒,但为什么不能只索引所有字段以使表变得异常快呢?我确信不这样做是有充分理由的,但是在一个有 30 个字段的表中三个字段怎么样? 10 在 30 领域?应该在哪里画线,为什么?
原文由 Vael Victus 发布,翻译遵循 CC BY-SA 4.0 许可协议
最近学习了索引的神奇之处,性能有了很大的提升。但是,根据我所学到的一切,我似乎无法找到这个问题的答案。
索引很棒,但为什么不能只索引所有字段以使表变得异常快呢?我确信不这样做是有充分理由的,但是在一个有 30 个字段的表中三个字段怎么样? 10 在 30 领域?应该在哪里画线,为什么?
原文由 Vael Victus 发布,翻译遵循 CC BY-SA 4.0 许可协议
这个答案是我个人的意见,我用我的数学逻辑来回答
第二个问题是关于边界在哪里停止,首先让我们做一些数学计算,假设我们有 N 行,表中有 L 个字段,如果我们索引所有字段,我们将得到 L 个新索引表,其中每个表都将排序索引字段的数据有意义,乍一看,如果您的表是 W 重量,如果您有 100 个大表,它将变为 W*2(1 tera 将变为 2 tera)(我已经在表编号的项目中工作过) arround 1800 table )你将浪费这个空间的 100 倍(100 tera),这远非明智之举。
如果我们将在所有表中应用索引,我们将不得不考虑索引更新是一个更新触发器所有索引更新这是一个选择所有无序等价的时间
由此我得出的结论是,在这种情况下,如果您这次松动,最好在选择或更新中丢失它,因为如果您选择一个未编入索引的字段,您将不会在所有已被索引的字段上触发另一个选择未编入索引
要索引什么?
外键: 必须基于
主键:我还不确定如果有人读到这可能对这种情况有所帮助
其他领域:第一个自然答案是其余领域的一半 为什么:如果您应该索引更多,那么您离最佳答案不远 如果您应该索引更少,那么您也不远,因为我们知道没有索引是坏的并且所有索引也不好。
从这 3 点我可以得出结论,如果我们有由 K 个键组成的 L 个字段,则限制应该接近 ((L-K)/2)+K
或多或少 L/10
这个答案是基于我的逻辑和个人价格
原文由 Mohammed Housseyn Taleb 发布,翻译遵循 CC BY-SA 4.0 许可协议
5 回答3.3k 阅读✓ 已解决
3 回答3.6k 阅读✓ 已解决
2 回答2.8k 阅读✓ 已解决
1 回答2.4k 阅读✓ 已解决
1 回答2.3k 阅读✓ 已解决
5 回答1.4k 阅读
3 回答1.2k 阅读✓ 已解决
索引占用内存(RAM)中的空间;索引太多或太大,数据库将不得不将它们交换到磁盘和从磁盘交换。它们还增加了插入和删除时间(必须为插入/删除/更新的每条数据更新每个索引)。
你没有无限的记忆。使所有索引都适合 RAM = 好。
你没有无限的时间。仅索引您需要索引的列可以最大限度地减少插入/删除/更新性能损失。