MySQL CONVERT函数详解：从字符串到数字/日期的类型转换与避坑-代码聚汇网

MySQL CONVERT函数详解：从字符串到数字/日期的类型转换与避坑

康石石·2026-09-03·阅读 22 GEO检测（免费）

CONVERTMySQL类型转换

|难度：普通|阅读约 35 分钟

1. CONVERT函数的两种形态：从SQL标准到ODBC风格的差异

我最早接触CONVERT是在接手一个老项目的时候。那个项目的数据库里存了一堆“看起来是数字其实是字符串”的字段，订单金额、用户积分、商品销量，全是varchar。当时有个报表要按金额排序，结果排序结果惨不忍睹：900排在了9999后面，因为字典序和数值序根本不是一回事。我一查，发现大家连类型转换都没做，直接ORDER BY，MySQL就只能按照字符串的字符顺序去排。

要解决这类问题，首先得搞清楚MySQL里CONVERT到底有多少种写法。很多刚入行的同学以为CONVERT就是一个固定写法，其实它有两套风格，长得不一样，用的场景也不一样。

1.1 ANSI/标准语法：CONVERT(expr, type)

这是最常用的一种，表达很直白：把表达式expr转换成type指定的数据类型。语法长这样：

sql复制CONVERT(expr, type)

type支持的类型有这些：

类型	说明	示例
BINARY	转成二进制字符串	CONVERT('abc', BINARY)
CHAR	转成字符串，可带字符集参数	CONVERT('abc', CHAR(10))
DATE	转成日期	CONVERT('2024-05-01', DATE)
DATETIME	转成日期时间	CONVERT('2024-05-01 12:30:00', DATETIME)
DECIMAL	转成定点小数	CONVERT('123.45', DECIMAL(10,2))
SIGNED	转成有符号整数	CONVERT('-100', SIGNED)
UNSIGNED	转成无符号整数	CONVERT('100', UNSIGNED)
TIME	转成时间	CONVERT('12:30:00', TIME)
YEAR	转成年份（MySQL 8.0.22+）	CONVERT('2024', YEAR)

注意，这里有个到处都会踩的小坑：SIGNED是有符号，UNSIGNED是无符号。如果字符串里存的是负数，你用UNSIGNED去转，结果会溢出。比如CONVERT('-1', UNSIGNED)，在MySQL里会返回一个很大的数（18446744073709551615），因为无符号整数没有负数概念，负数会绕到最大值那边去。这个坑我在线上环境见过不止一次，后面详细讲。

1.2 ODBC风格语法：CONVERT(expr USING transcoding_name)

这是第二种写法，专门用于字符集转换，语法完全不一样：

sql复制CONVERT(expr USING transcoding_name)

USING后面跟的是字符集名称，比如utf8mb4、gbk、latin1。这个语法的作用是把字符串从当前字符集转成目标字符集。举例，如果你有一个gbk编码的字段，要转成utf8mb4，可以这样：

sql复制SELECT CONVERT(username USING utf8mb4) FROM user_info;

但要小心，别把这两种语法混在一起。我之前见过有人写CONVERT('abc', USING utf8mb4)，也见过CONVERT('abc', CHAR USING utf8mb4)，都报语法错误。正确写法只有两种，要么CONVERT(expr, CHAR)，要么CONVERT(expr USING charset)，中间别混着来。

MySQL官方文档里还有第三种写法，带USING和逗号参数组合的完整形式，但实际开发中极少用到，我也几乎没有在生产环境见过，知道有这回事就行。

1.3 和CAST函数的关系：同一个世界的两个名字

说到CONVERT，就绕不开CAST。MySQL里CAST也是做类型转换的，语法：CAST(expr AS type)。很多人分不清它俩到底有什么区别，其实在MySQL里，它俩在绝大多数场景下是等价的。

