我总不能系统所有的SQL都是单表吧？
- 如果业务场景真的简单也不是不可以。
- 不过绝大部分都不会这么说，都会说自己系统特别复杂。可能说系统简单有点不好意思和人打招呼。
- 其实我倒是希望我们的业务场景简单一点。但是事与愿违，那业务逻辑是从业以来闻所未闻，以至于到现在我都说不清楚。
有的系统就是SQL都是单表
- 为什么？因为是某国产数据库。应用真的是完全适配了。在我看来属于跪着适配的。其实从我内心还真是希望有这种，因为DBA的话语权就可以高一点。业务想一个需求（不行，你别想，打回去）
那我们说说多表的冲击
- 看这两句是不是一样？
- select * from a,b where a.id=b.id and a.id=1;
- select * from a,b where a.id=b.id and a.id=1 and b.id=1;
- 答案是完全一样。
- 那么问题就是先从a.id=1 开始还是先从b.id=1开始。（单表情况下没有这个问题）于是这有两种可能。就看数据库怎么选了。
- 如果是具体业务表，开发人员能说先找主项，再找明细等。但是计算机哪里知道？
- 再看下面两句
- select * from a,b,c where a.id=b.id and a.id=c.id and c.id=1;
- select * from a,b,c where a.id=b.id and a.id=c.id and c.id=1 and b.id=1 and a.id=1;
- 答案是完全一样。
- 那么问题就是先从a.id=1 开始还是先从b.id=1开始或者是先从c.id=1开始。于是有6种可能。
- 那么4表关联呢？
- 答案是N！ N表的阶乘。
- 你想想一下10表关联。而传统行业8表是起步价，10表？30个表又何妨？
多表关联首先冲击的就是优化器
- 而从事数据库的人都知道，优化器是数据库最难之一。底层全是数学算法。
- 数学这个东西不会就是不会，逼急了什么事情都做的出来，但是数学除外。我考不上清华不是因为考试时间不够，不会的就是不会。就这么简单的道理。
- 数据库要从N！中依次选择最优的执行下来。如果选择错了，那么本来应该快的就慢了。
- 就这一点就是现在所谓兼容性中最大的问题，没有之一。大家都在说的兼容性是语法兼容性，有没有哪家说到优化器兼容100%。如果有且可以论证，那么大家去用吧。不被卡脖子了。
多表关联其次冲击的是分布式
- 我以前也听过不少分布式数据库说3表以上基本无响应了。我当时想这优化器也太弱了。
- 后来想想也不完全是优化器的事情。如果传统行业那种多表大量查询，不同节点大量数据交互这本身就慢。
- 再后来我意识到了还有其他的因素。
- 有些分布式数据库（也许有的不是，也许有的改进了，但是确实有）A表和B表同时进行重分布，假设有5个实例，每个示例上的进程有会因为查询而有1个会话进程。就会产生 5个会话。如果3表关联那么就是10个会话。你试想一下N表关联的场景。而且实例数越多会话也会越多。实例是M，关联是N的话。那么会话就是M*N。
- 这对于非互联网场景的应用开发来说是不能想象的。我们上来就是10-30个表。稍微点几下，会话数没有了。
- 那么也难怪无响应了。所以可能无响应某种程度也来自于这里。
- 我也知道这里在改进。但是架不住传统行业的业务就是复杂，不是说做到应用侧就可以了。而是很多就不是应用侧能做的了的。必须重度放在数据库中。不信的话你试试，这不是应用适配。而是行业模式适配（当然我其实乐见于这种可以整顿一下行业规划的事情，如果说能从我们数据库出发整顿行业业务流程，也是值得骄傲的事情）
都说深水区了
- 因为要应用适配，金融头部是真的有预算投入，几个亿都是小钱。但是腰间部的不一定。而没有这些预算的企业就难了。
- 我今天想说的，除了应用适配可能还要是行业适配。
