mysql不支持“只允许update某几列”的原生权限控制，因列级update权限仅校验sql中显式列出的列名是否授权，不拦截实际数据变更；可靠方案是用before update触发器比对new/old值并signal中断，或sql server的instead of update触发器重写逻辑。
直接结论：MySQL 不支持“只允许 UPDATE 某几列”的原生权限控制，必须用 BEFORE UPDATE 触发器或视图 + 权限组合实现；SQL Server 可用 INSTEAD OF UPDATE 触发器更灵活地重写逻辑。
为什么不能靠 GRANT UPDATE (col1, col2) 解决问题
MySQL 的列级 UPDATE 权限只控制「用户能否在 UPDATE 语句中显式写出该列」，不阻止语句执行后实际修改——也就是说：
- 如果用户有
UPDATE (name, email)权限，但写了UPDATE users SET name = 'x', phone = 'y' WHERE id = 1，会直接报错ERROR 1142 (42000): UPDATE command denied to user ... for column 'phone' - 但如果应用层拼的是
UPDATE users SET name = 'x', email = 'y' WHERE id = 1，哪怕表里还有salary列，MySQL 也完全不管——它只校验 SQL 文本里出现的列名是否在授权列表中 - 这意味着：权限是「语法检查层」的，不是「数据变更拦截层」的；只要 SQL 合法，数据库就照单执行，不会二次验证字段值是否真的该被改
MySQL 中真正生效的列更新拦截：BEFORE UPDATE 触发器
这是目前最可靠、行为可预测的方式。核心思路是：在更新发生前比对 OLD.col 和 NEW.col，发现非法变更立即中断。
例如禁止修改 id 和 created_at：
DELIMITER $$
CREATE TRIGGER before_users_update
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF NEW.id != OLD.id THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'cannot update the id column';
END IF;
IF NEW.created_at != OLD.created_at THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'cannot update the created_at column';
END IF;
END$$
DELIMITER ;
- 必须用
BEFORE UPDATE，不是AFTER或INSTEAD OF（MySQL 不支持后者） -
NEW.col != OLD.col是关键判断，避免把 NULL 和 NULL 误判为变更（NULL != NULL 返回 NULL，不是 TRUE） - 若字段允许 NULL，且业务上「从非 NULL 改成 NULL」也算非法，需额外加
IS NULL判断 - 触发器里不能写
UPDATE语句，否则会递归调用自己
SQL Server 更适合复杂拦截逻辑：INSTEAD OF UPDATE
当需要「允许改 A 列但仅当 B 列满足某条件」这类规则时，INSTEAD OF UPDATE 触发器能接管整个更新流程，自行决定哪些行、哪些列真要改。
例如：只允许活跃员工更新 Salary：
CREATE TRIGGER trg_PreventSalaryChange ON Employees
INSTEAD OF UPDATE
AS
BEGIN
-- 先回滚掉所有 salary 更新（无论是否活跃）
UPDATE e SET e.Salary = d.Salary
FROM Employees e
INNER JOIN deleted d ON e.EmployeeID = d.EmployeeID
WHERE d.IsActive = 0;
<p>-- 再放行活跃员工的 salary 更新
UPDATE e SET e.Salary = i.Salary, e.Status = i.Status
FROM Employees e
INNER JOIN inserted i ON e.EmployeeID = i.EmployeeID
INNER JOIN deleted d ON e.EmployeeID = d.EmployeeID
WHERE i.IsActive = 1;</p><p>-- 对非活跃员工抛错
IF EXISTS (SELECT * FROM inserted i JOIN deleted d ON i.EmployeeID = d.EmployeeID WHERE d.IsActive = 0)
BEGIN
RAISERROR('Cannot update salary for inactive employees.', 16, 1);
ROLLBACK TRANSACTION;
END
END;</p>
-
INSTEAD OF允许你完全跳过原 UPDATE，用自定义逻辑替代 - 必须手动处理所有允许更新的列，漏写就会变成 NULL（比如没写
e.Name = i.Name，Name 就被清空） - 注意
inserted和deleted表的用途：inserted是新值，deleted是旧值 - 错误必须用
RAISERROR+ROLLBACK TRANSACTION配合，否则事务可能部分提交
容易被忽略的隐性成本和风险
触发器拦截看着干净，但上线前得确认三件事：
- 应用是否用了 ORM 或客户端工具自动发
UPDATE ... SET col1=..., col2=..., col3=...全字段更新？这种写法会让触发器频繁误触发，尤其当某些列只是传了原值过来 - 触发器里做子查询或调用函数，会显著拖慢 UPDATE 性能；简单
IF NEW.x != OLD.x几乎无开销，但加个(SELECT COUNT(*) FROM logs WHERE user_id = NEW.id)就可能卡住 - MySQL 8.0.16+ 虽支持列级权限，但备份恢复时
mysql.columns_priv表容易遗漏；而触发器定义存在information_schema.TRIGGERS，备份 mysqldump 默认包含，更稳妥