对比项	CONVERT	CAST
语法	CONVERT(expr, type)	CAST(expr AS type)
字符集转换	支持CONVERT(expr USING charset)	不支持
支持的类型	全部	全部
标准兼容性	ODBC风格	SQL标准

实际使用中，我个人的习惯是：只在字符集转换时用CONVERT，其他的类型转换统一用CAST。这个习惯来源于代码可读性——CAST(expr AS DECIMAL(10,2))一眼就能看出是标准SQL，跨数据库迁移的时候不用改。但如果你所在团队更习惯CONVERT，也没问题，只是保持一致就好。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 字符串转数字：一张订单表的varchar字段是如何逼疯我的

说回我开头提到的那个订单表。那个表的金额字段叫amount，设计表的人不知道为什么用了varchar(20)。当时面临的具体问题是：报表要给每个用户汇总消费总额，有个同事写的SQL是这样的：

sql复制SELECT user_id, SUM(amount) FROM orders GROUP BY user_id;

MySQL执行的时候不会报错，但结果对不对？要看amount里存了什么。如果所有金额都是纯数字字符串，比如'99.90'、'128.00'，SUM其实能算，因为MySQL在做算术运算时会对字符串进行隐式类型转换，自动把'99.90'转成数字99.9再参与求和。但问题在于，一旦里面有脏数据，比如某个记录是'12.5元'，或者干脆是空字符串''，结果就会变得非常诡异。

2.1 为什么必须显式转换，而不是靠隐式转换

先弄清楚一个概念，MySQL的隐式类型转换和显式类型转换，行为不完全一样。隐式转换是MySQL在执行SQL时自动完成的，规则大致是：

字符串和数字比较时，字符串会尝试转成数字
在算术运算（+、-、*、/）中出现的字符串，会转成数字
数字和字符串做拼接，用CONCAT时，数字会转成字符串

听起来很方便，对不对？但隐式转换有两个很麻烦的问题。第一，它不受你控制，规则是MySQL定死的；第二，它不触发索引，容易导致全表扫描，这是性能上的大坑。

说个具体例子，假设表里有一个索引列mobile，存的是手机号字符串。你写WHERE mobile = 13800138000，因为右边是数字，MySQL会把左边的mobile字段隐式转成数字再比较。问题来了，一旦字段做了函数或运算转换，索引就失效了，这个查询会变成全表扫描。表小时没感觉，表大了之后，一次查询几秒钟，线上直接报警。所以，字段是字符串就老老实实用字符串去匹配，要么把右边写成'13800138000'，要么把左边显式转换后另建列，而不是指望隐式转换帮你干活。

2.2 CONVERT转数字的完整用法

回到订单汇总的问题。正确的做法是，在做聚合之前，先把amount字段显式转成数字类型，而且要处理脏数据。

如果金额是整数，用SIGNED：

sql复制SELECT user_id, SUM(CONVERT(amount, SIGNED)) AS total_amount FROM orders GROUP BY user_id;

如果金额可能带小数，用DECIMAL，比如保留两位小数：

sql复制SELECT user_id, SUM(CONVERT(amount, DECIMAL(10,2))) AS total_amount FROM orders GROUP BY user_id;

这里要重点说一下DECIMAL。DECIMAL(10,2)里的10是精度，表示总共10位有效数字，2是标度，表示小数点后保留两位。如果你处理的金额很大，比如有几个亿，这个10要相应调大，否则会溢出，MySQL返回的是DECIMAL的最大值边界而不是报错，非常容易看漏。

再说一个容易翻车的地方：CONVERT('12.5元', DECIMAL(10,2))的结果是什么？MySQL的转换规则是：从字符串开头开始解析，能解析出数字就解析，遇到非数字字符就停止，忽略后面所有内容。所以：

CONVERT('12.5元', DECIMAL(10,2)) 返回 12.50
CONVERT('123abc', SIGNED) 返回 123
CONVERT('abc123', SIGNED) 返回 0
CONVERT('', SIGNED) 返回 0
CONVERT(NULL, SIGNED) 返回 NULL

