在分区表上不使用分区键进行查询时的性能影响

Question

假设我按月对一个大尺寸的表（比如6TB）进行分区。我们正在提供约 300 RPS 的高流量。

示例架构

Create table mydata(
    id int not null,
    date_created not null,
    uuid_val not null,
    Primary key (id,date_created),
    key uuid_idx uuid_val
    ) Partition by range(to_days(date_created) ...

如果我在where子句中没有date_created的情况下查询该表，会对性能产生什么影响。 它肯定不会提供更好的性能，因为它无法进行分区修剪，但如果我基于索引 uuid_val 查询它，与具有相同架构的非分区表相比，会产生什么影响？

我尝试使用 6GB 数据对其进行基准测试，并通过索引而不是分区键进行查询（500,000 次），与在非分区表上运行相同的查询相比，在多个分区中搜索的开销似乎非常少（0.1 毫秒）。但为什么开销这么少呢？ 另外，在提供高流量时，我是否也可以预期 6TB 数据会带来这样的数字？ 我可以在没有分区键的情况下查询分区表吗，因为流程中可能没有分区键。

我的MySQL版本是8。引擎= InnoDB

Answer 1

如果我根据索引 uuid_val 查询它与具有相同架构的非分区表相比会产生什么影响？

在 MySQL 中，所有索引都是分区本地的。

由于如果您不提供分区键值作为查询的一部分，则不可能进行分区修剪，因此引擎将必须查询表的所有分区。

如果您有（例如）三个分区，则工作量是三倍。

在每个分区内，查询计划将完全相同（即在

uuid_val

上进行索引查找。

我可以在没有分区键的情况下查询分区表吗，因为流程中可能没有分区键。

是的，可以，但有上述限制。