Oracle时间戳精度丢失源于ODP.NET/JDBC驱动默认将TIMESTAMP映射为DateTime导致毫秒截断；应使用GetOracleTimeStamp()、显式指定OracleDbType.TimeStamp及统一TIMESTAMP(3)设计，并检查NLS_TIMESTAMP_FORMAT参数。
Oracle时间戳精度丢失在C#中不是数据库问题，而是JDBC/ODP.NET驱动和.NET类型映射共同导致的——默认把TIMESTAMP字段当成DateTime读取，毫秒被截断或归零。
为什么TO_TIMESTAMP写入后读出来没了毫秒？
根本原因在于.NET驱动对Oracle TIMESTAMP类型的默认映射行为：ODP.NET（尤其是旧版）会把带毫秒的TIMESTAMP列自动转成DateTime，而DateTime.Kind为Unspecified时，部分驱动版本会丢弃毫秒位；更隐蔽的是，JDBC驱动在oracle.jdbc.V8Compatible=true关闭时，也可能把微秒部分四舍五入到毫秒甚至清零。
- 确认是否真丢了：用SQL*Plus或SQL Developer查原始值，比如
SELECT TO_CHAR(ts_col, 'YYYY-MM-DD HH24:MI:SS.FF6') FROM t，如果显示.123000但C#里是.000，就是驱动层截断 - 检查驱动版本：Oracle.ManagedDataAccess.Core 3.21.10+已修复多数毫秒映射问题，低于3.21.0的版本建议升级
- 避免用
DataReader.GetDateTime()直接取值——它强制转DateTime且不保留FF精度；改用GetFieldValue<datetime>(i)</datetime>或GetValue()再手动转换
怎么让C#读到完整的毫秒甚至微秒？
关键不是改SQL，而是控制驱动如何解析和返回值。ODP.NET支持原生OracleTimeStamp类型，能完整保留精度，但需要显式启用。
- 连接字符串加
StmtCacheSize=0;FetchSize=1000;（避免语句缓存干扰精度） - 查询时用
OracleCommand而非通用DbCommand，并开启BindByName = true - 读取时优先用
GetOracleTimeStamp()方法：var ts = reader.GetOracleTimeStamp(0);<br>string fullStr = ts.ToString("yyyy-MM-dd HH:mm:ss.FFFFFFF"); - 若必须转
DateTime，用ts.Value（OracleTimeStamp的Value属性是DateTime，但保留毫秒），不要用(DateTime)ts强制转换
跨库兼容时怎么统一处理毫秒时间？
当项目同时连Oracle、PostgreSQL、SQL Server时，各数据库对毫秒的支持粒度不同（Oracle默认FF6，PGSQL默认FF6，SQL Server 2016+才支持FF7），硬靠驱动自动映射必然出错。
- 表设计阶段就约定：所有含毫秒的时间字段统一用
TIMESTAMP(3)（显式声明毫秒精度），避免依赖默认行为 - C#实体类中，时间字段统一用
DateTimeOffset或DateTime，但插入前一律用new DateTime(..., DateTimeKind.Utc)构造，避免Kind=Unspecified引发歧义 - 参数化插入时，不用
cmd.Parameters.Add("@t", dt)，改用cmd.Parameters.Add("@t", OracleDbType.TimeStamp).Value = dt，显式指定类型和精度 - 对金仓等国产库，按其文档要求传字符串（如
"2023-01-01 12:34:56.123"），因为其Oracle兼容模式对二进制时间解析不稳定
最易被忽略的一点：即使驱动和代码都正确，如果Oracle数据库的NLS_TIMESTAMP_FORMAT会话参数被设成不含FF的格式（比如'YYYY-MM-DD HH24:MI:SS'），某些工具类或ORM（如Dapper）在生成SQL时可能隐式触发格式化，导致毫秒从源头就被丢弃。上线前务必检查SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER = 'NLS_TIMESTAMP_FORMAT'。