这些规则如果你不清楚，很容易出现"明明字符串里有数字怎么转出来是0"的困惑。我见过一个真实场景，某业务的上报数据在特殊情况下会带单位后缀，比如"12元"，"5元"，前面的同事没做清洗直接CONVERT转数字，结果每个订单少算了0.几，月度报表差了十几万。所以转数字前，先了解一下你的数据到底长什么样。

2.3 空字符串和NULL是两码事

一个经常被忽略的细节是空字符串和NULL的转换结果完全不同。CONVERT('', SIGNED)返回0，而CONVERT(NULL, SIGNED)返回NULL。如果你在SUM里面用到空字符串，它会算成0参与求和，但如果原始值是NULL，则不会参与求和（SUM会忽略NULL）。这两种行为差异直接影响报表数字。

我的建议是：转换之前做数据清洗。用CASE WHEN加正则或者用TRIM判断空值，让脏数据统一变成NULL，或者统一变成0，视业务逻辑而定。比如：

sql复制SELECT user_id, SUM(
    CASE 
        WHEN amount IS NULL OR TRIM(amount) = '' THEN 0
        ELSE CONVERT(TRIM(amount), DECIMAL(10,2))
    END
) AS total_amount 
FROM orders 
GROUP BY user_id;

这样写虽然啰嗦一点，但至少结果是可预期的。

3. 字符串转日期：MySQL的宽松解析和你想的不一样

字符串转日期是CONVERT的另一个高频场景。通常发生在两种情况：一是外部系统导数据时日期字段是字符串，二是JSON接口返回值里日期是字符串需要入库。MySQL对日期字符串的解析规则可以说是"宽松"到让人惊喜，又"严格"到让人抓狂。

3.1 CONVERT字符串转日期的基本规则

最简单的用法：

sql复制SELECT CONVERT('2024-05-01', DATE);
-- 返回 2024-05-01

SELECT CONVERT('2024-05-01 14:30:00', DATETIME);
-- 返回 2024-05-01 14:30:00

SELECT CONVERT('14:30:00', TIME);
-- 返回 14:30:00

MySQL一个比较容易混的点是：CONVERT('2024-05-01', DATETIME)也行，因为日期字符串转成DATETIME时，时间部分自动补0。反过来，CONVERT('2024-05-01 14:30:00', DATE)也行，时间部分会被截断，只保留日期部分。这些行为在实际操作中很常用。

3.2 MySQL能解析哪些日期格式？

MySQL对日期字符串的解析能力比想象中强，它允许下面这些写法：

sql复制SELECT CONVERT('20240501', DATE);        -- 2024-05-01，数字格式
SELECT CONVERT('2024/05/01', DATE);      -- 2024-05-01，斜杠分隔
SELECT CONVERT('2024.05.01', DATE);      -- 2024-05-01，点分隔
SELECT CONVERT('2024-05-01', DATE);      -- 2024-05-01，标准格式
SELECT CONVERT('20240501143000', DATETIME); -- 2024-05-01 14:30:00

注意，分隔符不是强制的，20240501这种连着写的纯数字也可以转。甚至带时间部分的连写也可以解析。但是有一个最常见的坑：日月年的顺序。MySQL默认是年-月-日，不是月-日-年。如果你写CONVERT('05/01/2024', DATE)，MySQL会把它当成2024年5月1日还是2024年5月20日？答案是：看MySQL的sql_mode配置和版本，大多数情况下会报错或者返回0000-00-00，因为MySQL严格模式下不接受这种格式。如果你的数据是美国习惯的月/日/年，得先做字符串重组。

3.3 日期字符串解析的边界和诡异现象

MySQL对日期字符串的校验有一个特殊之处：它允许一些"不存在的日期"转出来是NULL或0000-00-00，而不是报错。比如：

