完全不同意它关于性能的评价，他说的都是皮毛，关键的性能是数据库性能。
不怨它，你没有交代，insert内部是绑定变量的（这还有关安全，导致我安全失分。）。158楼的语句表明了。
就算这个insert，生成语句（含多轮的编辑）同时生成绑定树，打开游标，这点耗时的事只第一次做，后边绑定变量，执行是每条做。最后析构时才关闭游标。就这一项就比AI给的那个东西效率高多少倍。
再者，支持多线程批量操作，一般 ORACLE测试是1000条一批最快。效率有多NB？玩过ORACLE的都知道sqlldr吧？那可是性能标杆，一般人吹自己程序的性能，都会吹达到了sqlldr的几成。那似乎是不可逾越的顶峰。我的工具，在采用批量处理后，基本与sqlldr差不多，有时它高一点，有时我高一点。但是使用多线程+2节点RAC后，性能接近它的2倍，更多的节点应该可以更高。
当然sqlldr也可以设置多线程，但是它的线程数不可控，胡乱开一大堆线程不够打架的，性能更低。多节点RAC的运用，它也没啥好办法。

还有，单列模板的提取，就是那个getTemplate（），模板是按数组存储的，为了按名提取，配了个HASH索引，测试过，100多列时提取速度显著提高。

不同意评价里说的不主张使用非标准容器。我的容器产生在STL出现前很久，有几十年的使用历史了，极为可靠，绝无内存泄露，有的应用项目几年不停机也没有内存泄露。最早的是在1985年在DOS的C语言中产生，需要动态有序存储方法，那时候叫B_Tree（如果数据原生有序，它会退化成链表，也行，我就省了写个链表工具了），95年改为BB_tree（平衡二叉树，挺佩服AI它能看出来），那时候STL在哪里？没有AI呀，只能把自己积累的小玩意儿一点点堆积。

本帖讨论的是反射，反射是泛型的基础，我用泛型处理的方式解决了ORM问题，使得即使新手也能方便的写出高效率的可靠的DML。
大概是2010年吧，公司要测一下DB2的性能，让我和另一位哥们写个测试程序，我就把ORACLE的工具包改吧改吧，弄了个单条插入版，那哥们就用DB2的ESQL,我俩耗时差不多都写完了，测试结果，我的速度是他的40倍。

那年头还有个奇谈怪论，不主张开游标操作数据库，说是开销太大。直到08年，被一位ORACLE大侠教育了，才知道开游标绑定变量是提高DML性能的关键技术。开游标绑定变量真是麻烦呀，你看看158楼，把列名和values都写对，次序正确，绑定要一个个核对无误，容易吗！有时候随随便便做个小玩意儿，就如107楼的，谁还费那个力呀。



【 在 yuanmo 的大作中提到: 】
: 这个Claude Code前几天就猜测是这个原因。原文我没贴过来。
: DeepSeek的结论类似：
:
: ...................
--
修改:ylh1969 FROM 221.221.54.*
FROM 221.221.54.*