更快的报告来源是 Mysql

Posted 2023-04-18

【中文标题】更快的报告来源是 Mysql

【英文标题】：Faster reporting where source is Mysql

【发布时间】：2016-09-04 05:52:52

【问题描述】：

我们有一个 mysql 主从架构。我们有大约 1000 张桌子。我们的数据库中有 5 或 6 个表，每个表大约 30 到 40 GB。我们不能将一个 30 GB 表连接到另一个 30 GB 表，因为它永远不会返回结果。

我们的工作：从一个表中选择所需的数据，然后在另一个表中分块查找匹配的数据。这给了我们结果，但这很慢。

在将两个表连接成块后，我们会进一步处理这些表。我们根据用例使用了更多的连接。

当前数据库：架构：5 个主服务器，100 个从服务器。

1.我们怎样才能让它更快？索引在这里不是问题，我们已经在使用它。

2。我们是否需要一些大数据方法来获得更快的结果。

编辑：下面的查询详细信息

Query select count(*) from A, B where A.id = B.uid;

表 A 30 GB，有 51 列。 id是主键，是自增整数。

表 B 27 GB，有 48 列。 uid (int 11) 是非唯一索引。

使用了 MySql ISAM。

【问题讨论】：

请注意：使用索引和正确使用它们是两件不同的事情。但如果没有任何关于结构、查询、计划等的实际信息，就无法回答。

好的，我正在编辑我的问题

具体请提供SHOW CREATE TABLE和EXPLAIN SELECT ...。

我会这样做的。但是今天我在家。我无权访问数据库。明天会做。考虑查询是否正确。索引也正确使用。

能否提供EXPLAIN SELECT ...。

【参考方案1】：

这是一个糟糕的查询。它要么

扫描所有A 对于每个 id，在 B 的索引中查找（随机）uid。

或

在uid上扫描B的所有索引 对于每个 uid，查找（随机）A 中的 id（在 PK 中，因此 i 是数据）。

无论哪种情况，

A 的 30GB 都会被触动 B 的大部分 uid 索引将被触及 第 1 步将是线性扫描 第 2 步将是随机探测，可能涉及 lots 的 I/O。

如果查询，请说明意图；也许我们可以帮助您重新制定它以达到相同或相似的目的。

同时，您有多少 RAM？ innodb_buffer_pool_size的设置是什么？表是 InnoDB 吗？

查询最终会返回一个结果，除非某些“超时”杀死它。

id 是 AUTO_INCREMENT 吗？还是uid 是“UUID”？ （UUID 会降低性能，但有一些小技巧可以提供帮助。）