sql复制SELECT CONVERT('2024-13-01', DATE);
-- 月份13不存在，返回 NULL（严格模式）或 0000-00-00（非严格模式）

这个行为很危险——你转出来一个无效日期，程序却不知道，继续往里写数据，后面查询时才发现有的是NULL，有的是0000-00-00，导致报表缺数。判断"到底有没有转换成功"，最稳妥的方法是配合MySQL的STR_TO_DATE函数使用。STR_TO_DATE的好处是你可以指定格式，严格校验，无法解析时返回NULL，方便在SQL里做过滤：

sql复制SELECT STR_TO_DATE('2024-13-01', '%Y-%m-%d');
-- 返回 NULL，因为13月不存在

所以我的建议是：如果只是快速查看，CONVERT够用了；如果是写入正式表之前的数据校验，优先用STR_TO_DATE。

3.4 反向操作：把日期转回字符串

还有一个非常常见但容易和CONVERT搞混的场景：不是字符串转日期，而是日期转字符串，用来格式化展示。这时候用DATE_FORMAT，不是CONVERT。虽然CONVERT也能把日期转成字符串（CONVERT(NOW(), CHAR)），但它的输出格式固定是'YYYY-MM-DD HH:MM:SS'，没法自定义。

sql复制SELECT DATE_FORMAT(NOW(), '%Y年%m月%d日');
-- 输出：2024年05月01日

这里有个小技巧：DATE_FORMAT和STR_TO_DATE的格式符是同一套，%Y四位年份，%m两位月份，%d两位日期，%H小时，%i分钟，%s秒。你把STR_TO_DATE和DATE_FORMAT放在一起记，正向反向都有了。

4. CONVERT在字符集转换和其他场景中的妙用

4.1 USING语法：修正乱码的主力工具

前面提到过CONVERT(expr USING charset)是字符集转换。这个场景有多常见？举个例子，我做数据迁移时，从老库导过来的数据经常出现中文乱码，一串"鏄箍鐮佷簡"这样的字。排查下来基本都是源库字符集和目标库字符集不一致导致的，比如源库latin1存了utf8的字节，导入后MySQL用latin1去解读utf8字节流，自然就乱了。

这种情况下，CONVERT(expr USING utf8mb4)可以救场。比如某个字段被当成latin1存了utf8的字节，要转回utf8mb4：

sql复制SELECT CONVERT(CONVERT(name USING latin1) USING utf8mb4) FROM some_table;

这里面的逻辑是：先用latin1把当前乱码字符串转成原始字节，再用utf8mb4把字节正确解码。这个双重转换的写法看起来绕，实际是修复乱码的经典套路。当然，最好的方案还是建表时统一用utf8mb4，但历史数据修复时，这个"套娃"写法非常实用。

4.2 CONVERT和CAST在项目中的选择策略

在团队协作里，代码一致性比个人偏好更重要。我见到过一个项目，一半SQL用CONVERT，一半用CAST，维护的人看一眼代码就要纠结一下这里到底是不是故意的。所以在真实项目里，要定一个统一规范。

我的建议是：

常规类型转换（字符串转数字、字符串转日期），优先用CAST，因为SQL标准可读性强、跨数据库迁移成本低
字符集转换，只能选CONVERT(expr USING charset)，因为CAST不支持这个功能
如果你的项目迁移到了MySQL 8.0，注意CAST还有一些扩展语法，比如CAST(expr AS CHAR CHARACTER SET utf8mb4)、CAST(... AT TIME ZONE ...)，这些在老版本里没有

4.3 CONVERT和聚合函数的配合

回到类型转换的实际业务场景，有时候不是单独一列需要转换，而是整个表达式需要统一类型。比如有个销量字段存储的是字符串，但你要做RANK()排名，那窗口函数里可以直接转换：

