#大数据（#大数据是指什么）

12张表的join优化背后到底是什么？（片尾没有彩蛋）

我优化你妹优化你妹，上来就给我吹牛逼！12张表的join有244个字段，45个查询条件，数据量达到千万级别，如果这样的数据量和查询条件发生在你身上，你会怎么做？是不是100%能想到？有很多人在问mysql如何优化，其中一个人去面试时，面试官提出了这样的问题：上游提供了12张表的数据，需要从这些表中查询，共有45个查询条件，数据量达到千万级别。

这样的问题该如何优化？12张表的join，我优化你妹优化你妹优化你妹，上来就给我吹牛逼！如果你问我如何优化这个场景，我会告诉你，这种问题我压根就不想去理。但是我发现，无论我的视频中涉及到数据库的问题还是其他方面的问题，都有很多人在问这个场景该如何优化。

我发现很多人在数据库优化方面存在误区，我们不能总是寻找巧妙的优化方法来解决一些不切实际的需求。优化需要付出一定的代价，我可以举一个不太恰当的例子，地球和某个星球之间相差几千光年，如何快速到达那里？

先说join的问题。很多人不知道MySQL的join底层是一个for循环，join几张表就代表要循环嵌套几次。举一个最简单的例子，12张表全部都是主键join，只查一条数据，树的高度是3层。MySQL需要经过一乘以3乘以12等于36次10才能把这一条数据查询出来，更别提你这里面数据可能不是唯一的，还有什么范围查询还可能涉及到回表。

你说怎么优化？这里面很明显的优化方式就是形成大宽表，利用空间换时间，没有其他好的解决方式。这244个字段你要放到一张表里面，利用大数据平台，把这12张表的数据全部都抽取出来形成数据分层，再对数据进行清洗，根据需求做到1张表里面去，然后查询这1张表减少10次，提高查询效率，这是解决方案。

如果你还有45个查询条件，你总不可能都做索引还要进行聚合查询，数据量又比较大，这种场景我劝你真的不要在MySQL上面浪费太多时间了。如果你的12个join的数据还能够回流到MySQL，可以利用索引字段查一下，否则就放弃吧。

这45个查询千万级数据的聚合，我们可以考虑使用Clickhouse，因为它是列式存储的，那列式存储和行存储有什么不同呢？举一个简单的例子，这张图片是传奇游戏的背包，这张是原神的背包。如果要统计传奇背包中黄色太阳水的数量和原神背包中小方块的数量，哪一个更快速呢？行存储需要逐一读取每个存储位置，然后再进行聚合，而列存储则是将相同的字段聚集在一起，聚合时只需取出相关字段即可。因此，采用这种数据结构的存储在聚合、大宽表和where条件较多的场景下具有优势，但也存在一些不足，比如更适合离线读多写少且对一致性要求不高的场景，更新能力也比较有限。尽管如此，它的聚合能力仍然非常强大。

我们可以参考网上的测试数据，35亿条数据的聚合需要30多秒钟，1亿条数据的聚合只需1秒钟，而在MySQL上，这是难以想象的速度。因此，我并不是想介绍clickhouse，而是想告诉大家，在进行技术优化或选择技术时，不能同时追求“既要又要”。技术会随着业务的发展不断进步。正是由于业务的推动，才出现了分布式、集群、微服务、列式存储、大数据、NoSQL等新技术。

当出现新的需求时，应该尝试使用新的技术来解决专业问题。如果仍使用老方法或中间键解决新问题，则架构可能存在问题。片尾没有彩蛋。

我看你有MySQL优化的经验，如果有一个场景，需要查询12张表并进行JOIN查询，查询字段有四五十个，数据量有千万，还需要进行一些聚合查询，那么该如何优化呢？面试官您好，我认为仅靠MySQL无法解决这个问题。

在这种情况下，我们可能需要引入一些新的中间件，例如ClickHouse。我是在询问MySQL的优化方法，您却告诉我需要引入新的中间件，这需要投入很多资金。如果您无法优化MySQL，那么我们今天的面试可以结束了，您可以回家等待通知。