鍍金池/ 問答/數(shù)據(jù)庫/ 請問：我把mysql的join改寫成兩條，但where條件遇到問題

請問：我把mysql的join改寫成兩條，但where條件遇到問題

請問：我把mysql的join改寫成兩條，但where條件遇到問題
比如：
sql = select * from order o join user u on u.user_id = o.user_id where u.type = '微信注冊'
因為user 表被遷到其他的數(shù)據(jù)庫，只能通過接口訪問。
拆分成：
sql1 = select user_id from user where type = "微信注冊";

sql2 = select * from order where user_id in (sql1取出的user_id ) limit 20 offset 0
當user表數(shù)據(jù)越來越多，sql1取出的user_id有上萬條，這樣在sql2里，user_id in （上萬條），查詢太慢了，請問有什么優(yōu)化的方式？

回答
編輯回答
久舊酒

既然存在關(guān)聯(lián)關(guān)系，你還強行把它拆到兩個庫中，醉醉的。
當然你可以說你決定不了，這是上層拍腦袋決定的。
一個方案就是定時冗余一個UserID表到你當前的數(shù)據(jù)庫中方便聯(lián)表查詢，或者運用第三方搜索軟件，整合各個數(shù)據(jù)庫的數(shù)據(jù)，加快搜索，比如solr、sphinx。

2018年8月31日 03:41
編輯回答
悶油瓶

覺得你這種業(yè)務(wù)需求很奇怪啊
這種關(guān)聯(lián)查詢要聯(lián)查就不要拆，拆了就不要這種聯(lián)查嘛
并且這種查微信注冊的訂單直接在訂單里冗余一個訂單或者用戶類型就好了啊
這種跨實例的join不關(guān)用什么方式性能都不會好哪里去，引入中間件就把計算和緩存都放到了中間件層，很危險

2017年3月20日 08:30
編輯回答
兔囡囡

解決幾種方法

  1. 引入中間件可以解決join問題
  2. 引入冗余臨時用戶表，解決join
  3. 如果只是幾萬數(shù)據(jù)子查詢是否可做業(yè)務(wù)上代碼處理。不走聯(lián)表
2017年1月13日 05:29
編輯回答
艷骨

這里的慢是有原因的
sql1 = select user_id from user where type = "微信注冊";

type = "微信注冊";這里是否可以優(yōu)化 ，中文比對。

接口返回數(shù)據(jù)。

既然 user 遷走了orer 外鍵怎么做的？ user_id 是否該有索引

2017年9月7日 15:57