通过减少索引大小来提高MySQL性能？

我有一张约1.2米行的桌子。它有6个索引列，包括一个包含url的varchar（255）字段。通过减少索引大小来提高MySQL性能？

我需要能够扫描表以查看表中是否存在网址，因此索引，但我想知道是否通过将索引大小减少到50左右来看到性能增益？

当然这意味着它可能必须在数据库中搜索url时扫描更多的行......但我只需要每30秒进行一次这样的查询，所以我想知道是否较小的索引大小将是值得的。思考？

2011-03-17 makeee

我将首先使用mysql“explain”来确定您的查询对每个索引的实际使用情况，然后开始检查更改。如果它在搜索中使用varchar（255）索引，那么很难找到速度更快的东西（索引应该提供近乎直接的访问），这就是为什么在更改索引字段之前调查。 – Brandon 2011-03-17 00:50:30

所有答案都被拒绝或零？ – AbiusX 2011-03-17 14:47:31

两个原因降低也许更好 - （假设你的指数是非常有用的）

1）指标过于内存获取加载，所以有可能是您的索引规模的增长在一定程度上罕见的可能性，这是不完全可在内存中缓存。那就是当你看到性能受到影响时（所有新的硬件规格......几乎不可能有120万行，但仍值得注意）。

2）很多时候，只有第一个'n'字符足以能够快速识别每条记录。你可能根本不需要索引整个255个字符。

两个原因，你可能不关心 -

1）如前所述，你可能再也看不到你的指标日益成为你的关键缓冲的，那么，为什么担心。

2）您需要确定第一个'n'个字符，甚至在此之后，性能将小于或等于一个完整的索引......不会更多。你真的需要花时间吗？是否值得可能失去准确性？

来源

2011-03-17 03:31:39 Jai

-1

索引大小只对磁盘空间很重要，所以你不会遇到严重的问题。

有或没有索引可以基于您的CRUD操作，您有更多的选择或更多插入/更新/删除？

来源

2011-03-17 00:45:20 AbiusX

我怀疑你会看到任何改变索引只会使用前50个字符的差异。

由于这是一个VARCHAR列，索引值只会与每个URL一样长，所以查看典型的URL，您可能只能为每个URL约50个字符编制索引。

即使URL的长度都大得多，减小索引大小可能只会增加索引的那部分已经在内存中的机会，但是我再次怀疑您会注意到任何差异。如果音量很高，并且您需要启动微优化以获得更多性能，这可能只会有用。

来源

2011-03-17 01:03:45

从我SQL indexing tutorial (covers MySQL as well)：

提示：始终致力于指数的原始数据。这通常是您可以放入索引的最有用的信息。

这是我建议的一般规则，直到有一个非常强的理由去做不同的事情。

在大多数情况下，空间不是问题。

表现明智，索引树深度以索引叶节点的数量对数增长。这意味着，将索引尺寸减半可能不会减少树深度。因此，性能增益可能仅限于提高缓存命中率。但是你提到你每30秒执行一次该查询。在适度加载的机器上，这意味着您的索引不会被缓存（除了可能每隔30秒搜索一次相同的URL）。

毕竟：我没有看到任何理由对上述一般建议采取行动。

如果您确实想要保存索引空间，请尝试首先查找冗余索引（例如，那些以相同列开头的索引）。这些通常是低悬的成果。

来源

2011-03-17 08:14:31

引用的提示很好。然而，您的性能分析仅查看索引查找，而忽略索引扫描 - 索引查找确实遵循日志（大小） - 具有相当大的日志基础，但索引扫描的性能直接跟随大小。所以，这取决于系统的主要作用。例如它是检索单个记录或例如排序的范围。此外，检索排序的范围可能是较慢的操作，因此速度的感知会更加感受到它。 – Unreason 2011-03-17 11:13:26

@非理由 - 是的。不幸的是，我们两个都在做猜测，因为实际的查询没有显示出来。就我所了解的问题而言，每30秒只有一个查询使用该索引。如果该查询检索许多记录，则离开节点遍历和表访问会导致[slow index exerience]（http://use-the-index-luke.com/sql/anatomy/slow-indexes），以便不使用该声明的索引也可能成为一种选择。然而，所有的猜测都是。 – 2011-03-17 13:07:32

保留你的url的固定长度为32的md5散列。

来源

2011-03-17 09:06:31 Pentium10

这可能比平均URL大小更长。 – Alasdair 2013-05-27 02:51:45

通过减少索引大小来提高MySQL性能？

回答

相关问题