❶ sql查詢一個表裡的數據在另一個表是否存在
--創建測試表
CREATE TABLE AA_TMP(ID VARCHAR2(10)); --插入目標表
CREATE TABLE AA_LOOKUP(ID VARCHAR2(10));--要插入的數據
INSERT INTO AA_LOOKUP VALUES('1');
INSERT INTO AA_LOOKUP VALUES('2');
INSERT INTO AA_LOOKUP VALUES('3');
COMMIT;
--插入數據不存在時更新
INSERT INTO AA_TMP(ID)
SELECT ID FROM AA_LOOKUP A
WHERE NOT EXISTS
(SELECT 1 FROM AA_TMP B
WHERE A.ID=B.ID
)
;
COMMIT;
❷ 連接池已經配置成功但是編譯時提示lookup<javax.sql.DataSource>錯誤怎麼解決
java:comp/env
這個只是根目錄.
正確的配置是tomcat下面的\conf\context.xml
<Resource name="jdbc/aaa" />
配置這樣的話就把java:comp/env改成java:comp/env/jdbc/aaa
項目下web.xml中配置
<resource-ref>
<res-ref-name>jdbc/aaa<res-ref-name>
</resource-ref>
❸ sql server執行計劃 怎麼看消耗資源
掃描：逐行遍歷數據。
先建立一張表，並給大家看看大概是什麼樣子的。
CREATE TABLE Person(
Id int IDENTITY(1,1) NOT NULL,
Name nvarchar(50) NULL,
Age int NULL,
Height int NULL,
Area nvarchar(50) NULL,
MarryHistory nvarchar(10) NULL,
EcationalBackground nvarchar(10) NULL,
Address nvarchar(50) NULL,
InSiteId int NULL
) ON [PRIMARY]
表中的數據14萬左右，大概類似下面這樣：
此表，暫時沒有任何索引。
一、數據訪問操作
1、表掃描
表掃描:發生於堆表，並且沒有可用的索引可用時，會發生表掃描,表示整個表掃描一次。
現在，我們來對此表執行一條簡單的查詢語句：
SELECT * From Person WHERE Name = '公子'
查看執行計劃如下：
表掃描，顧名思義就是整張表掃描，找到你所需要的數據了。
2、聚集索引掃描
聚集索引掃描：發生於聚集表，也相當於全表掃描操作，但在針對聚集列的條件如(WHERE Id > 10)等操作時，效率會較好。
下面我們在Id列來對此表加上一個聚集索引
CREATE CLUSTERED INDEX IX_Id ON Person(Id)
再次執行同樣的查詢語句：
SELECT * From Person WHERE Name = '公子'
執行計劃如下：
為什麼建的聚集索引在Id列，會對掃描有影響呢？更何況與Name條件也沒關系啊？
其實，你加了聚集索引之後，表就由堆表變成了聚集表。我們知道聚集表的數據存在於聚集索引的葉級節點。因此，聚集掃描與表掃描其實差別不大，要說差別大，也得看where條件里是什麼，以後返回的數據。就本條SQL語句而言，效率差別並不大。
可以看看I/O統計信息：
表掃描：
聚集索引掃描：
此處超出本文范疇了，效率不在本文考慮范圍內，本文只考慮的是，各種掃描的區別，以及為何會產生。
3、聚集索引查找
聚集索引查找：掃描聚集索引中特定范圍的行。
看執行以下SQL語句：
SELECT * FROM Person WHERE Id = '73164'
執行計劃如下:
4、索引掃描
索引掃描：整體掃描非聚集索引。
下面我們來添加一個聚集索引，並執行一條查詢語句：
CREATE NONCLUSTERED INDEX IX_Name ON Person(Name) --創建非聚集索引
SELECT Name FROM Person
查看執行計劃如下：
為什麼此處會選擇索引掃描(非聚集索引)呢？
因為此非聚集索引能夠覆蓋所需要的數據。如果非聚集索引不能覆蓋呢?例如，我們將SELECT改為SELECT *再來看看。
好明顯，返回結果所包括的記錄太多，用非聚集索引反而不合算。因此使用了聚集索引。
如果此時我們刪除聚集索引，再執行SELECT *看看。
DROP INDEX Person.IX_Id
而此時沒有聚集索引，所以只有使用表掃描。
5、書簽查找
前面關於索引的學習我們已經知道，當在非聚集索引中並非覆蓋和包含所需全部的列時，SQL Server會選擇，直接進行聚集索引掃描獲得數據，還是先去非聚集索引找到聚集索引鍵，然後利用聚集索引找到數據。
下面來看一個書簽查找的示例：
SELECT * FROM Person WHERE Name = '胖胖'--Name列有非聚集索引
執行計劃如下：
上面的過程可以理解為：首先通過非聚集索引找到所求的行，但這個索引並不包含所有的列，因此還要額外去基本表中找到這些列，因此要進行鍵查找，如果基本表是以堆進行組織的，那麼這個鍵查找(Key Lookup)就會變成RID查找(RID Lookup),鍵查找和RID查找統稱為書簽查找。不過有時當非聚集索引返回的行數過多時，SQL Server可能會選擇直接進行聚集索引掃描了。
二、流聚合操作
1、流聚合
流聚合：在相應排序的流中，計算多組行的匯總值。
所有的聚合函數(如COUNT(),MAX())都會有流聚合的出現，但是其不會消耗IO，只有消耗CPU。
例如執行以下語句：
SELECT MAX(Age) FROM Person
查看執行計劃如下：
2、計算標量
計算標量：根據行中的現有值計算新值。比如COUNT()函數，多一行，行數就加1咯。
除MIN和MAX函數之外的聚合函數都要求流聚合操作後面跟一個計算標量。
SELECT COUNT(*) FROM Person
查看執行計劃如下：
3、散列聚合(哈希匹配)
對於加了Group by的子句，因為需要數據按照group by 後面的列有序，就需要Sort來保證排序。注意,Sort操作是佔用內存的操作，當內存不足時還會去佔用tempdb。SQL Server總是會在Sort操作和散列匹配中選擇成本最低的。
SELECT Height,COUNT(Id) FROM Person --查出各身高的認輸
GROUP BY Height
執行計劃如下：
對於數據量比較大時，SQL Server選擇的是哈希匹配。
在內存中建立好散列表後，會按照group by後面的值作為鍵，然後依次處理集合中的每條數據，當鍵在散列表中不存在時，向散列表添加條目，當鍵已經在散列表中存在時，按照規則（規則是聚合函數，比如Sum,avg什麼的）計算散列表中的值（Value）。
4、排序
當數據量比價少時，例如執行以下語句，新建一個只有數十條記錄的與Person一樣的表。
SELECT * INTO Person2 FROM Person2
WHERE Id < 100
再來執行同樣的查詢語句：
SELECT Height,COUNT(Id) FROM Person2 --只是表換成了數據量比較少的表
GROUP BY Height
執行計劃如下：
三、連接
當多表連接時(包括書簽查找，索引之間的連接)，SQL Server會採用三類不同的連接方式：循環嵌套連接，合並連接，散列連接。這幾種連接格式有適合自己的場景，不存在哪個更好的說法。
新建兩張表如下
這是一個簡單的新聞，欄目結構。
1、嵌套循環
先來看一個簡單的Inner Join查詢語句
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
執行計劃如下：
循環嵌套連接的圖標同樣十分形象，處在上面的外部輸入(Outer input)，這里也就是聚集索引掃描。和處在下面的內部輸入(Inner Input),這里也就是聚集索引查找。外部輸入僅僅執行一次，根據外部輸入滿足Join條件的每一行，對內部輸入進行查找。這里由於是7行，對於內部輸入執行7次。
根據嵌套循環的原理不難看出，由於外部輸入是掃描，內部輸入是查找，當兩個Join的表外部輸入結果集比較小，而內部輸入所查找的表非常大時，查詢優化器更傾向於選擇循環嵌套方式。
2、合並連接
不同於循環嵌套的是，合並連接是從每個表僅僅執行一次訪問。從這個原理來看，合並連接要比循環嵌套要快了不少。
從合並連接的原理不難想像，首先合並連接需要雙方有序.並且要求Join的條件為等於號。因為兩個輸入條件已經有序，所以從每一個輸入集合中取一行進行比較，相等的返回，不相等的舍棄，從這里也不難看出Merge join為什麼只允許Join後面是等於號。從圖11的圖標中我們可以看出這個原理。
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
OPTION(MERGE join)
執行計劃如下：
如果輸入數據的雙方無序，則查詢分析器不會選擇合並連接，我們也可以通過索引提示強制使用合並連接，為了達到這一目的，執行計劃必須加上一個排序步驟來實現有序。這也是上述SQL語句為什麼要加OPTION(MERGE join)的原因。上述對Article表的ColumnId列進行了排序。
3、哈希連接
散列連接同樣僅僅只需要只訪問1次雙方的數據。散列連接通過在內存中建立散列表實現。這比較消耗內存，如果內存不足還會佔用tempdb。但並不像合並連接那樣需要雙方有序。
要進行下面這兩個實現，得把兩個列的聚集索引不要建在ColumnId列，否則不會採用哈希連接。
ALTER TABLE PK_Nx_Column DROP CONSTRAINT PK_Nx_Column --刪除主鍵
DROP INDEX Nx_Column.PK_Nx_Column --刪除聚集索引
CREATE CLUSTERED INDEX IX_ColumnName ON Nx_Column(ColumnName) --創建聚集索引
--這里再設置回主鍵就可以了，有了聚集索引，就不能隨主鍵默認建啦
還要刪除另外一個表Article的聚集索引哦。
然後執行以下查詢：
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
執行計劃如下：
要刪除掉聚集索引，否則兩個有序輸入SQL Server會選擇代價更低的合並連接。SQL Server利用兩個上面的輸入生成哈希表，下面的輸入來探測，可以在屬性窗口看到這些信息，如圖15所示。
❹ 怎麼使用look up控制項將源表中的
LOOKUP 控制項的主要目的是：
從關系型的表、視圖或者同義詞中根據lookup 條件查詢lookup port，返回查詢結果，供mapping 中的其他控制項使用或者插入到目標表
LOOKUP 控制項能夠完成的任務包括：
得到一個關聯的值，例如根據USER_ID 得到USER_NAME
執行一個計算，例如得到計算公式中的一個乘數
更新緩慢變化的維表，可以用LOOKUP 來判斷當前記錄是否在目標表中已經存在
LOOKUP 控制項的類型：
Connected：直接從其他控制項獲得輸入信息；可以使用靜態或者動態的Cache；只緩沖mapping 中用到的port；每條記錄可以返回多個column，並且能夠插入到動態Cache 中；查詢條件無匹配時，返回所有輸出port 的默認值，如果使用動態Cache，Informatica Server把記錄毫無改變的保留在Cache 中；支持用戶定義的默認值；返回多個輸出值到另一個控制項中
Unconnected：間接的從其他控制項的:LKP 表達式的結果來獲得輸入信息；只能使用靜態Cache；緩沖所有的port；每條記錄只能返回一列；查詢條件無匹配時，返回NULL；不支持用戶定義的默認值；將返回值輸出到定義:LKP 表達式的控制項中
Connected LOOKUP 控制項的處理過程
1.直接從mapping 中的另一個控制項獲得輸出數據
2.對於每一條數據，Informatica Server 根據LOOKUP 控制項中的條件去查詢LOOKUP表或者是Cache
3.如果LOOKUP 控制項是Uncached 或者使用的是靜態的Cache，Informatica Server返回查詢的結果；如果使用的是動態的Cache，Informatica Server 在Cache 中查詢從LOOKUP表中查詢得到的結果，如果在Cache 中不存在，則將結果插入到Cache 中，如果在Cache中存在，則更新這些記錄或者不做改變，同時標記這些記錄是「插入」、「更新」、「無變化」等類型
4.然後將結果返回到下一個控制項
可以將上面的經過經過filter 或者router 控制項來得到對於目標表中不存在的記錄
Unconnected LOOKUP 控制項的處理過程
1.相關控制項想間接的從其他LOOKUP 控制項的:LKP 表達式的結果來獲得輸入信息，例如UPDATE STRATEGY 控制項
2.對於每一條數據，Informatica Server 根據LOOKUP 控制項中的條件去查詢LOOKUP表或者是Cache
3.Informatica Server 返回一個值到LOOKUP 控制項的return port
4.Informatica Server 返回值到調用:LKP 的控制項的表達式中
Unconnected LOOKUP 控制項的主要用處是更新緩慢變化的維
LOOKUP 控制項的組件
LOOKUP 表
需要有源或者是目標中的一個可以訪問這個LOOKUP 表；可以是一個單獨的表，也可以使用SQL 語句覆蓋來得到一個包括多個表的查詢通過連接到數據來引入LOOKUP 表的定義，可以通過資料庫的本地驅動或者是ODBC 來進行連接，但是使用資料庫本身的本地驅動性能更好一些對於非常大的LOOKUP 表，考慮添加索引來提高查詢的性能，索引需要包括LOOKUP 條件中的所有的欄位對於Cache LOOKUP，將LOOKUP 的ORDER BY 子句中的包含在索引中即
可；對於Uncached LOOKUP，要把LOOKUP 條件裡面的自動都加入到索引中
LOOKUP 埠
I：輸入埠
O：輸出埠
L：查詢埠，在默認的SQL 中出現，LOOKUP 表中的每列都被自動的定義
為L 和O 埠，可刪除
R：無連接LOOKUP 中的返回埠
LOOKUP 屬性
Lookup SQL Override 只能在cache enable 的情況下才能用，另外不要輸入ORDER BY 子句，即使輸入INFORMATICA 也會產生ORDER BY 子句
Lookup Caching Enabled：如果選中，查詢一次表，以後的記錄都從緩沖中去查詢；如果不選，每條記錄都從資料庫中查詢一次
Lookup Policy on Multiple Match：確定在uncached 和static cache 的情況下如何處理查詢得到的多條記錄，可以取得第一條、最後一條或者是報錯；在dynamic cached 的情況下，如果查詢得到多條記錄，會報錯
Dynamic Lookup Cache：當把經過的記錄插入到目標表的同時，插入或者更新cache裡面的記錄
Insert Else Update：如果選中整個選項並且進入LOOKUP 控制項的記錄類型是INSERT，那麼對於不存在的記錄進行插入，對於存在的記錄進行更新；如果不選中這個選項，只是對那些是INSERT 類型的記錄在cache 進行尋找，找不到則插入，否則不做其他操作
Update Else Insert：如果選中整個選項並且進入LOOKUP 控制項的記錄類型是UPDATE，那麼對於存在的記錄進行更新，對於不存在的記錄進行插入；如果不選中這個選項，只是對那些是UPDATE 類型的記錄在cache 進行尋找，找到則更新，否則不做其他操作。
LOOKUP 查詢
默認產生ORDER BY 子句，並且順序與SELECT 中的欄位的順序是一致的SYBASE 中的ORDER BY 子句最多可以有16 個欄位，因此如果LOOKUP 中有超過16 個欄位的查詢，必須使用多個LOOKUP 控制項進行查詢當在OVERRIDE SQL 中要寫WHERE 子句時，如果是dynamic，必須在LOOKUP控制項前面添加一個FILTER 控制項，來確保只有滿足條件的記錄被插入到cache 和目標表中如果沒有cache，sql override 無效；在override 中SELECT 的欄位必須與L 埠和O 埠一致
LOOKUP 條件
類似於WHERE 子句；條件中的數據類型必須一致；多個條件之間的關系是「與(AND)」；NULL 值是可以匹配的；
如果有多個條件，把帶等號的條件放在前面，可以提高性能；對於有多個匹配的情況，可以選擇返回的類型：第一個匹配、最後一個匹配、返回錯誤；INFORMATICA 的ORDER BY 是升序排列的dynamica cache 的情況下，因為不能返回多個記錄，所以只能使用等號的條件
LOOKUP tips
給LOOKUP 條件中的欄位添加索引把帶有等號的條件放置在前面把較小的LOOKUP 表進行cache在資料庫中進行表的關聯：如果LOOKUP 表和源表在同一個數據裡面，而且cache是不可能的，就在資料庫裡面進行表關聯對於靜態的LOOKUP 表，盡量使用永久性的cache：這樣可以在多個session 見復用如果想在EXPRESSION 中使用:LKP 來調用查詢的結果，引入一個unconnected 的LOOKUP
對於cache 的LOOKUP，重定義ORDER BY 子句：1）generate SQL；2）按照LOOKUP
條件中的欄位的順序添加ORDER BY 語句；3）在ORDER BY 語句後面添加--，作為重定
義的記號，否則出錯
❺ sql server裡面 include什麼意思
如果返回的數據列就包含於索引的鍵值中，或者包含於索引的鍵值+聚集索引的鍵值中，那麼就不會發生Bookup Lookup，因為找到索引項，就已經找到所需的數據了，沒有必要再到數據行去找了。這種情況，叫做索引覆蓋；
❻ 哪位高手能告訴我:用主/細表、TABLE的LOOKUP欄位、QUERY的查找欄位
用BDE沒問題用ADO（ADOQUERY）的Lookup編輯有問題，可以該為計舉動當作段解決！
❼ sql如何實現vlookup功能
這太簡單啦
比如A表有姓名，B表也有姓名
select * from A where 姓名 in(select 姓名 from B)