boss说平时查询数据量大的数据尽量避免用join 宁可一次将一张表的数据查出来再用这些数据去做查询 也不要用过多的使用join 尽量分成多次查询来做 ，请大神来讲讲这其中的sql优化
join方式其实挺好，主要是索引把握起来不是那么的得心应手，容易出现问题。
所以你们boss直接说join不要用于大数据。
而分别查的原因：比如我拿到对应这边的主键id，再到另外表去查，效率肯定是高得不要不要的。
一句话：越简单的查询效率越高
真不明白数据量大的情况下join了会导致性能低下，如果数据量大了单独查询某个表就几百兆上G，加载到程序就花费好长时间
如果用了关系型数据库，用表的join是很自然的做法，除非一些特例：
sql语句太复杂，或统计信息不准确，造成数据库生成的执行计划不正确，导致运行效率低下，且短时间没办法改写sql
数据量特别大（至少过亿），数据库负载成为整个系统的性能瓶颈，在架构设计的时候就规定了不用数据库本身的表连接功能。
使用了ORM框架，对于关联对象默认会使用N+1查询的方式，如果数据量不是特别大，加上有缓存功能，效率并不低。
所以一般情况下，用数据库的join功能，比自己多次取数据做关联效率要高，否则一张大数据量表，但是传递到PHP中，就要花费很长的时间。
sql优化最基本的原则，就是让数据库尽早、高效率的过滤数据，避免无效的运算，具体的手段比较多，需要根据不同的数据库来确定实现方案。
索引会加快查询速度
利用缓存（memchache等）
请自行explain之。
这要看你数据库链接是不是长链接了，如果配置为长链接的话还好一点，不过要join的时候可以首先通过where或者其他方法缩减你的主表，不要一股脑的拉起来，这样的话性能会好很多。但是还是具体问题具体分析吧，跑一遍就有结果了哇。不过如果不是长链接的话估计连表会快一点。
分成多次查询的原因是因为：无论是join还是子查询，mysql优化器都会对sql进行优化（子查询就会自作聪明办坏事，join偶尔也会）
所以一条一条写，自己可以把握