不建议使用join的原因

不推荐使用join的原因： 1.DB承担的业务压力大，能减少负担就减少。当表处于百万级别后，join导致性能下降； 2.分布式的分库分表。这种时候是不建议跨库join的。目前mysql的分布式中间件，跨库join表现不良。 3.修改表的schema，单表查询的修改比较容易，join写的sql语句要修改，不容易发现，成本比较大，当系统比较大时，不好维护。 不使用join的解决方法： 在业务层，单表查询出数据后，作为条件给下一个单表查询。也就是子查询。 会担心子查询出来的结果集太多。mysql对in的数量没有限制，但是 mysql限制整条sql语句的大小。通过调整参数max_allowed_packet ，可以修改一条sql的最大值。建议在业务上做好处理，限制一次查询出来的结果集是能接受的。应用层次关联的优势：1 将查询分解后，执行单个查询可以减少锁的竞争 2 在应用层关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展 3 查询本身效率也可能会有所提升。查询id集的时候，使用IN（）代替关联查询，可以让MySQL按照ID顺序进行查询，这可能比随机的关联要更高效。 4 可以减少冗余几率的查询。在应用层做关联查询，意味着对应某条记录应用只需要查询一次，而在数据库中做关联查询，则可能需要重复访问一部分数据。 5. 更进一步，这样做相当于在应用中实现了哈希关联，而不是使用MySQL的嵌套循环关联。某些场景哈希关联的效率要高很多。

这个问题的难点在于如何找出B表中每个关联字段组中的第一条记录，对于MYSQL我们可以利用自增ID（auto_increment)的特性予以解决。

因为MySql不支持rownumber()这类开窗函数（ACCESS可以利用FIRST函数），如果B表里没有自增ID的话，建议先创建一个与B表结构相同的表，同时添补一个自增ID字段，然后将B表中的记录全部追加到这个新表里，跟着我们就可以利用这个自增ID字段来解决问题了。

下面是利用自增ID特性的解决方案

假设A,B表的关联字段名为（R_ID ），  B表里有一个自增ID字段（id）

select A.*,t2.* from A, 

(select * from B,  

(select min(id) as F_id from B group by R_ID)t 

where B.id=t.F_id))t2 

where A.R_ID=t2.R_ID

如果不想输出所有的字段，A.*,t2.*换成相应的具体字段即可

上面的代码也可以使用inner Join连接，但是经验告诉我其运行效率不如上面的写法高（不指定连接类型的等同连接）

MYSQL不利用自增ID的方法暂时未能找到。

---