問(wèn)題背景：

• 有a、b、c三個(gè)表，a跟b、c都是一對(duì)多的關(guān)系，a有自增主鍵a.id，這是排序分頁(yè)的依據(jù)，但按BOSS要求，不許在b、c表中添加a.id的冗余字段（包括外鍵手段，外鍵是使用的a中另一個(gè)保證唯一的定長(zhǎng)字符串a(chǎn).guid）；
• b、c表中均有字段用于作篩選條件，且由于a跟b、c都是一對(duì)多的關(guān)系，無(wú)法在a表中添加b、c表的篩選用字段作冗余；
• 說(shuō)是由于預(yù)計(jì)數(shù)據(jù)量會(huì)非常大（百萬(wàn)級(jí)），不允許使用join連接，且由于考慮以后遷移其他數(shù)據(jù)庫(kù)的可能性，不允許使用自增主鍵id做外鍵，包括不允許使用自增主鍵id作為其他表的冗余字段。

需求：

• 獲取a表數(shù)據(jù)列表，分頁(yè)顯示，排序依據(jù)是a.id；
• 有必選的篩選條件，在a表中，在此舉例為a.set；
• 有可選的篩選條件，條件分別在b、c表中，在此舉例為b.type，c.name。

探索（此問(wèn)題未解決，求助各位大佬幫忙）：

• 此問(wèn)題的等價(jià)join連接SQL語(yǔ)句如下所示：

  SELECT a.id,a.guid,a.col1,a.col2 
  FROM a 
      INNER JOIN b ON a.guid = b.a_guid
      INNER JOIN c ON a.guid = c.a_guid
  WHERE a.set = 'xxx'          -- 必選條件
      AND b.type = 1           -- 整數(shù)，可選篩選條件
      AND c.name LIKE '%XXX%'  -- 模糊查詢，可選篩選條件
  GROUP BY a.guid              -- 去重
  ORDER BY a.id                -- 按a.id排序
  LIMIT 0,10                   -- 分頁(yè)
  ;

• 不允許使用join連接，故思路自然是添加冗余字段，問(wèn)題背景也說(shuō)明了a表無(wú)法添加b、c表的冗余字段，故在b、c表中都添加了a_set（即a.set）的冗余字段；

• 若不考慮分頁(yè)，僅根據(jù)單獨(dú)的可選篩選條件自然可以先篩選出a.guid，如根據(jù)b.type篩選：

  SELECT b.a_guid FROM b WHERE b.a_set = 'xxx' AND b.type = 1 GROUP BY b.a_guid;

• 但這樣問(wèn)題自然在于b表中沒(méi)有a.id字段可供排序，無(wú)法進(jìn)行分頁(yè)，分頁(yè)思路自然是上面的語(yǔ)句查詢出b.a_guid的結(jié)果集后，在a表中使用IN進(jìn)行查詢，然后按a.id進(jìn)行排序分頁(yè)，但此思路又有個(gè)問(wèn)題是本身a、b、c三表的數(shù)據(jù)量預(yù)計(jì)就會(huì)很大，篩選出的b.a_guid的結(jié)果集可能也會(huì)非常大，可能會(huì)導(dǎo)致SQL語(yǔ)句超出長(zhǎng)度限制，即便增加了SQL語(yǔ)句的長(zhǎng)度限制或者使用子查詢的方法，但I(xiàn)N中的數(shù)據(jù)量太多的話，不也是會(huì)很影響查詢效率嗎，會(huì)不會(huì)效率還不如使用JOIN連接？
• 就此，思路卡在此處，實(shí)在想不出好的解決方案，在此求助路過(guò)的大神幫忙，提供一下解決的思路