如果數據不多的話還是用表變數試試。過多使用臨時表會產生大量的I/O操作，數據量很小的情況下反而效率不高，還要維護索引/策略等等信息表，這些多餘的操作表變數都不需要。
❷ sql2005中臨時表#table和表變數@table有什麼不同呀
我記得以前在哪些地方看到過。
表變數和臨時表是兩個不同的東西，但是他們是可以用於一些共同的用途的。不過要注意一下使用的場景。
臨時表
臨時表有兩種類型：本地表和全局表。本地臨時表的名稱都是以「#」為前綴，全局臨時表的名稱都是以「##」為前綴。臨時表的訪問是有可能造成物理IO的。臨時表可以有索引、數據統計這些。
表變數
表變數是變數的一種，表變數也分為本地及全局的兩種。表變數存放在內存中，但是並不是沒有限制而是有一定限制的，如果表變數數據量超過閾值，會把內存耗盡，然後使用硬碟空間，這時再訪問他就會增加了內存調入調出的機會，反而降低速度。表變數是不能有索引的。
大概就是這些，其他的記不住了。
❸ SQL Server 表變數和臨時表的區別
臨時表 vs. 表變數
1.存儲位置：臨時表是利用了硬碟(tempdb資料庫) ，表名變數是佔用內存，因此小數據量當然是內存中的表變數更快。當大數據量時，就不能用表變數了，太耗內存了。大數據量時適模喚雀合用臨時表。
2.性能：不能一概而論，表變數存儲數據有個性能臨界點，在這個臨界點鏈宏之內，表變數比臨時錶快，旦早表變數是存儲在內存中的。
3.索引：表變數不支持索引和統計數據，但可以有主鍵；臨時表則可以支持索引和統計數據。
參考：http://www.cnblogs.com/freshman0216/archive/2010/11/14/1868672.html
❹ SQL資料庫中臨時表，臨時變數和with as關鍵詞創建「臨時表」的區別
》臨時表：物理上存在的，使用時與正式表無差別；只是在會話結束時，DBy引擎會將它自動刪除；
》臨時變數：形式上是個變數，而不是表；同樣是在會話中有效；會話結束，就消失；
》WITH ... AS是公共表達式（CTE）的語法表示，它只是邏輯概念，沒有物理對象。
一個類似情況就是View（相對於Table），沒有物理對象。
但View至少還有定義存貯在DB系統表中，而CTE只是一種語法表示（僅在執行時才會被解析、翻譯）。
❺ SQL Server 表變數和臨時表的區別
表變數是一種特殊的數據類型，用於存儲結果集以進行後續處理。table 主要用於臨時存儲一組作為表值函數的結果集返回的行。其作用域為一個語句批。臨時表有兩種類型：本地表和全局表。在與首次創建或引用表時相同的 SQL Server 實例連接期間，本地臨時表只對於創建者是可見的。當用戶與 SQL Server 實例斷開連接後，將刪除本地臨時表，所以局部臨時表的作用域為當前連接。全局臨時表在創建後對任何用戶和任何連接都是可見的，當引用該表的所有用戶都與 SQL Server 實例斷開連接後，將刪除全局臨時表，所以全局臨時表的作用域為所有連接。
❻ SQL資料庫中臨時表，臨時變數和with as關鍵詞創建「臨時表」的區別
SQL資料庫中數據處理時，有時候需要建立臨時表，將查詢後的結果集放到臨時表中，然後在針對這個數據進行操作。
創建「臨時表」（邏輯上的臨時表，可能不一定是資料庫的）的方法有一下幾種：
1.with tempTableName as方法（05之後出現）：
with temptable as 其實並沒有建立臨時表，只是子查詢部分（subquery factoring），定義一個SQL片斷，該SQL片斷會被整個SQL語句所用到。有的時候，是為了讓SQL語句的可讀性更高些，也有可能是在UNION ALL的不同部分，作為提供數據的部分。特別對於UNION ALL比較有用。因為UNION ALL的每個部分可能相同，但是如果每個部分都去執行一遍的話，則成本太高，所以可以使用WITH AS短語，則只要執行一遍即可。
http://www.cnblogs.com/zhaowei303/articles/4204805.html
❼ 技術分享 | 淺談 MySQL 的臨時表和臨時文件
本文內容來源於對客戶的三個問題的思考：
以下測試都是在 MySQL 8.0.21 版本中完成，不同版本可能存在差異，可自行測試；
臨時表和臨時文件都是用於臨時存放數據集的地方；
一般情況下，需要臨時存放在臨時表或臨時文件中的數據集應該符合以下特點：
從臨時表|臨時文件產生的主觀性來看，分為2類：
用戶創建臨時表：
-- 用戶創建臨時表(只有創建臨時表的會話才能查看其創建的臨時表的內容)
注意：
可以創建和普通表同名臨時表，其他會話可以看到普通表(因為看不到其他會話創建的臨時表)；
創建臨時表的會話會優先看到臨時表；
-- 同名表的創建的語句如下
當存在同名的臨時表時，會話都是優先處理臨時表(而不是普通表)，包括：select、update、delete、drop、alter 等操作；
查看用戶創建的臨時表：
任何 session 都可以執行下面的語句；
查看用戶創建的當前 active 的臨時表(不提供 optimizer 使用的內部 InnoDB 臨時表信息)
注意
用戶創建的臨時表，表名為t1，
但是通過 INNODB_TEMP_TABLE_INFO 查看到的臨時表的 NAME 是#sql開頭的名字，例如：#sql45aa_7c69_2 ；
另外 information_schema.tables 表中是不會記錄臨時表的信息的。
用戶創建的臨時表的回收：
用戶創建的臨時表的其他信息&參數：
會話臨時表空間存儲 用戶創建的臨時表和優化器 optimizer 創建的內部臨時表(當磁碟內部臨時表的存儲引擎為 InnoDB 時)；
innodb_temp_tablespaces_dir 變數定義了創建 會話臨時表空間的位置，默認是數據目錄下的#innodb_temp 目錄；
文件類似temp_[1-20].ibt ；
查看會話臨時表空間的元數據：
用戶創建的臨時表刪除後，其佔用的空間會被釋放(temp_[1-20].ibt文件會變小)。
在 MySQL 8.0.16 之前，internal_tmp_disk_storage_engine 變數定義了用戶創建的臨時表和 optimizer 創建的內部臨時表的引擎，可選 INNODB 和 MYISAM ；
從 MySQL 8.0.16 開始，internal_tmp_disk_storage_engine參數被移除，默認使用InnoDB存儲引擎；
innodb_temp_data_file_path 定義了用戶創建的臨時表使用的回滾段的存儲文件的相對路徑、名字、大小和屬性，該文件是全局臨時表空間(ibtmp1)；
可以使用語句查詢全局臨時表空間的數據文件大小：
SQL 什麼時候產生臨時表|臨時文件呢？
需要用到臨時表或臨時文件的時候，optimizer 自然會創建使用(感覺是廢話，但是又覺得有道理=.=!)；
(想像能力強的，可以牢記上面這句話；想像能力弱的，只能死記下面的 SQL 了。我也弱，此處有個疲憊的微笑😊)
下面列舉一些 server 在處理 SQL 時，可能會創建內部臨時表的 SQL ：
SQL 包含 union | union distinct 關鍵字
SQL 中存在派生表
SQL 中包含 with 關鍵字
SQL 中的order by 和 group by 的欄位不同
SQL 為多表 update
SQL 中包含 distinct 和 order by 兩個關鍵字
我們可以通過下面兩種方式判斷 SQL 語句是否使用了臨時表空間：
# 如果 explain 的 Extra 列包含 Using temporary ，那麼說明會使用臨時空間，如果包含 Using filesort ，那麼說明會使用文件排序(臨時文件)；
如果執行 SQL 後，表的 ID 列變為了show processlist 中的 id 列的值，那麼說明 SQL 語句使用了臨時表空間
SQL創建的內部臨時表的存儲信息：
SQL 創建內部臨時表時，優先選擇在內存中，默認使用 TempTable 存儲引擎(由參數 internal_tmp_mem_storage_engine 確定)，
當 temptable 使用的內存量超過 temptable_max_ram 定義的大小時，
由 temptable_use_mmap 確定是使用內存映射文件的方式還是 InnoDB 磁碟內部臨時表的方式存儲數據
(temptable_use_mmap 參數在 MySQL 8.0.16 引入，MySQL 8.0.26 版本不推薦，後續應該會移除)；
temptable_use_mmap 的功能將由MySQL 8.0.23 版本引入的 temptable_max_mmap 代替，
當 temptable_max_mmap=0 時，說明不使用內存映射文件，等價於 temptable_use_mmap=OFF ；
當 temptable_max_mmap=N 時，N為正整數，包含了 temptable_use_mmap=ON 以及聲明了允許為內存映射文件分配的最大內存量。
該參數的定義解決了這些文件使用過多空間的風險。
內存映射文件產生的臨時文件會存放於 tmpdir 定義的目錄中，在 TempTable 存儲引擎關閉或 mysqld 進程關閉時，回收空間；
當 SQL 創建的內部臨時表，選擇 MEMORY 存儲引擎時，如果內存中的臨時表變的太大，MySQL 將自動將其轉為磁碟臨時表；
其能使用的內存上限為 min(tmp_table_size,max_heap_table_size)；
監控 TempTable 從內存和磁碟上分配的空間：
具體的欄位含義見：Section 27.12.20.10, 「Memory Summary Tables」.
監控內部臨時表的創建：
當在內存或磁碟上創建內部臨時表，伺服器會增加 Created_tmp_tables 的值；
當在磁碟上創建內部臨時表時，伺服器會增加 Created_tmp_disk_tables 的值，
如果在磁碟上創建了太多的內部臨時表，請考慮增加 tmp_table_size 和 max_heap_table_size 的值；
created_tmp_disk_tables 不計算在內存映射文件中創建的磁碟臨時表；
例外項：
臨時表/臨時文件一般較小，但是也存在需要大量空間的臨時表/臨時文件的需求：
因為這些例外項一般需要較大的空間，所以需要考慮是否要將其存放在獨立的掛載點上。
其他：
列出由失敗的 alter table 創建的隱藏臨時表，這些臨時表以#sql開頭，可以使用 drop table 刪除；
通過 lsof +L1 可以查看標識為 delete ，但還未釋放空間的文件。
如果想釋放這些 delete 狀態的文件，可以嘗試下面的方法(不推薦，後果自負)：
普通的磁碟臨時表|臨時文件(一般需要較小的空間)：
臨時表|臨時文件的一般所需的空間較小，會優先存放於內存中，若超過一定的大小，則會轉換為磁碟臨時表|臨時文件；
磁碟臨時表默認為 InnoDB 引擎，其存放在臨時表空間中，由 innodb_temp_tablespaces_dir 定義表空間的存放目錄，表空間文件類似：temp_[1-20].ibt ；MySQL 未定義 InnoDB 臨時表空間的最大使用上限；
當臨時表|臨時文件使用完畢後，會自動回收臨時表空間文件的大小；
innodb_temp_data_file_path 定義了用戶創建的臨時表使用的回滾段的存儲文件的相對路徑、名字、大小和屬性，該文件是全局臨時表空間(ibtmp1)，該文件可以設置文件最大使用大小；
例外項(一般需要較大的空間)：
load data local 語句，客戶端讀取文件並將其內容發送到伺服器，伺服器將其存儲在 tmpdir 參數指定的路徑中；
在 replica 中，回放 load data 語句時，需要將從 relay log 中解析出來的數據存儲在 slave_load_tmpdir(replica_load_tmpdir) 指定的目錄中，該參數默認和 tmpdir 參數指定的路徑相同；
需要 rebuild table 的在線 alter table 需要使用 innodb_tmpdir 存放排序磁碟排序文件，如果 innodb_tmpdir 未指定，則使用 tmpdir 的值；
若用戶判斷產生的臨時表|臨時文件一定會轉換為磁碟臨時表|臨時文件，那麼可以設置 set session big_tables=1;讓產生的臨時表|臨時文件直接存放在磁碟上；
對於需要較小空間的臨時表|臨時文件，MySQL 要麼將其存儲於內存，要麼放在統一的磁碟臨時表空間中，用完即釋放；
對於需要較大空間的臨時表|臨時文件，可以通過設置參數，將其存儲於單獨的目錄|掛載點；例如：load local data 語句或需要重建表的在線 alter table 語句，都有對應的參數設置其存放臨時表|臨時文件的路徑；
當前只有 innodb_temp_data_file_path 參數可以限制 用戶創建的臨時表使用的回滾段的存儲文件的大小，無其他參數可以限制臨時表|臨時文件可使用的磁碟空間；