在數據庫日常維護工作中，我們可能經常需要把某個查詢結果插入到現有的表中。如需要把兩張表進行合并、需要把另外一張報紙能夠符合條件的的記錄插入到現有的表中、需要把另外一張表中的某些字段重新整理后插入到現有的表中等等。但是，我們都知道在數據庫中對此進行操作，不想Excel表格那么方便，通過選擇、復制、粘貼即可以完成工作表之間的合并。在數據庫中，不能夠對列直接進行復制與粘貼的操作。那么在數據庫中能否有簡單而有效的解決措施呢?其實在SQLServer數據庫中，靈活使用insert into Select(插入結果查詢)語句就可以實現這個需求。

　　如現在由于公司人事部門合并后需要把數據庫中的USER_A中的數據復制到表USE_B中。那么就可以利用如下的語句來實現:

　　

????? Insert into USER_B (ad_user_id,Value,name,manager_id) 　　Select ad_user_id,Value,name,manager_id from USER_A Where( manager_id =100001)

　　通過如上這條簡單的insert into select語句就可以把某一張表中符合條件的記錄插入到目標表中。不過這條語句雖然比較簡單，但是其中的條條框框仍然有很多。具體的來說，在使用這條語句的時候，需要遵守如下的這些條條框框。

　　一、需要指定源表中需要復制的列。

　　有時候可能復制與被復制的表表結構不同。如需要把表A中的name(英文名字)字段復制到表B中的name2(中文名字)中。此時原有復制表與被復制表中字段的名稱不同，為此需要在上面的語句中，把所需要復制列名稱一一列舉出來。另外可能只需要把被復制表中的部分列復制到目的表總，此時也有顯示的指名所需要復制的列。注意復制對象與目標對象都需要列出，以免發生張冠李戴的現象。筆者在使用這條語句的時候，不管任何情況，及時兩者表格中的內容完全一致，筆者也習慣在語句中把字段的名稱一一的列出。雖然這會增加一定的工作量，但是卻可以提高這條語句執行的準確性。簡而言之，就是需要在語句中指定源表zhon綱要復制其內容的列;指定目標表總要向其中復制數據的目標列。即使兩這個表中的這些列名稱相同，也最好能夠顯示的指定。此時數據庫管理員不能夠偷懶，否則的話很容易導致數據插入錯誤，而一切要重頭再來。

　　二、存儲數據時的順序。

　　如果現在在源表中有一萬條符合條件的記錄要保存到目的表中，那么這些記錄在數據庫中存儲的順序應該是什么呢?默認情況下，其存儲的數據順序就是查詢結果所得到的順序。在沒有采用排序語句的情況下，其實就是源表中實際存儲的順序(一般按記錄創建的先后順序來保存)。不過有時候可能這個排序順序不怎么合理。筆者在認為，最好對需要插入的結果進行恰當的排序，這有利于提高插入記錄的查詢效率。如在牧地中，可能對員工編號設置了索引;或者在目的表中查詢員工的信息是按員工編號來排序的。那么在目的表中插入數據的時候，最好能夠按員工的編號來進行排列。是順序還是逆序排列要跟目的表中保持一致。如此的話，插入數據后進行查詢的話，如需要查詢所有后來插入的結果，那么就不需要對其進行重新排序。因為存儲的時候就是按照員工編號來插入，那么查詢出來的數據也是按照員工編號來的。可見，為需要插入的數據設置合理的排序順序，這有利于提高以后查詢的性能。故筆者建議，為了提高數據庫的性能，最好在插入數據的時候利用Order BY語句指定插入數據時的順序。雖然這不是強制性的，但是筆者建議各位數據庫管理員還是要這么做。

　　三、指定復制行的條件。

