MySQL在SQL执行时对字段值进行隐式类型转换，由目标列类型驱动，发生在WHERE/INSERT/UPDATE等语句的值绑定阶段；字符集不匹配会导致截断或替换；DEFAULT值在解析阶段确定；SELECT结果已格式化，JSON字段需用->>获取数字类型。
SQL执行时字段值如何被MySQL转换
MySQL在解析SQL语句后，会对输入值做隐式类型转换，这个过程发生在WHERE、INSERT、UPDATE等语句的值绑定阶段。比如向INT列插入字符串'123abc'，MySQL会截取前导数字部分转成123；而'abc123'则转为0（严格模式下会报错Truncated incorrect INTEGER value）。
关键点在于：转换由目标列的数据类型驱动，不是由SQL字面量决定。常见触发场景包括：
- 比较操作中两边类型不一致，如
WHERE id = '10'（id是INT） -
INSERT INTO t(col) VALUES ('2023-10-01')插入到DATE列 - 函数参数类型与传入值不匹配，如
DATE_ADD('2023', INTERVAL 1 DAY)
字符集与排序规则如何影响存储前的转换
当客户端发送的字符串与表/列定义的CHARSET或COLLATION不一致时，MySQL会在写入前做字符集转换。例如客户端用utf8mb4连接，但某列定义为latin1，那么'✅'这类4字节UTF-8字符会被截断或替换为'?'，且不会报错——除非开启STRICT_TRANS_TABLES。
容易忽略的细节：
-
CONVERT()和CASE ... COLLATE显式转换只影响当前表达式，不改变列定义 - 连接层
character_set_client、character_set_connection、character_set_results三者不一致会导致同一SQL在不同客户端表现不同 -
SHOW VARIABLES LIKE 'character\_set%'看到的是会话级配置，不是表结构本身
INSERT/UPDATE中NULL、DEFAULT、表达式值的求值时机
MySQL在执行DML前先完成所有值的求值与类型适配，再进入存储引擎层。这意味着：
-
DEFAULT值在语句解析阶段就确定，不是每次插入时动态计算（除非是CURRENT_TIMESTAMP或UUID()这类特殊函数） -
NULL插入到NOT NULL列会直接报错Column 'x' cannot be null，不会尝试转空字符串或0 - 表达式如
price * 0.9在server层完成计算，结果类型由操作数精度决定；若price是DECIMAL(10,2)，乘法结果可能被截断为DECIMAL(10,2)而非自动扩展
INSERT INTO orders (total, discount) VALUES (199.99, total * 0.1); -- 错误：不能在VALUES里引用刚插入的列
INSERT INTO orders (total, discount) VALUES (199.99, 199.99 * 0.1); -- 正确：值必须是常量或确定表达式
为什么SELECT结果看起来“没转换”，但实际已发生隐式转换
SELECT语句中看似“原样返回”的值，其实早已经历server层的类型推导和格式化。例如查询TINYINT列返回整数1，但若该列有ENUM('a','b')，实际返回的是字符串'a'——因为ENUM底层存储是整数，但查询时按定义映射回字符串。
更隐蔽的问题出现在JSON字段：
-
JSON_EXTRACT(json_col, '$.id')返回带引号的字符串"123"，不是数字123 -
->>操作符才做自动去引号转换，即json_col ->> '$.id'返回123（类型为DECIMAL） - 对JSON字段使用
ORDER BY时，若未用->>，排序按字符串规则进行，"10"会排在"2"前面
真正写入磁盘前的最终形态，取决于存储引擎（InnoDB/Blob格式）、行格式（COMPACT/DYNAMIC）、以及是否启用了innodb_strict_mode——这些配置决定了截断、警告、错误之间的边界在哪里。
