隐式类型转换导致索引失效和全表加锁：当字段类型与查询值不一致（如BIGINT字段传字符串、VARCHAR字段传数字），MySQL会逐行转换列值，破坏B+树有序性，使EXPLAIN显示type=ALL、key=NULL，触发全表扫描及全表记录锁。
WHERE 字段类型和传入值必须严格一致
隐式类型转换是锁表最隐蔽的诱因——它不报错，但会让 EXPLAIN 显示 type=ALL 或 type=index，实际扫描全表并逐行加锁。比如 user_id 是 BIGINT，却写成 WHERE user_id = '123'；或 phone 是 VARCHAR，却用 WHERE phone = 13800138000。
这类写法在测试环境可能跑得通，一到生产就触发全表扫描+全表加锁。验证方式很简单：EXPLAIN FORMAT=TRADITIONAL SELECT ... 看 key 是否为空、rows 是否远超预期匹配数。
- MySQL 中，用
CAST()或直接改参数类型：把'123'改成123，或显式写WHERE user_id = CAST('123' AS SIGNED) - SQL Server 中，优先用
TRY_CONVERT()替代隐式转换，避免遇到非数字字符时整个批处理崩溃 - ORM 场景下，检查生成 SQL 的参数绑定逻辑，确保字段类型与变量类型对齐（如 Java 的
Long对应BIGINT，不是String）
函数包裹字段会让索引彻底失效
WHERE DATE(created_at) = '2026-10-01' 看似合理，实则强制全表扫描。InnoDB 和 SQL Server 都无法用索引加速带函数的表达式，等价于对每行计算一次函数再比对。
正确写法是把函数“推到右边”，让字段单独出现在比较左侧：
- 改
DATE(created_at) = '2026-10-01'为created_at >= '2026-10-01' AND created_at - 改
UPPER(name) = 'ALICE'为建函数索引（MySQL 8.0+）或用生成列+普通索引 - 避免
LIKE '%abc'开头的模糊查询，它天然无法走索引，会放大扫描范围和锁量
分批 UPDATE 必须用索引字段做范围切片，不能只靠 LIMIT
UPDATE ... WHERE status = 'pending' LIMIT 1000 看似安全，但如果 status 没索引，或只有单列 status 索引而区分度极低（比如 95% 都是 pending），InnoDB 仍会全表扫描，只是最后只改前 1000 行——锁早已加满。
真正可控的做法是基于有索引的单调字段（如 id 或 created_at）做确定性切片：
- MySQL：用
WHERE id > 100000 AND id ，配合 <code>id主键索引，每次只扫描目标区间 - SQL Server：用
WHERE id > @last_id ORDER BY id+TOP(1000)，每次更新后用SELECT @last_id = MAX(id)推进 - 绝对避开
WHERE id IN (SELECT id FROM ...)—— 子查询未落地前，InnoDB 可能对整张源表加意向锁
查锁源永远比调 WHERE 条件更优先
UPDATE 卡住时，90% 不是这条语句本身的问题，而是被别的事务堵住了。盲目加索引、改写 WHERE，可能完全跑偏。
先定位谁在占锁：
- MySQL：查
information_schema.INNODB_TRX，按TRX_STARTED排序，重点关注状态为LOCK WAIT的事务，再关联INNODB_LOCK_WAITS找 blocking_trx_id - SQL Server：立刻执行
SELECT blocking_session_id, wait_type, wait_resource FROM sys.dm_exec_requests WHERE blocking_session_id > 0
锁升级不是语法错误，而是事务边界失控、扫描范围失控、或并发节奏失控的综合结果。一个没提交的事务，可能让后续所有相关 UPDATE 原地冻结十几分钟——这种问题，EXPLAIN 看不出，索引也救不了。