　　需要把某張表中的記錄復制到另外一張表中，往往需要指定復制行的條件。也就是說，往往不會把源表中所有的記錄都復制到目的表中。如現在需要把員工信息A表中的數據復制到員工信息B表中。可是由于員工離職或者其他的原因，員工信息A表中的記錄可能有些已經作廢掉了。如果把A表中的數據不加過濾就直接把全部記錄都一成不變的復制到B表中，那顯然會給B表增加不少的垃圾數據。為此在復制數據到目的表的表的時候，企業用戶可能只需要把現在還在職的員工信息復制到B表中。此似，在使用上面的語句時，就需要利用Where條件來限制需要復制的行。如一般在數據庫系統設計的時候，都會在表中加入一個isactive類似的控制字段，表示當前記錄是否有效。當員工離職時，不會刪除這個員工的信息，而是會把其設置為不活躍。在數據庫表中反應出來的就是這個字段為N。為此，在上面的語句中，要把isactive列對應的值為N的記錄去掉。所以如果在表與表合并的時候，需要根據一定的規則來過濾數據的話，則可以在語句中加入Where語句來進行限制。這個限制雖然不是必須的，但是卻可以避免把一些垃圾數據也導入到新表中。

　　雖然數據庫管理員可以先把所有的記錄先都復制到目的表中，然后再利用delete語句進行刪除。但是筆者并不贊成這么做。一方面這么做會額外的增加工作量;其次也會對目標表中的數據產生破壞。因為在目標表中執行delete語句中，如果條件設置不當，那么很有可能把目標表中的數據也刪除了。所以說，復制記錄后再進行刪除，這個操作會帶來一定的風險。一不小心，就會破壞源表中的數據。其實，在復制的時候，在語句中加入Where限制語句就可以輕而易舉的避免這種風險。既然如此，數據庫管理員還有什么理由還需要在事后再冒這個風險呢?

四、插入結果時要注意數據的兼容性。

　　當把記錄插入到目的表中，需要注意源表中的內容必須與目標中的列兼容。這主要包含兩個方面的含義。一是數據類型要兼容，二是其字段的大小需要兼容。如源表中的name字段的長度為22;而目的表中這個字段的長度只有20。則在執行以上的語句時，就很可能因為數據長度過長而導致復制失敗。除了要注意這個字段長度的兼容之外，還需要注意的是數據庫在復制的過程中會對某些數據類型進行自動的轉換。如源表中員工編號這個字段可能是采取流水號編號，為此數據庫中的字段類型可能就是整數型。而在目的表中，對于員工編號采用部門號(字符)+流水號的形式，那么在數據庫表中其采用的就是字符類型格式。現在需要把源表中的員工編號的字段內容復制到目的表中，是可以的。雖然兩者的數據類型不同，但是把整數型的數據復制到字符型的字段中，這是允許的。也就是說，他們是兼容的。但是需要注意的是，復制過去后，原先的整數型數據在目的表中會以字符型數據來存儲，而不是整數型數據。為此如果后來因為其他原因，需要把目的表中的數據再復制到源表中時，就會發生錯誤。因為字符型數據是無法在整數型數據類型中進行存儲。所以說，在數據庫中所謂的兼容往往是單向的。這一點在進行記錄復制的時候，需要特別的當心。

　　另外有些數據類型可能是不兼容的，那么在復制數據的時候，數據庫管理員需要采用數據類型轉換函數對其進行強制轉換。如某個字段雖然存儲的都是數字，但是其數據庫中的數據類型是字符型的。此時需要把字符型的數據(全部都是數字)復制到整數型的字段中，則需要利用強制轉換函數先對數據類型進行轉換，然后再進行復制。這也是解決數據類型不一致的一個有效措施。

　　五、執行復制時的注意事項。

　　在使用這條語句的時候，需要注意其跟普通的insert語句不同。通常情況下，如果利用Insert語句插入記錄的時候，如果發現插入的記錄有問題，則可以通過撤銷執行插入操作(在沒有遞交事務之前)來撤銷插入的操作。但是使用insert into 語句進行表與表之間合并記錄的時候，則是不能夠執行撤銷操作的。為此為了數據的安全，最好在執行insert into語句之前，對數據庫來一個手工的完全備份。如此當這個操作有問題的時候，則可以通過恢復數據庫來解決由此帶來的問題。

　　另外，在執行這個語句的時候，最好先執行一下其SELECT子句，看看其查詢出來的結果是否符合用戶的需要。當這個查詢語句設計準確后，再把其跟Insert into 語句結合起來使用，這個方法可以提高表記錄合并的準確率。雖然中間多了一個查詢的步驟，但是對于數據的準確性來說，這一個步驟還是值得的。

總結

以上是生活随笔為你收集整理的将查询结果插入到现有表中的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。