c＃DataSet.Fill Firebird 2.5填补了可怕的性能问题

备注我完全重写了问题，因为在探索选项和获得见解时，我意识到我的问题的根源完全不是我想的。

我使用Firebird作为数据库引擎和标准.Net提供程序（v.5.11.0）使用以下代码获取数据：

// myBlob1 is BLOB SUB_TYPE 1 (text field) with some empty, but some // VERY long stuff (xml-content) which exceeds VARCHAR(32765), but I removed // those before performing my tests!!! var tick = Stopwatch.StartNew(); DataTable dataTable = new DataTable(); DbLive.Open(); FbCommand command = new FbCommand("SELECT myBlob FROM MY_TABLE", DbLive); try { dataTable.BeginLoadData(); FbDataAdapter fda = new FbDataAdapter(command); fda.Fill(dataTable); dataTable.EndLoadData(); } command.Dispose(); DbLive.Close(); tick.Stop(); Console.WriteLine("Execution time: " + tick.ElapsedMilliseconds + " [ms]"); 

我提取大约30k行，总共大约16Mb的数据（根据数据库工作台的统计数据），但只有20k行具有非空数据。

所以我使用朴素方法获取整个事物，然后我使用了cast (VARCHAR(8192))方法（请注意，我在执行测试之前删除了> 8192个字符的所有行）。 现在，结果如下：

 // Obtained when loading data over wifi, with a bandwidth of about 100Mbps) // the performance on local machine did not make a big difference!) No casting: 73287.0788 ms With casting: 2360.2244 ms 

Blobs在这里确实发生了一些不好的事情。 我使用Firebird 3和压缩测试了性能，但结果并没有好多少（一个非常小的改进，但差异仍然是相同的数量级）。

要点：1。如果我使用其他提供商（例如建议的www.ibprovider.com ，但我无法对其进行测试），我可以期待改进www.ibprovider.com 。这是其他数据库引擎上的已知问题，还是存在希望通过换到另一个引擎来获得改进？

Answer 1

我对上面的许多事情感到有些困惑，所以让我澄清一些见解：

1. 事实上， FbDataReader和Dapper方法没有加载blob字段，因此性能确实无关紧要;

2. 使用CAST到VARCHAR(4096)确实显示了显着的性能改进（请注意，在这里，我测试了text-blob的内容以完全匹配，这确实有效）：

   DataTable no cast：73287.0788 ms

   FbDataReader cast：2224.1387 ms

   DataTable强制转换：2360.2244毫秒

我甚至尝试使用压缩Firebird 3，没有显着的改进。 所以我确实使用BLOB而不是大型VARCHAR导致了这个问题。

请注意，我没有成功使用其他提供商进行测试。

底线：使用BLOB SUBTYPE 1杀死我的表现，我应该使用VARCHAR 。