額sQL

① sql 統計數量及金額

SELECT UID as 用戶 ,COUNT(ORDER_SN)as 訂單總數,SUM(TOTAL)as 合計總金額 FROM 訂單表 group by uid

② 【SQL】金額如果存在資料庫中應該使用何種類型

在工作中發現原本系統中金額類型（int 10，存入資料庫時乘100）已經不能滿足當前需求，需要重新修改類型。於是像技術總監發起兩次審批，但都被駁回了。第一次金額類型為 DECIMAL(32,8) , 第二次類型是 DECIMAL(10,2），之後技術總監說，你第一次的類型可能是對的，於是小彭百思不得其解，引發以下的靈魂三問......

為什麼系統期初設置金額時要用 int 10 類型？
為什麼兩次審批都被駁回？
為什麼後來技術總監又說第一次的可能是對的？
簡單思考過後：小彭，大膽的推測了第一個問題，可能是當初設計數據結構時，認為金額精確到分即可，所以默認乘100 （保留兩位小數）。但金額最大為 9千萬元，是否真的能符合要求，回頭還得再問問技術總監。這時，小彭又想到兩個問題：

既然是保留小數了，為什麼還要用 INT 類型呢？
如果說 FLOAT和 DOUBLE類型可能會存在精度問題，又為什麼不用 DECIMAL類型呢？
經過查閱博客之後：小大概想通了第二個問題，第一次被駁回的原因是：DECIMAL類型在資料庫中是根據傳入的數值來決定存儲的位元組長度的，32明顯過長會導致磁碟空間的浪費。而第二次則是走了另外一個極端：原本長度為10已經快要滿足不了需求的了，如果再修改為同樣的長度意義不大，還會引起後續再次修改類型的情況。

又結合系統反思了一下：大概明白了第三個問題，至於金額的長度其實是沒有沒有一個具體的標準的，要根據具體業務情況，預估最大的金額上限，再決定具體長度。

意料之外的驚喜，在看書籍中意外的解決了第二組的兩個問題。 由於CPU不支持對 DECIMAL 的 直接計算，所以在計算的過程中需要額外的空間及計算開銷，導致性能過慢。還存在另外一種解決方案：使用 BIGINT 代替 DECIMAL，在計算時，可以乘或除以相應的倍數即可，來取代 DECIMAL 計算代價高的問題。

最後總結：

FLOAT和 DOUBLE類型會存在精度問題，是因為十進制0.1在電腦里用二進制是無法精確表示的。
DECIMAL類型在資料庫中存儲的位元組長度計算公式：對decimal(M,D) ，如果M>D，長度為M+2，否則為D+2。
要根據具體業務情況，預估最大的金額上限，再決定具體長度。
DECIMAL 計算的過程中需要額外的空間及計算開銷，性能低。