decimal是逐位编码的定点数，避免二进制浮点精度问题，适用于金融等高精度场景；其存储将整数与小数分开编码，支持确定性舍入；DECIMAL(M,D)中M为总有效数字位数，D为小数位数；修改M/D可能触发全表重写导致锁表；运算性能低于整数，建议金额存为整数单位以提升效率。
decimal 类型不是“带小数点的整数”，也不是“近似小数”，它是把数字按十进制位逐位编码存储的定点数。这种设计天然规避了二进制浮点数（如 FLOAT/DOUBLE）因进制转换导致的 0.1 + 0.2 ≠ 0.3 这类精度漂移，所以金融、计费、审计等场景必须用 decimal。
decimal 怎么存数据：整数+小数分开编码
它不把整个数字当做一个二进制值处理，而是拆成两部分：小数点前的有效位、小数点后的有效位。底层常用 Binary-Coded Decimal（BCD）或压缩十进制格式——每个十进
制数字（0–9）用 4 位二进制独立表示。比如 123.45 存的是 “1”“2”“3”“.”“4”“5” 的精确编码序列，不是 123.45 的二进制近似值。
- 插入 99.99，读出来就是 99.99，不会变成 99.98999999999999
- 计算 0.1 + 0.2 得到 0.3，不是近似值
- 支持确定性舍入：ROUND(123.456, 2) 稳定返回 123.46，不依赖 CPU 或语言实现
精度参数 M 和 D 的真实含义
DECIMAL(M, D) 中：
-
M（精度） 是总有效数字位数，不是“整数位 + 小数位”之和的简单相加，而是整个数字最多能写几位十进制数字（含负号和小数点位置），最大支持 65（MySQL）或 38（SQL Server）
-
D（标度） 是小数点后固定保留的位数，必须满足 0 ≤ D ≤ M；D 越大，能存的小数越精细，但整数部分可用位数就越少
- 例如 DECIMAL(10, 4)：最多 10 位数字，其中 4 位在小数点后 → 整数部分最多 6 位 → 可存 -999999.9999 到 999999.9999
为什么改 decimal 字段容易锁表？
修改 DECIMAL(M, D) 的 M 或 D 值属于“元数据变更 + 数据重写”。数据库要逐行检查并可能重排二进制存储结构，尤其当表很大时：
- ALTER COLUMN Price DECIMAL(12,4) → 需验证每条现有数据是否仍在新范围内
- 若原值是 999999.999，而新定义是 DECIMAL(10,3)，就直接报错失败
- MySQL 5.7+ 对某些修改支持 ALGORITHM=INSTANT，但仅限增加精度（如从 (10,2) → (12,2)），不能减少或调高 D
性能开销在哪？什么时候该警惕
decimal 运算比整数慢，原因在于：
- 每次加减乘除都要对齐小数位、逐位运算、处理进位/借位，无法利用 CPU 的原生整数指令流水线
- 索引效率略低：同样长度下，decimal 的比较逻辑比 BIGINT 复杂，范围查询或排序时 CPU 消耗更高
- 批量场景明显：千万级订单汇总统计中，用 DECIMAL(18,2) 做 SUM 耗时可能是 BIGINT（单位为分）的 2–3 倍
建议策略：
- 金额统一转为“最小货币单位整数”（如分、厘）存 BIGINT，应用层负责格式化显示
- 确需小数语义（如利率、折扣率、浓度值）再用 decimal，并严格按业务需要设 M/D，避免盲目留大余量
- 报表类查询可考虑物化视图或预聚合表，把 decimal 计算提前固化
制数字（0–9）用 4 位二进制独立表示。比如 123.45 存的是 “1”“2”“3”“.”“4”“5” 的精确编码序列，不是 123.45 的二进制近似值。