mysql 为什么不推荐三张表以上的关联？

[Aresxue]

今天看到了一个说法说 mysql 不推荐三张表以上的关联，我觉得多表关联虽然可读性较差和耦合性较高，但是可以节省 IO 次数，减少执行时间从而提升接口的性能。

[realpg]

MYSQL 不推荐技术渣的人三张表以上关联

[reus]

MySQL 5 对于 join 只有 nested loop 一种计划，没有 hash join，没有 merge join，所以你再怎么优化，残疾就是残疾，于是各位就得出了“少 join ”的结论。

你用 Oracle，PostgreSQL，SQL Server 这些数据库，就完全没有这些问题。

[bzj]

没有用过 3 张表以上关联的估计都没做过什么复杂的系统，比如一个简单的订单数据列表，起码要关联 5 张表

[bzj]

@sun1991 能说出手写 foreach 的，应该是 phper

[huijiewei]

说关联五张表的都是做并发 1 的系统的吧

[Aresxue]

@msg7086 访问数据库的次数

[xuanbg]

@nekoneko 你没任何条件的话，单表读 1 亿照样完犊子。如果有条件的话，1 亿里面取 100 条数据，关联、条件都有索引，3 个表 join 写对 sql 也是几十毫秒的事情。

[Aresxue]

@wysnylc 如果是很看重接口响应速度的业务，单表和关联的效率能查 10 倍以上，当然是在数据量远没有达到机器性能瓶颈的时候

[Aresxue]

@Cbdy 也不单单是性能，还是如何去权衡的问题，大概的度是多少，就好比 mysql 单表 500 万性能就会有问题，这个说法虽然不对但也有一定的借鉴意义

[Aresxue]

@shakoon 传统行业里比较重 DB 轻业务，以前用 Oracle 的时候见过几千行的 sql。。。

[Aresxue]

@sampeng 笛卡尔积不是这么算的，在连接查询里，如果 on 条件是非唯一字段，会出现笛卡尔积(局部笛卡尔积)；如果 on 条件是表的唯一字段，则不会出现笛卡尔积。

[Aresxue]

@sampeng 扯到现在你这个算是唯一一个比较有建设性的说法了，数据库 CPU 这块有什么好的资料吗？会卡死是真的，见过卡死的，顺便问下一般 4G 双核的机器能支持 mysql 多大的计算量而不影响总体性能？

[Aresxue]

@huijiewei 传统行业里这种关联很多，除非是互联网而且是对高并发要求很高的，不然 5 张表完全是小 case，如果把定时任务也能算的吧，那这个可就多了。。。

[mikulch]

1. mysql 就是为高并发设计的，单表高并发随便查都不会有太大的性能问题。
2. mysql 不怕单表高并发查询，不代表不怕关联查询。mysql 的设计比较怕联表查询，特别是复杂的业务联表查询+查询里面的计算。
3. 在 sql 里面实现复杂的业务和联表，是比较偏向于传统 it 的做法。

[huijiewei]

@Aresxue 关联多只是 db 的习惯而已，不想拥抱变化的继续关联呗，反正我写存储过程写的已经吐过了

[sampeng]

@Aresxue 没有…纯看官方手册加搜索。如果所有 on the 条件都是唯一键那就好了咯。但通常 n 表 join 是不可能出现这种情况的。

就你这小水管配置？别指望优化了…先加机器吧…量大 4 核 32g 没毛病。量小也要 2 核 16g 也行吧。我是选择内存大，cpu 小的配置。几乎全在缓存里。没有 io 操作

[sampeng]

@Aresxue 2c4M 没有高并发…这配置就是做实验用用还行。量大点就要跪…

[qiyuey]

我一般不推荐关联

[Aresxue]

@huijiewei 互联网的趋势是重业务轻 DB，但是关联这种东西我觉得现阶段还是很有必要的。还有扯存储过程干嘛，Mysql 的存储过程本来就是个半成品，用的人又不多。

[Aresxue]

@sampeng 只是举个例子，比较小块的机器容易量化一点，我这边项目生产用的都是 16 核 256G 的。。。但是这种机器你知道有多贵吗。。。