我喜欢钱!它比DECIMAL少一个字节，而且计算执行得更快，因为(实际上)加法和减法操作本质上是整数操作。@SQLMenace的例子——这对不了解情况的人是一个很大的警告——同样可以应用于整数，其结果将为零。但这并不是不使用整数的理由——在适当的地方。

所以，当你处理的是金钱，并根据它遵循的数学规则(与整数相同)使用金钱时，使用金钱是完全“安全”和适当的。

如果SQL Server将MONEY的除法和乘法转换为小数(或浮点数?)会更好吗?可能，但他们没有选择这样做;在除法时，他们也没有选择将整数提升为浮点数。

金钱没有精确度问题;小数在计算过程中使用更大的中间类型只是使用该类型的一个“特征”(我实际上不确定这个“特征”延伸了多远)。

要回答具体的问题，一个“令人信服的理由”?好吧，如果你想在SUM(x)中获得绝对最大性能，其中x可以是DECIMAL或MONEY，那么MONEY将具有优势。

另外，不要忘记它的小表兄弟smallmoney——只有4个字节，但它的最大值为214,748.3647——这对于钱来说非常小——因此通常不适合。

为了证明使用更大的中间类型的观点，如果你显式地将中间类型赋值给一个变量，DECIMAL也会遇到同样的问题:

declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)

select @a = 100, @b = 339, @c = 10000

set @d = @a/@b

set @d = @d*@c

select @d

产生2950.0000(好吧，至少是DECIMAL四舍五入，而不是MONEY截断——与整数相同。)

永远不要使用金钱。它不精确，纯粹是垃圾;总是使用十进制/数字。

运行这个来看看我的意思:

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

输出:2949.0000 2949.8525

有些人说钱不能一分一分

这是我计算相关性的一个问题，把它换成金钱会得到错误的结果。

select t1.index_id,t2.index_id,(avg(t1.monret*t2.monret)
    -(avg(t1.monret) * avg(t2.monret)))
            /((sqrt(avg(square(t1.monret)) - square(avg(t1.monret))))
            *(sqrt(avg(square(t2.monret)) - square(avg(t2.monret))))),
current_timestamp,@MaxDate
            from Table1 t1  join Table1 t2  on t1.Date = traDate
            group by t1.index_id,t2.index_id

我喜欢钱!它比DECIMAL少一个字节，而且计算执行得更快，因为(实际上)加法和减法操作本质上是整数操作。@SQLMenace的例子——这对不了解情况的人是一个很大的警告——同样可以应用于整数，其结果将为零。但这并不是不使用整数的理由——在适当的地方。

所以，当你处理的是金钱，并根据它遵循的数学规则(与整数相同)使用金钱时，使用金钱是完全“安全”和适当的。

如果SQL Server将MONEY的除法和乘法转换为小数(或浮点数?)会更好吗?可能，但他们没有选择这样做;在除法时，他们也没有选择将整数提升为浮点数。

金钱没有精确度问题;小数在计算过程中使用更大的中间类型只是使用该类型的一个“特征”(我实际上不确定这个“特征”延伸了多远)。

要回答具体的问题，一个“令人信服的理由”?好吧，如果你想在SUM(x)中获得绝对最大性能，其中x可以是DECIMAL或MONEY，那么MONEY将具有优势。

另外，不要忘记它的小表兄弟smallmoney——只有4个字节，但它的最大值为214,748.3647——这对于钱来说非常小——因此通常不适合。

为了证明使用更大的中间类型的观点，如果你显式地将中间类型赋值给一个变量，DECIMAL也会遇到同样的问题:

declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)

select @a = 100, @b = 339, @c = 10000

set @d = @a/@b

set @d = @d*@c

select @d

产生2950.0000(好吧，至少是DECIMAL四舍五入，而不是MONEY截断——与整数相同。)

作为对其他答案主旨的反驳。看金钱的诸多好处…数据类型!在SQLCAT的关系引擎指南中

我要具体指出以下几点

Working on customer implementations, we found some interesting performance numbers concerning the money data type. For example, when Analysis Services was set to the currency data type (from double) to match the SQL Server money data type, there was a 13% improvement in processing speed (rows/sec). To get faster performance within SQL Server Integration Services (SSIS) to load 1.18 TB in under thirty minutes, as noted in SSIS 2008 - world record ETL performance, it was observed that changing the four decimal(9,2) columns with a size of 5 bytes in the TPC-H LINEITEM table to money (8 bytes) improved bulk inserting speed by 20% ... The reason for the performance improvement is because of SQL Server’s Tabular Data Stream (TDS) protocol, which has the key design principle to transfer data in compact binary form and as close as possible to the internal storage format of SQL Server. Empirically, this was observed during the SSIS 2008 - world record ETL performance test using Kernrate; the protocol dropped significantly when the data type was switched to money from decimal. This makes the transfer of data as efficient as possible. A complex data type needs additional parsing and CPU cycles to handle than a fixed-width type.

所以这个问题的答案是“视情况而定”。对于某些算术操作，您需要更加小心，以保持精度，但您可能会发现，出于性能考虑，这样做是值得的。

之前所有的帖子都提出了有效的观点，但有些并没有准确地回答这个问题。

问题是:当我们已经知道钱是一种不那么精确的数据类型，并且在复杂的计算中使用它会导致错误时，为什么有人更喜欢钱?

当你不需要进行复杂的计算，并且可以用这种精度来换取其他需求时，你就会使用金钱。

例如，当您不需要进行这些计算，而需要从有效的货币文本字符串中导入数据时。此自动转换仅适用于MONEY数据类型:

SELECT CONVERT(MONEY, '$1,000.68')

我知道你可以制作自己的导入程序。但有时您不希望使用全球特定的区域设置格式重新创建导入例程。

另一个例子，当你不需要进行这些计算(你只需要存储一个值)，需要节省1个字节(金钱需要8个字节，而十进制(19,4)需要9个字节)。在一些应用中(快速CPU，大内存，慢IO)，比如只是读取大量的数据，这也可以更快。

我刚看到这个博客:SQL Server中的金钱vs.十进制。

这基本上是说金钱有一个精确的问题……

declare @m money
declare @d decimal(9,2)

set @m = 19.34
set @d = 19.34

select (@m/1000)*1000
select (@d/1000)*1000

对于货币类型，你将得到19.30而不是19.34。我不确定是否存在将钱分成1000份进行计算的应用场景，但这个示例确实暴露了一些局限性。