create table tbl_a(id integer,id2 integer);
create table tbl_b(id integer,id2 integer);
truncate tbl_a;
truncate tbl_b;
insert into tbl_a values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6);
insert into tbl_b values (1,1),(2,2),(3,3),(4,4),(7,7),(8,8);
select * from tbl_a inner join tbl_b using (id) where tbl_b.id2 = 3;
-- 3,3,3
select * from tbl_a inner join (select * from tbl_b where id2 = 3) t2 using (id);
-- 3,3,3
select * from tbl_a left join tbl_b using (id) where tbl_b.id2 = 3;
-- 3,3,3
select * from tbl_a left join (select * from tbl_b where id2 = 3) t2 using (id);
-- 1,1,null
-- 2,2,null
-- 3,3,3
-- 4,4,null
-- 5,5,null
-- 6,6,null
select * from tbl_a right join tbl_b using (id) where tbl_b.id2 = 3;
-- 3,3,3
select * from tbl_a right join (select * from tbl_b where id2 = 3) t2 using (id);
-- 3,3,3
因為正常用inner join 比較多,容易產生錯覺,認為條件放裡面和放外面是一樣的。
from t1
cross joint2
inner joint3
oncondition
和from t1
,t2
inner joint3
oncondition
並不完全相同,因為第一種情況中的condition
可以引用t1
,但在第二種情況中卻不行。
我的第乙個subscriber踩坑記錄
為了得到autoware歐式聚類演算法處理後的雷射雷達點雲聚類資料,我打算在autoware建ros功能包,直接利用autoware的資料格式將資料讀出來。下面是我的踩坑記錄1.開啟錄製的實驗資料 2.啟動autoware以及歐式聚類演算法 3.rostopic list檢視話題列表 4.rosto...
乙個程式設計師一天之內踩過的坑
作為乙個踩坑天王,我必須對此做乙個反思,不然我覺得自己這輩子就完了 1 發現硬體的問題,自己把問題復現三遍,如果每次都能復現,馬上換硬體,貼上標籤這硬體有問題,以後再也不用 2 在最初對乙個硬體進行除錯的時候,一定要反覆確認,拿著原理圖乙個個對比,奇怪了,當時我也是拿著原理圖乙個個對比,怎麼還是會出...
最近踩的乙個小坑
最近需要實現乙個業務,大致的內容是為了提高效率,把資料庫中的資訊定時同步到記憶體中,然後使用記憶體查詢,提高效率。然後在實現過程中遇到了乙個問題,需要同步的資訊約9萬條,但是這9w條資料對應了133w個,大概乙個id十幾張吧。儲存這些的時候,遇到了小問題。專案原本使用的結構是 list vin1,1...