只授update权限而不授select即可实现仅修改不查询，但需先revoke冗余权限、精确匹配host四元组，并验证show grants输出仅含update；mysql不自动赋予select，where条件隐式读取会因缺select报错，字段级限制需显式指定列名。
只授 UPDATE 权限，不带 SELECT 就查不了
想让某用户能改某张表但不能看内容，直接 GRANT UPDATE ON db_name.table_name TO 'user'@'host' 即可。MySQL 不会自动附赠 SELECT 权限——没授，就真查不到。这点常被忽略，误以为“能 UPDATE 就该能查”，结果执行 UPDATE ... WHERE name = 'x' 时直接报错 ERROR 1142 (42000): UPDATE command denied，其实是 WHERE 条件触发了隐式读取，而用户根本没有 SELECT 权限。
如果你只要求“能按条件更新”，又不想开放整表查询，得换思路：用存储过程封装逻辑，再单独授予 EXECUTE 权限；或者改用带行级限制的视图 + UPDATE 授权（但视图本身不支持直接 UPDATE，需是可更新视图且底层表权限已配好）。
REVOKE 之前必须确认四元组完全匹配
如果用户已有 ALL PRIVILEGES 或其他组合权限，仅执行 GRANT UPDATE 不会覆盖旧权限。必须先清理：
REVOKE SELECT, INSERT, DELETE, DROP, ALTER ON db_name.table_name FROM 'user'@'host'- 注意：
'user'@'host'中的host必须和原始授权时一模一样，比如原先是'reporter'@'10.20.5.%'，就不能用'reporter'@'%'去REVOKE，否则静默失败 - 执行后务必用
SHOW GRANTS FOR 'user'@'host'确认输出里只剩UPDATE（或你期望的权限）
MySQL 8.0+ 的角色机制更适合批量管理
手动给每个用户反复 GRANT/REVOKE 容易出错，尤其当多个用户需相同表级 UPDATE 权限时：
- 先建角色：
CREATE ROLE 'table_updater' - 授予权限：
GRANT UPDATE ON sales_db.orders TO 'table_updater' - 把用户加进角色：
GRANT 'table_updater' TO 'user_a'@'10.0.1.%', 'user_b'@'10.0.2.%' - 启用角色（对用户生效）：
SET DEFAULT ROLE 'table_updater' TO 'user_a'@'10.0.1.%'
这样后续只需调整角色权限，所有成员自动同步。但注意：角色在 MySQL 8.0 才默认启用，低版本不支持。
UPDATE 权限本身不包含字段级控制，要限制列就得显式指定
默认 GRANT UPDATE ON db.t TO u 允许更新整张表任意字段。若只想让其改 status 和 updated_at，必须写成：
GRANT UPDATE (status, updated_at) ON app_db.tasks TO 'worker'@'192.168.10.%';
此时该用户对其他字段执行 UPDATE 会报 ERROR 1142；但如果它有 SELECT 权限，仍能读全部字段——字段级 UPDATE 和 SELECT 是独立控制的。
真正容易被绕过的点在于：只要用户能连上、有 UPDATE 权限，且表结构公开，他就可能通过错误信息、响应时间、主键范围试探等方式间接推断数据。权限控制只是第一道门，敏感字段加密、应用层校验、审计日志这些不能省。
