Oracle临时表在C#中需显式事务、动态命名、建索引、用BulkCopy及JOIN优化。默认连接池和自动提交会导致数据丢失或干扰，ON COMMIT选项与索引设计直接影响性能。
Oracle临时表在C#中必须显式声明事务才能生效
Oracle的GLOBAL TEMPORARY TABLE数据只对当前会话（或事务）可见，但C#的OracleConnection默认不自动绑定事务上下文。如果你用ExecuteNonQuery直接插入再查，很可能查不到刚插的数据——因为没开启事务，Oracle把插入当成了自动提交的独立操作，而临时表数据在提交后即被清空（取决于ON COMMIT DELETE ROWS定义）。
实操建议：
- 必须用
OracleTransaction显式包裹所有写入和后续查询操作 - 临时表建表语句里明确指定
ON COMMIT PRESERVE ROWS（会话级）或ON COMMIT DELETE ROWS（事务级），别依赖默认 - 连接字符串中避免
Pooling=true（连接池可能复用会话，导致临时表数据“意外残留”或“意外丢失”），测试阶段可加Pooling=false
批量写入临时表要用OracleBulkCopy，别用循环INSERT
向临时表灌入百万级数据时，逐条INSERT可能慢10倍以上。Oracle官方驱动支持OracleBulkCopy，它底层调用SQL*Loader协议，绕过SQL解析开销。
关键点：
-
OracleBulkCopy的DestinationTableName必须是已存在的临时表名（不能带schema前缀，如直接填"TMP_ORDER_DATA"，而非"SCHEMA.TMP_ORDER_DATA"） - 源
DataTable列顺序、类型必须与临时表严格一致；DateTime列建议用OracleDbType.TimeStamp映射，避免隐式转换失败 - 设置
BatchSize = 50000和WriteToServerTimeout = 600（秒），防止大批次超时中断
关联计算时优先用JOIN而非子查询+IN
临时表建好后，常用来和正式表做关联。但很多人习惯写SELECT * FROM real_table WHERE id IN (SELECT id FROM tmp_table)，这在Oracle中极易触发全表扫描，尤其当tmp_table有几十万行时。
更稳的写法：
- 改用
INNER JOIN：数据库能利用临时表上的索引（记得给临时表的关键字段建索引！） - 如果必须用
IN，确保tmp_table的被查字段上有索引，且IN子查询返回结果集不超过1000行（Oracle 12c+对IN列表长度有限制） - 避免在
WHERE里对临时表字段做函数操作，例如WHERE UPPER(tmp.name) = 'ABC'会让索引失效
C#代码里临时表名不能硬编码，得用唯一会话标识
多线程或高并发场景下，多个请求共用同一张临时表名会相互干扰（虽然Oracle按会话隔离，但调试或日志追踪时极难定位）。更糟的是，如果某次异常退出没清理，下次同名建表会报ORA-00955: name is already used by an existing object。
安全做法：
- 运行时动态生成表名，比如
"TMP_" + Guid.NewGuid().ToString("N").Substring(0, 8).ToUpper() - 用
OracleCommand执行DROP TABLE {tableName} CASCADE CONSTRAINTS前加BEGIN EXECUTE IMMEDIATE 'DROP TABLE {tableName}'; EXCEPTION WHEN OTHERS THEN NULL; END;防错 - 临时表定义（
CREATE GLOBAL TEMPORARY TABLE）放在首次使用前执行，且只执行一次（可用ConcurrentDictionary缓存是否已建）
临时表不是银弹——它的性能优势高度依赖索引设计和事务范围控制。最常被忽略的是：忘了在临时表上建索引，或者误以为“临时=不用优化”，结果关联时全表扫正式表，反而比内存Join还慢。