sql复制SELECT 
    product_id,
    CONVERT(sales_amount, UNSIGNED) AS amount,
    RANK() OVER (ORDER BY CONVERT(sales_amount, UNSIGNED) DESC) AS rn
FROM product_sales;

再比如，日期比较时，如果传入的是字符串参数，可以转成DATE再和日期列比较：

sql复制SELECT * FROM events 
WHERE event_date = CONVERT('2024-05-01', DATE);

这里有个细节：event_date本身是DATE类型，右边用字符串'2024-05-01'直接比较也行，MySQL会自动转换。但如果你是在一个复杂查询里、且event_date列上有索引，建议尽量让列独立出现在比较符一侧，不要对列本身用函数，否则索引失效。右边的字符串参数不管用不用CONVERT，因为它是常量，不会影响索引使用。

5. 类型转换实战避坑：从排序错乱到索引失效

这一部分把前面零零散散提到的坑做一次完整梳理。很多问题不止出现在MySQL，你在SQL Server、Oracle、PostgreSQL里同样会遇到类似的类型转换陷阱，只是函数名不同。这里我给出一份避坑清单。

5.1 排序错乱：字符串数字列ORDER BY结果不对

问题现象

sql复制SELECT amount FROM orders ORDER BY amount DESC;

结果：999、888、900、100、99……看起来完全没排序。

根因分析

amount是varchar，排序按字典序逐个字符比较。'999'和'900'比较，第一个字符'9'相等，第二个字符'9'和'0'比较，'9'比'0'大，所以'999'排在'900'前面，这就是字典序排序的结果。如果想让数字大小排序，必须显式转换：

sql复制SELECT amount FROM orders ORDER BY CONVERT(amount, SIGNED) DESC;

延伸建议

这种问题一旦出现，说明表结构设计已经有点危险了。如果这列全是纯数字，建议直接在业务层把表结构改了，把varchar字段改成int或decimal，从源头解决。临时SQL里用CONVERT只是一时的办法。我在实际项目中处理过类似问题：改了字段类型之后，原来跑1秒的报表SQL直接变成100毫秒，因为不再需要逐行隐式转换了。

5.2 CONVERT对索引的影响

这是最容易被忽视的性能问题。之前提到的WHERE mobile = 13800138000会走全表扫描，就是因为左侧字段发生了隐式转换。显式转换也一样，如果你写了：

sql复制SELECT * FROM orders WHERE CONVERT(amount, SIGNED) > 100;

amount列虽然建了索引，但在WHERE条件里对列套了CONVERT函数，比如CONVERT(amount, SIGNED)，MySQL无法直接使用amount列上的索引，因为索引存的是原始值，不是转换后的值。所以这条SQL同样会全表扫描。正确写法应该是：

sql复制SELECT * FROM orders WHERE amount > '100';

如果字段本身就是varchar，'100'字符串参与比较，两者都是字符串，走的是字典序比较加索引扫描，如果数据都是统一格式的纯数字，这个写法仍然可走索引。或者更彻底的方案：新建一个数字列，在数据写入时同步维护好数字值，WHERE条件使用这个数字列并建立索引，查询性能最稳。

5.3 从报错反推类型转换需求

网络上关于"failed to convert property value of type 'java.lang.string' to required type"这类报错的讨论很活跃，另外还有"failed to execute 'setattribute' on 'element': cannot convert object to primitive"这类前端报错。这些报错虽然发生在应用层，但根因往往可以追到数据库端的类型定义。

举个典型链路：Java应用里有一个Integer字段，但数据库表对应的列是varchar，ORM框架在把数据库值映射到Java对象时，尝试把"123"转成Integer，结果数据库返回了一个带空格的"123 "，或者根本就是非数字内容"暂无"，Java端就会抛出类型转换失败。这类问题，你在数据库端可以用CONVERT先做清洗，但更重要的还是统一数据类型——应用层类型和数据库字段类型要匹配，不能全靠ORM和数据源两边的宽松转换来兜底。

