UPDATE变慢主因是WHERE字段与值类型不一致触发隐式转换，导致索引失效、全表扫描；如VARCHAR字段用数字查询（user_id = 123）、DATETIME字段用数值字面量（create_time >= 20240101），均会强制逐行类型转换，破坏B+树索引有序性。
UPDATE 语句变慢，大概率不是 SQL 写错了，而是 WHERE 条件里字段类型和值类型不一致，触发了 MySQL 的隐式类型转换——它会直接废掉索引，强制全表扫描。
WHERE 字段是 VARCHAR，但传了数字（比如 user_id = 123）
这是最典型的踩坑场景。MySQL 会把每一行的 user_id 值都转成浮点数再比，B+ 树索引无法支持这种逐行运行时转换。
- 现象：
EXPLAIN SELECT *显示type=ALL、rows接近总行数，key为空 - 验证方法：把条件改成
user_id = '123'再 EXPLAIN，如果type=ref且key显示索引名，就坐实了问题 - ORM 尤其危险：MyBatis 的
#{id}如果 Java 类型是Long，而 DB 字段是VARCHAR，SQL 就会悄悄生成数字字面量
WHERE 字段是 DATETIME/BIGINT，但传了字符串（比如 create_time >= '20240101'）
看着像字符串，但 MySQL 会按数值解析这个字面量，再尝试转成时间，整个过程绕过索引。更隐蔽的是 create_time >= 20240101（没引号），这会被当成整数比较，完全偏离时间语义。
Ainee: AI Notetaker
下载
一款AI办公效率工具，主要用于Your ultimate AI-powered notetaking and learning companion.，适合需要提升相关任务效率的用户。
- 后果不只是慢：全表扫描期间，InnoDB 会对每行加 X 锁，哪怕只更新 1 行，也可能锁住几千行，引发其他事务卡在
Updating或Locked - 注意字符集混用：表用
utf8mb4，但连接层用latin1，或 JOIN 的两张表字段字符集不同，也会触发隐式转换，执行计划里会出现Using where; Using index但实际没走索引 -
EXPLAIN UPDATE在 MySQL 5.6.2 之前根本不可用，报错ERROR 1064 (42000)不代表 SQL 有语法错误，只是版本太低
怎么快速定位是不是隐式转换惹的祸？
别猜，用等价 SELECT 模拟，条件一字不差，然后看 EXPLAIN 的 type 和 key 字段。
- 必须用
SELECT *，不能带函数（如WHERE DATE(created_at) = '2024-01-01'会失效） -
key为空 ≠ 没建索引，可能是联合索引最左前缀没满足（比如索引是(a,b,c)，条件只写了WHERE b = 1） - 查
information_schema.INNODB_TRX看长事务，确认有没有未提交的 UPDATE 占着资源导致锁堆积
真正难处理的不是发现隐式转换，而是它往往藏在框架参数传递、连接层字符集配置、甚至上下游服务数据类型定义不一致里——这些地方不会报错，但会让索引在你毫无察觉时彻底失效。
