更快地报告来源是Mysql

时间:2016-09-04 05:52:52

标签: mysql database-design relational-database bigdata

我们有一个Mysql Master Slave架构。我们有大约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。

1 个答案:

答案 0 :(得分:1)

这是一个糟糕的查询。它会

  1. 扫描所有A
  2. 对于每个id,在B的索引中查找(随机)uid。
    1. 扫描uid上所有B的索引
    2. 对于每个uid,在A中查找(随机)id(在PK中,因此我是数据)。
    3. 在任何一种情况下,

      • 将触及30GB的A
      • 将触及B的大部分uid索引
      • 步骤1将是线性扫描
      • 第2步将是随机探测,可能涉及批次的I / O.

      如果查询,请解释意图;也许我们可以帮助你重新制定它以实现相同或类似的目的。

      与此同时,你有多少内存? innodb_buffer_pool_size的设置是什么?表格是InnoDB吗?

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

      idAUTO_INCREMENT吗?或uid是“UUID”? (UUID使性能变差,但有一些小技巧可以提供帮助。)