5.4 隐式转换的"友好"和"坑"只在一线之间

MySQL有一个很"贴心"但也很坑的机制：字符串和数字比较时，字符串会被转成数字。比如：

sql复制SELECT '10abc' = 10;
-- 返回 1（true），因为'10abc'转成数字是10

SELECT 'abc' = 0;
-- 返回 1（true），因为'abc'转成数字是0

这个行为在WHERE条件里会时不时坑你一把。比如你统计某列中有多少个非数字字符串时：

sql复制SELECT COUNT(*) FROM orders WHERE amount_column = 0;

你本意是想查"amount_column列内容为0的记录"，但结果把所有无法转成数字的字符串（比如'abc'、'暂无'、''）全都查出来了，因为它们全部被隐式转成0。这类问题排查起来极其耗费时间，因为SQL语法没有错，结果看起来也"合理"，就是总行数比预期多很多。

要避开这个坑，原则是：字符串列和数字比较时，要么把右侧也写成字符串，要么显式把左侧用CONVERT处理好再比较。我建议在写SQL之前先问自己一句："我到底是在比较字符串，还是在比较数字？"搞清楚这一点，很多类型转换的问题就能避免。

5.5 如果数据库不是MySQL：SQL Server的CONVERT差异

搜索引擎的热搜词里有不少"sqlserver 字符串转数字"的搜索记录，说明很多人是在SQL Server里遇到类似问题。SQL Server的CONVERT和MySQL最大的区别在于语法顺序：

sql复制-- SQL Server 的写法：CONVERT(目标类型, 表达式)
SELECT CONVERT(INT, '123');

-- MySQL 的写法：CONVERT(表达式, 目标类型)
SELECT CONVERT('123', SIGNED);

这是很多人从SQL Server迁移到MySQL或者反过来时最容易犯的错：把两个数据库的CONVERT参数顺序搞混了。此外，SQL Server的CONVERT还支持两个额外的参数去控制日期格式，比如CONVERT(VARCHAR, GETDATE(), 120)是标准日期时间格式，第三个参数120。MySQL没有这个用法，只能靠DATE_FORMAT。如果你的工作环境里同时维护多种数据库，最好把这样的差异整理成一张对照表，每次跨库操作前先看一眼，能省很多调试时间。

5.6 类型转换和存储过程、数据处理任务的配合

在存储过程或者ETL脚本里，类型转换更是家常便饭。比如我在写存储过程时接外部接口的数据，JSON里的字段都是字符串，插入表之前就要逐个转换：

sql复制SET @amount = CONVERT(JSON_UNQUOTE(JSON_EXTRACT(@json_body, '$.amount')), DECIMAL(10,2));
SET @created_at = STR_TO_DATE(JSON_UNQUOTE(JSON_EXTRACT(@json_body, '$.created_at')), '%Y-%m-%d %H:%i:%s');

这里有个实战小技巧：JSON_EXTRACT返回的字符串带引号，必须用JSON_UNQUOTE再去掉引号，否则CONVERT出来的数字是0，日期是NULL，找半天不知道错在哪。类似这种"多一层包裹"的坑，在数据处理里很常见，每次遇到类似报错，先检查一下是不是多了引号、多了空格、多了不可见字符。

最后再分享一个我自己的习惯

我平时写SQL处理线上问题时，现在养成了一个条件反射：凡是看到字符串和数字做比较、字符串排序、字符串聚合这些场景，第一反应不是直接写SQL，而是先花十秒钟想想"这一列到底是字符串还是数字"。这个习惯帮我避免了很多次线上事故。另外，如果一张表的数据量比较大，我会特别留意WHERE条件里的列是否被函数包了一层。CONVERT很强大，但用在不该用的地方，代价是性能。

最后送大家一个排查思路：先看字段定义，再用SELECT DISTINCT看真实数据样本，最后再决定怎么写转换函数，顺序反了，结果多半要返工。