mysql范围查询性能

Question

我有一个包含 40000 行的简单 MySQL 表：

id CHAR(36) (i am using UUIDs as primary keys)
number_from (INT)
number_to (INT)

有 3 个索引：

primary(id)
number_from(number_from)
number_to(number_to)

看起来像下面这样的简单查询需要相当大 时间量（例如 30 秒或更长时间）：

SELECT * FROM numbers WHERE (number_from >= 703911711 AND number_to <= 703911800)

我可以做些什么来优化性能？

Answer 1

分离索引将强制 MySQL 单独扫描它们。如果您同时索引number_from 和number_to一起，MySQL 可以在单个索引上执行整个where 子句：

CREATE INDEX number_from_number_to_ind
ON numbers (number_from, number_to)

将id 添加到索引实际上将允许MySQL 在不访问表的情况下执行整个查询，但代价是使索引显着变大。您必须进行基准测试，看看这是否真的提高了查询的性能：

CREATE INDEX all_columns_ind
ON numbers (number_from, number_to, id)

Answer 2

你有两个不容易解决的问题。

• UUID 非常“随机”，
• 优化器不理解从到范围不重叠

但首先，让我们确保您的缓存设置正确。 如果您正在使用 MyISAM，key_buffer_size 应该是大约 20% 的可用 RAM。 或者对于 InnoDB，innodb_buffer_pool_size 应该是大约 70% 的可用 RAM。如果您的设置很小，则此更改只会将问题从 I/O 转移到 CPU。当您无法在 RAM 中缓存大部分表及其索引时，它不会扩展过去。 Reference

My blog 解释了为什么 UUID 对于大型索引来说很糟糕。这还提供了一个存储函数来使 UUID 更小（BINARY(16)），因此更易于缓存；这将有助于 I/O。

如果您有“type-1” UUID（例如由 MySQL 生成），该博客还解释了为什么在 Function 的帮助下可以扩展 UUID 的使用。但是，如果它是其他类型的 UUID，并且您必须至少有一个带有 UUID 的 BTree（INDEX 或 PRIMARY KEY），那么您的任务是不可扩展的。你能把它变成AUTO_INCREMENT吗？这将允许INSERTs 聚集在表格的“末端”，而不是随机散布在表格周围，从而耗尽缓存？

至于范围，您需要修改表格以在每行中仅放置 from/to 之一。这涉及“无主”范围的额外行。然后编写一个存储例程来使用LIMIT 1 来防止您所看到的——即未能有效使用任何索引。 Another blog 详细介绍了 IPv4（可能是您正在做的）和 IPv6 的架构设计和参考代码。我的代码非常可扩展，并且消除了您提出的索引问题。

Answer 3

当范围的边界存储在不同的属性中时，常规索引不起作用。正如许多人发现和记录的那样，解决方案是使用地理空间索引。 This 是谷歌的第一个热门。

由于 mysql 地理空间索引在二维中工作，因此诀窍是将范围映射到一维并在另一维中使用固定比例。