MySQL不支持列级UPDATE权限，GRANT UPDATE(col)语法无效；实际生效的字段级限制仅能通过BEFORE UPDATE触发器或封装逻辑的存储过程实现。
MySQL不支持UPDATE列级权限，直接GRANT UPDATE(col)无效
MySQL的UPDATE权限**只支持表级，不支持字段级写控制**。你不能用GRANT UPDATE (status) ON db.t TO 'u'@'%'来限制用户只能改status字段——这条语句语法上虽能执行，但实际不起作用。只要用户有整表UPDATE权限，就能更新任意字段；反之，若没授整表权限，哪怕只授了某几列，UPDATE操作仍会报ERROR 1142。
真正生效的字段级UPDATE限制只有两种硬方案
想让worker用户能改updated_at但不能碰amount，必须绕开权限系统本身：
- 用
BEFORE UPDATE触发器拦截：在BEFORE UPDATE ON orders里判断OLD.amount != NEW.amount，触发SIGNAL SQLSTATE '45000'报错。但注意：它拦不住UPDATE ... SET @var := amount这类间接读取，且批量更新时性能下降明显 - 用存储过程封装逻辑：把允许的更新逻辑（如“仅更新status和updated_at”）写进
PROCEDURE update_order_status，再GRANT EXECUTE ON PROCEDURE db.update_order_status TO 'worker'@'%'。用户只能调用该过程，无法直连表执行UPDATE
为什么别信“GRANT UPDATE(col)”能生效
常见误解是复制文档里“支持列级UPDATE”的描述就以为能用。实际上：
- MySQL官方文档中
UPDATE (col1, col2)语法仅用于兼容性保留，**自5.7起已明确标注为“无实际效果”** -
SHOW GRANTS输出里看到UPDATE (status)只是记录你输过什么，不代表运行时校验——MySQL服务端压根不检查这个 - 即使你
REVOKE UPDATE ON db.t FROM 'u'@'%'后再GRANT UPDATE (status) ON db.t，用户执行UPDATE t SET amount=1 WHERE id=1依然成功（因为没REVOKE掉其他权限，或误留了ALL PRIVILEGES）
最容易被忽略的验证盲区
测试是否真限制住，不能只看GRANT语句或SHOW GRANTS输出：
- 必须用该用户新建连接，执行
UPDATE t SET amount=999 WHERE id=1，观察是否报ERROR 1142（没权限）还是ERROR 1362（触发器拦截） - 如果用了触发器，还要测
UPDATE t SET status='x', amount=999 WHERE id=1——它应失败，但UPDATE t SET status='x' WHERE id=1必须成功 - 别忘了检查
INFORMATION_SCHEMA.TRIGGERS确认触发器状态为ENABLED，且DEFINER权限足够（否则可能静默失效）
