我希望这个问题不是太“正确的领域”，我会坦率地说，与 stackflow 上的许多人相比，我是一个新手......
我想比较我正在从事的 AI 项目的图像、音频和文本的对象表示。我想将所有三个输入转换为单一数据类型，并使用中央比较算法来确定静态可能的匹配。
进行此类比较的“最快”本机 .Net 和 SQL 数据类型是什么？在 .Net 中，哪种数据类型需要 CLR 中的最少转换？对于 SQL，什么类型可以“CRUD-ed”最快？
我在考虑 .Net 的字节和 SQL 的整数，但整数构成了一维概念的问题。你认为图像和音频应该在文件系统而不是 SQL 中处理吗……我猜是……</p>
FWIW 我正在用我在 TrossenRobotics.com 购买的零件构建机器人
就个人而言，如果您需要在大型二进制对象之间进行频繁比较，我会散列对象并比较散列。
如果哈希不匹配，那么您可以确定对象不匹配（这应该是大多数情况）。
如果哈希值匹配，您可以开始一个更冗长的例程来比较实际对象。
如果您经常比较这些对象，则仅此方法就可以大大提高您的性能。
数据类型的速度有点难以衡量。如果您使用的是 32 位操作系统或 64 位操作系统，这会产生很大的不同。为什么？因为它决定了处理这些数据的速度。通常，在 32 位系统上，适合 32 位的所有数据类型（int16、int32、char、byte、指针）将以相同的速度处理。如果您需要处理大量数据，最好将其分成四个字节的块，以便您的 CPU 处理它们。
但是，当您将数据写入磁盘时，数据速度往往取决于更多因素。如果您的磁盘设备位于某个 USB 端口上，则所有数据都会被序列化，因此它将是一个字节接一个字节。在这种情况下，大小并不重要，尽管最小的数据块会留下最小的间隙。（在像 Pascal 这样的语言中，您会为此类数据使用打包记录以优化流性能，同时让记录中的字段以 4 字节的倍数对齐以提高 CPU 性能。）常规磁盘将数据存储在更大的块中。为了提高读/写速度，您希望数据结构尽可能紧凑。但是为了处理性能，让它们在 4 字节边界上对齐更有效。
这让我想起了我曾经和某人讨论过在 NTFS 磁盘上使用压缩。我设法证明压缩 NTFS 分区实际上可以提高计算机的性能，因为它必须读取更少的数据块，即使这意味着它必须做更多的处理来解压缩相同的数据块。
要提高性能，您只需找到最弱（最慢）的链接并从那里开始。一旦优化好了，就会有另一个薄弱环节……
就个人而言，我会说你最好使用字节数组。您可以轻松地将文件读入缓冲区...并从缓冲区读入字节数组，您可以在其中进行比较。
据我回忆，就纯粹的性能而言，Int32 类型是 .NET 中速度更快的数据类型之一。不能说它是否最适合您的应用程序。
在将任何内容拉入 .NET 之前，您应该使用 LEN 函数检查 SQL Server 中数据的长度。如果长度不同，您已经知道这两个对象是不同的。这应该可以避免将大量不必要的数据从 SQL Server 带到您的客户端应用程序。
我还建议使用 CHECKSUM 函数（http://msdn.microsoft.com/en-us/library/aa258245(SQL.80).aspx ）存储哈希码（在二进制数据的单独列中）。这仅在您使用 SQL Server 2005 及更高版本并且您将数据存储为 varbinary(MAX) 时才有效。再一次，如果哈希码不同，二进制数据肯定是不同的。
如果您使用的是 SQL Server 2000，那么您会被“图像”数据类型所困扰。
image 或 varbinary(MAX) 都可以很好地映射到客户端上的 byte[] 对象，但是如果您使用的是 SQL Server 2008，则可以选择将数据存储为 FILESTREAM 数据类型 ( http://blogs.msdn。 com/manisblog/archive/2007/10/21/filestream-data-type-sql-server-2008.aspx）。