又花时间试了试FireDAC,本想找到一些办法，让FireDAC取数据能和DBX样快，最终还是失败了，DBX实现是太快了，3472第记录（110个字段的表），0毫秒就抓过来了，
FireDAC最快也要将近20毫秒。不过FireDAC已经把数据抓到TFDDatSTable中，知道记录条数了，（比DBX要强，DBX的DBXReader是不知道记录数的）
如果只是让FDCommand执行SQL后，不Feach到TFDDatSTable， 那么也是0毫秒（但读取不了数据的）。
除此之外，
FDMemTable1.AttachTable(FDDatSTable, nil);
FDMemTable1.Open;
在DBGrid中显示数据的话，FireDAC非常快， 比用 TDBXClientDataSetReader.CopyReaderToClientDataSet(DBXReader, ClientDataSet1);要快N倍了。
应该说，搭配数据控件，FireDAC非常棒。
另外，试了试在Datasnap中使用FireDAC, 虽然可以用TFDJSONDataSets返回N个数据集，但速度感觉还不是很好，有待优化。而用DBXReader速度是非常快，但返回多个结果集还是有点不方便。应该算各有优势吧。 如果习惯在Datasanp中返回实体类给客户端，还是有DBX在速度上更有优势，如果习惯返回 TDataset的，客户端使用了DB控件，用FireDAC更方便。DataSnap的核心是基于DBX框架的，个人感觉DBX框架设计的很好，相当长的时间内， Datasnap是不会有什么变动，除非EMB推出新的框架。以目前的情况看，EMB应该不会花精力和时间推出新品。但是，FireDAC又是EMB主推的数据访问层组件，与Datasnap之间的更好容合还真是要费些脑筋的。
不过，如果EMB总是让程序用处理Delta的方式来开发程序，真的不是一件很爽的。早期的ADO也能过滤“增”删“改”的记录，但.NET中没有人这么搞，还是像JAVA的框架看齐了。
何况Datasnap也能传打包类的，为什么不更进一步呢！？