在MySQL中，数值型数据并不是一个笼统的概念，它主要由整数类型和小数类型两大类别构成。理解这两类数据在存储方式、精度表现和适用场景上的差异，是设计表结构时的重要基础。很多开发者在初期容易把所有数字字段都设为INT或DOUBLE，却没有意识到不同数值类型在底层存储和运算规则上的巨大区别，这往往会在后续业务中埋下精度丢失或空间浪费的隐患。
一、MySQL数值型数据的两大类别：整数与小数
MySQL官方将数值数据类型划分为整数类型和小数类型。整数类型专门用于保存没有小数部分的数值，例如用户ID、库存数量、年龄、状态码等。这类数据在计算机内部以二进制形式直接表示，存储紧凑，运算速度快。小数类型则用来表示带小数点的数值，它可以进一步细分为浮点类型和定点类型。浮点类型包括FLOAT和DOUBLE，采用近似存储方式；定点类型即DECIMAL，采用精确存储方式。
为什么MySQL要区分整数和小数？根本原因在于计算机处理这两类数值的成本不同。整数运算可以直接由CPU的整数单元完成，不需要处理小数点的位置变化，因此效率较高。而小数运算需要额外的小数点对齐、舍入策略以及精度控制，尤其是十进制与二进制之间的转换，会让某些看似简单的小数在二进制中变成无限循环数，从而产生精度误差。理解这一点，就能明白为什么金额字段不建议使用FLOAT，而应选择DECIMAL。
从设计角度看，明确两大数据类别可以帮助开发者快速缩小选择范围。遇到不带小数的数值时，优先在整数类型中挑选合适的宽度；遇到需要小数部分的数据时，再根据精度要求决定使用浮点类型还是定点类型。这个基础分类是掌握MySQL数值类型体系的第一步。
二、整数类型详解：从TINYINT到BIGINT
MySQL提供了五种主要的整数类型，它们的差别在于占用字节数和表示范围。TINYINT占用1字节，有符号范围是-128到127，无符号范围是0到255；SMALLINT占用2字节，有符号范围约-3.2万到3.2万；MEDIUMINT占用3字节，有符号范围约-838万到838万；INT占用4字节，有符号范围约-21亿到21亿；BIGINT占用8字节，可以表示非常大或非常小的整数。选择时需要根据实际业务数据的最大可能值来确定，既不要浪费空间，也要预留一定的增长空间。
整数类型支持UNSIGNED属性，可以将正数范围扩大一倍。例如TINYINT UNSIGNED可以存储0到255，适合存储年龄、状态码等不可能为负数的数据。但需要注意的是，UNSIGNED不会改变存储字节数，只是改变了最高位的含义。如果字段本身不涉及负数，使用UNSIGNED是合理的扩展范围手段。
下面通过一个建表语句展示不同整数类型的典型用法：
CREATE TABLE user_profile ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, age TINYINT UNSIGNED NOT NULL, login_count INT UNSIGNED DEFAULT 0, phone_code SMALLINT UNSIGNED, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
在这个示例中，id字段使用BIGINT UNSIGNED来支持海量用户增长；age字段使用TINYINT UNSIGNED，因为年龄通常在0到150之间；login_count使用INT UNSIGNED可以记录较大的登录次数；phone_code使用SMALLINT UNSIGNED存放国际区号。如果所有字段都使用INT，虽然开发简单，但会造成不必要的存储开销，当表数据量达到亿级时，每行多浪费几个字节也会显著增加磁盘占用。
还有一个容易忽略的问题是整数溢出。当插入的值超过字段范围时，在严格模式下MySQL会报错；在非严格模式下，MySQL会根据SQL模式进行截断或报错，但通常不会自动扩展字段类型。因此在设计阶段就应该评估字段的最大可能值，防止后续业务增长导致溢出。
三、小数类型详解：浮点数与定点数的关键区别
小数类型中，FLOAT和DOUBLE属于浮点类型，它们遵循IEEE 754标准，使用二进制浮点数近似表示十进制小数。FLOAT占用4字节，约7位有效十进制精度；DOUBLE占用8字节，约15位有效十进制精度。浮点类型的优势在于可以表示非常大或非常小的数值，例如科学计算、传感器数据等场景，但代价是无法精确表示所有十进制小数。
DECIMAL属于定点类型，它以字符串或二进制十进制格式存储，可以精确表示指定精度的小数。定义DECIMAL时需要指定总位数M和小数位数D，例如DECIMAL(10,2)表示总共10位数字，其中2位是小数，整数部分最多8位。DECIMAL的存储空间与M值相关，通常每9位十进制数字占用4字节，因此DECIMAL的存储开销通常比DOUBLE更大，但换来的是精确的十进制运算。
下面的查询可以直观展示浮点数与定点数的精度差异：
SELECT 0.1 + 0.2 = 0.3 AS float_result; SELECT CAST(0.1 AS DECIMAL(10,2)) + CAST(0.2 AS DECIMAL(10,2)) = 0.3 AS decimal_result;
第一个查询返回0，因为0.1和0.2在二进制浮点数中无法精确表示，相加后的结果并不是精确的0.3；第二个查询返回1，因为DECIMAL按照十进制精确存储和计算。这个例子充分说明了为什么金额、财务数据、汇率等对精度敏感的场景必须使用DECIMAL，而不能使用FLOAT或DOUBLE。
此外，FLOAT和DOUBLE在等值比较时也容易出现问题，因为不同运算路径得到的近似值可能存在极微小的差异。即使两个浮点数在显示上看起来相等，直接用等号比较也可能失败。建议浮点类型的比较使用范围判断或容忍误差，而DECIMAL则可以放心进行等值比较。
四、如何选择数值类型：场景与避坑建议
选择数值类型时，首先要判断数据是否包含小数。如果不包含小数，优先考虑整数类型，并根据值的范围选择TINYINT、SMALLINT、INT或BIGINT。如果字段允许负数，保留有符号范围即可；如果确定不会出现负数，加上UNSIGNED可以让正数范围翻倍。对于自增ID、日志计数等可能快速增长的字段，建议直接使用BIGINT，避免后期从INT迁移到BIGINT带来的表结构变更成本。
如果数据包含小数，则需要进一步区分精度要求。对于金额、税费、账户余额、交易金额等业务关键数据，必须使用DECIMAL，并合理设置M和D的值。例如金额通常使用DECIMAL(12,2)存储，可以支持最高99亿的金额，精确到分。对于统计指标、评分、科学计算结果等允许微小误差的场景，可以使用DOUBLE以获得更大的数值范围和更小的存储空间。
还有一些常见误区需要避免。一是不要使用FLOAT存储金额，即使金额数值不大，浮点误差也可能在多次累加后被放大，导致对账不平。二是不要用字符串类型（如VARCHAR）存储数值，这样会丧失数值运算能力，并且排序、比较、聚合都会退化为字符串逻辑。三是不要过度使用DECIMAL，因为DECIMAL的运算性能比整数和浮点数低，存储开销也更大，在非精确场景下会浪费资源。四是不要把所有整数字段都设为INT，根据实际范围选择更小的类型可以让索引更紧凑，提高查询性能。
总体而言，MySQL数值型数据的两大类别——整数与小数——各自有清晰的适用边界。设计表结构时，应当结合业务数据的范围、精度和运算需求，从这两大类别中挑选最合适的子类型。这样既能保证数据正确性和一致性，又能优化存储和查询效率，为系统长期稳定运行打下良好基础。