mysql - 慢 SELECT ... LIMIT 联合表上没有 WHERE 子句

Question

我有一个关于联合表引擎的问题:

我创建了一个联合表，指向一个合理的大型远程表(大约 800.000 行，行大小 211 字节，MyISAM)。

发送以下查询时:

SELECT * FROM TABLE LIMIT 0,30

查询总是需要 9 秒才能完成。

尝试:

SELECT * FROM TABLE WHERE primaryKey = 1234

像往常一样快(< 0.001 秒)。

我尝试在多个数据库服务器上尝试联合表，结果始终相同。现在我的问题是:幕后是否发生了我不知道的事情？ Mysql 是否在没有 WHERE 子句的情况下获取整个索引？是否需要一些内部排序？

无论如何，在我看来，提供数据的远程数据库服务器应该立即处理这个问题，不是吗？

Mysql版本:5.5.31

Answer 1

FEDERATED 有很多问题。它本质上要求另一台机器一次发送一行。这会产生往返开销。

优化器不是很好，尤其是 FEDERATED，无法将操作“下推”到其他服务器。也就是说，它不会将可以由另一台服务器完成的工作交给其他服务器，而是请求记录，然后在启动查询的服务器上完成工作。

注意像 (< 0.001s) 这样的时间。这通常意味着查询缓存已打开，查询并没有真正执行，而是从 QC 中获取。使用 FEDERATED，QC 无法正确维护，因此要么自动禁用它，要么您应该禁用它。 (我不知道是哪个。)

SELECT * FROM TABLE LIMIT 0,30

那不获取任何索引。它从“数据”中获取行。我期望它获取 30 行(以 .MYD 中最先出现的 30 行为准)然后退出。但是 FEDERATED 可能比这更笨。

在 MyISAM 的情况下，PRIMARY KEY 与任何其他 UNIQUE 键相同。

一种更深入地了解正在发生的事情的方法:

FLUSH STATUS;
SELECT * FROM TABLE LIMIT 0,30;
SHOW SESSION STATUS LIKE 'Handler%';

我希望看到一个或两个大约 30 个处理程序。但是，从你的“9 秒”来看，它可能会说大约 800000 个。如果是“800000”，那么 FEDERATED 似乎不能高效地完成像您的 LIMIT 这样简单的事情。