1. cross join
又叫笛卡爾積，匹配前乙個表與後乙個表的每一行和每一列，這樣得到的結果集為n*m行（n, m分別為每張表的行數），x+y列（x, y分別為每張表的列數）。可見，該結果集可能會成為乙個巨大的表，對記憶體和後續處理都會造成巨大壓力，所以，慎用（真沒用過）。
語法：select ... from t1 cross join t2 ...
（盜用using sqlite3 2010中的圖）
2. inner join
類似cross join，但內建機制限制了返回的結果數量。返回的結果集不會超過x + y列，行數在0- n*m行之間。有3種方法用來指定inner join的判斷條件：
第一種是on表示式：select ... from t1 join t2 on conditional_expression ...，例如：select ... from employee join resource on employee.eid = resource.eid ...。
但on這種方式有倆個問題：一是語句比較長，二是存在重複列，如倆個eid。因此，可以使用第二種方式using表示式：select ... from t1 join t2 using ( col1 ,... ) ...，這種join返回的結果集中沒有重複的字段，只是每個字段必須存在於各個表中。
更簡潔的方式是，使用第三種方式natural join：sql自動檢測各表中每一列是否匹配，這樣，即使表結構發生變化，也不用修改sql語句，可以自動適應變化。
（繼續盜圖）
3. outer join
解決我的問題使用的是outer join。
sqlite3只支援left outer join，其結果集由不大於x + y列，n - n*m行構成，至少包含左側表的每一行，對於join後不存在的字段值，則賦null。這樣得到的表與我們之前設計那個全集結果一樣，但資料結構更清晰，空間占用更少。
（最後一次盜圖）
Hive中join的三種方式
hive在實際的應用過程中，大部份分情況都會涉及到不同的 的連線，例如在進行兩個table的join的時候，利用mr的思想會消耗大量的記憶體，良妃磁碟的io，大幅度的影響效能，因為shuffle真的好令人擔心啊，總之，就是各種問題都是由他產生的。下面介紹一下涉及hive在join的時候的優化方式 第...
SQLite3中TimeStamp的使用問題
color blue 在使用sqlite3時使用了timestamp，但是遇到一些問題，現總結如下 一 我的sql語句 create table logs id integer primary key,idcardno varchar 50 createdtime timestamp not nul...
Django中SQLite3的使用
from django.db import models class blogarticle models.model title models.charfield max length 50 author models.charfield max length 20 time models.int...