ODBC连oracle，比起Pro*C和OCI能慢多少？另求对设计的改进。

基本已经确定生产环境至多是PC服务器，不会超过几十万吧，IO性能是相当有限的，加上数据表少，就两张，已经用顺序结构全预读了（直接用用户ID索引，不会比这个更快了，ID上限是百万级的，至多消耗几百MB内存），同步回写机制方面也已经考虑周全，数据读取这块应该不是瓶颈了。

还采用了“预计算”机制，通过设计交互协议，让本地的计算基本能够不依赖请求的数据，服务器空闲的时候就用“预计算”生成了多条候补数据，请求过来直接回复。

通过这样的设计让服务器的处理请求能力最大化了，目前测试只要“预计算表”还有数据候补，速度瓶颈就是千兆网卡（用WSAEventSelect模式的UDP，这一块暂时不想用更高级的，性能提高不了太多的），可以说处理性能已经优化到极限了。

问题主要是同步回写这块，数据库回写速度有限， “预计算表”定的很大的话，我有意制造持续的峰值请求会造成数据回写队列严重积压，内存占用升高。odbc驱动的性能相对来说比oracle原厂提供的连接方式是要慢的，数据库方面我不太熟悉，没用过oracle原厂的，odbc相对能慢多少呢？

如果说不是慢一个数量级或许多倍，而仅仅是慢几成，就算了，现在效率是够的，而且我开发机器还懒得装笨重的oracle呢，现在一直利用着odbc的通用性，装轻量级的MySQL在开发……只是觉得我为了oracle的回写慢去刻意限制精心设计的数据预读和处理流程的速度防止爆内存，有点不爽，比如我会限制较小的预计算条数，预计算候补用完了，处理速度自然降下来（因为有硬件加密卡，即便用多块也是明显瓶颈），也给了oracle喘气的时间。

如果确实快一个很多，我考虑换oracle原厂连接，网上的测试数据很多不靠谱，就和编程语言的效率评测一样。

或者大家针对这个问题还有什么其他点子。

强调一下，数据表是极其简单的，可能和某些本科生的课程设计复杂度都差不多，数据索引和SQL语句优化基本没有什么空间，ODBC层级的优化已经做了。NoSQL之类的我推荐过，但需求方坚持oracle，说是“放心”。因为这是一个专用通信系统的鉴权服务器，电信级的，数据安全很重要的，需求方可能会购买全套的oracle数据安全技术和服务（数据热备等）。

15 个解决方案