Java 在持久化数亿个SQL时间戳对象时，性能会受到影响

在执行依赖于

oracle.sql

包的程序时，与持久化相同数量的long相比，持久化>2亿个时间戳会对性能造成很大的影响

要持久化的Java：

Collection<ARRAY> longs = new ArrayList<ARRAY>(SIZE);
Collection<ARRAY> timeStamps = new ArrayList<ARRAY>(SIZE);
for(int i = 0; i < SIZE;i++)  
{  
    longs.add(new ARRAY(description, connection, i));  
    timeStamps.add(new ARRAY(description,connection,new Timestamp(new Long(i)));
}  

Statement timeStatement = conn.createStatement();  
statement.setObject(1,timeStamps);  
statement.execute();   //5 minutes

Statement longStatement = conn.createStatement();  
statement.setObject(1,longs);  
statement.execute();  //1 minutes 15 seconds

更新

---

java.sql.Timestamp

正在使用

数字需要4个字节，时间戳需要11个字节。此外，时间戳具有与其关联的元数据。对于每个时间戳，Oracle似乎都会计算元数据并与字段一起存储。

Oracle时间戳不会作为绝对值存储，因为像java.sql.Timestamp这样的epoc在内部保持不变。它是一个包含各种“人类”字段、世纪、月份等值的大位掩码

---

因此，从历元开始的每一纳秒时间戳都被解析为存储前的“人类”日期。

在Srini的帖子中添加了关于按数据类型使用内存的文档：

数据类型上的Oracle文档：（包括数字和时间戳的内存大小）

文档说明数字需要5-22个字节，时间戳需要11个字节，整数需要4个字节

---

另外，在查询日期范围时，是否可以将日期作为长值而不是时间戳插入，然后在查询数据时使用存储过程进行转换？这显然会影响查询的速度，因此可能会导致问题进一步恶化，但是……）

事实上，它的长度正好是4倍，这让我觉得它执行4个基本操作，而long执行1个。所以数据库在幕后做了一些额外的“帮助”？我知道了，有没有一种变通方法可以让我对日期范围执行查询。附近有工作吗？基本上，数据会被查询到日期范围。实际上，现在我读得更仔细了，这是java.sql.Timestamp还是oracle.sql.Timestamp？使用oracle.sql.Timestamp可能会有很大帮助，然后，它使用java中内存中数据的oracle表示，因此它应该更快地转换为insert语句（尽管除非您的输入可以直接转换为oracle的字节，否则您最终将在某个地方承担成本）更清楚地说，java中的代码使用java.sql.timestamp数据库就是Oracle将时间戳视为的东西。对，我决定在数据库中使用时间戳，因为我不想因为分布式系统的性质而每分钟进行N次转换。主要是因为我不相信Oracle缓存f的结果函数。但是，如果函数结果确实被缓存，我可能会重新访问它。这并不是说我非常喜欢Oracle数据库，更不用说编写函数来调用数据库了，但碰巧Oracle 11g确实提供了缓存函数结果的功能。我最终选择了物化视图，因为它是10g

64 bit RHEL 5  
jre 6u16  
ojdbc14.jar
64 GB dedicated to the JVM