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——这些配置决定了截断、警告、错误之间的边界在哪里。
