MySQL的用户账号并不是单纯由用户名决定的，而是由用户名和来源主机共同组成，这意味着同一个用户名在不同主机上可以拥有完全不同的密码和全局权限。当业务系统迁移、网络划分调整或者安全策略收紧时，经常需要批量修改这些账号允许登录的主机范围。虽然使用自带的账号管理命令更安全，但在大量账号需要统一调整的场景下，直接通过UPDATE语句修改mysql.user表似乎是一种更快的选择。本文会把这个操作拆开讲清楚，包括哪些步骤必须做、哪些坑不能踩，以及有没有更稳妥的替代方式。

一、先理解mysql.user表里的Host字段

mysql.user表是MySQL权限体系的核心，它保存了账号信息和全局级别的权限。该表的主键由Host和User两列共同构成，也就是说，'app_user'@'10.0.0.5'和'app_user'@'10.0.0.%'是两个完全不同的账号。Host列支持具体IP地址、主机名、通配符百分号以及下划线等写法，例如%表示任意主机，10.0.0.%表示某个内网网段。修改主机限制，本质就是修改这一列的值。

不同MySQL版本中mysql.user表的列结构差异很大，但Host列始终存在。在MySQL 5.7和8.0中，该表使用InnoDB存储引擎，理论上可以像普通表一样执行UPDATE。不过必须清楚一点：直接修改这张表只是改变了账号允许登录的来源地址，并不会自动同步到其他权限表。因为MySQL的权限并不是只存在一张表里，全局权限放在mysql.user表，库级权限放在mysql.db表，表级权限放在mysql.tables_priv表，列级权限放在mysql.columns_priv表，存储过程权限放在mysql.procs_priv表。这些表中同样有Host列，用来标识权限授予给哪个主机上的用户。

如果只更新mysql.user表，比如把'app_user'@'10.0.0.5'改成'app_user'@'10.0.1.5'，但mysql.db表里仍然记录着'app_user'@'10.0.0.5'的库级权限，那么新账号登录后可能只拥有全局权限，而库级权限会丢失。这是直接UPDATE操作最容易忽略的隐患。因此，在动手之前一定要先查清楚这个用户都分布在哪些权限表里。

二、通过UPDATE语句批量修改Host的完整步骤

第一步永远是备份。权限表一旦改错，轻则单个账号异常，重则整个实例的权限体系混乱。可以使用mysqldump单独备份mysql库中的user表，也可以直接在数据库里创建备份表。下面是两种常见方式：

mysqldump -uroot -p mysql user > /tmp/mysql_user_backup_$(date +%F).sql

CREATE TABLE mysql.user_backup AS SELECT * FROM mysql.user;

备份完成后，不要急着执行UPDATE。先用SELECT语句精确锁定要修改的行，确认影响范围符合预期。比如现在需要把app_user和report_user两个账号允许登录的主机从10.0.0.%网段批量调整到10.0.1.%网段，可以先这样查询：

SELECT user, host FROM mysql.user
WHERE user IN ('app_user', 'report_user')
  AND host LIKE '10.0.0.%';

确认返回结果无误后，再执行UPDATE。对于前缀变化的场景，借助REPLACE函数可以一次性替换多个账号的主机前缀，而不需要逐个写等值匹配。SQL如下：

UPDATE mysql.user
SET Host = REPLACE(Host, '10.0.0.', '10.0.1.')
WHERE Host LIKE '10.0.0.%'
  AND user IN ('app_user', 'report_user');

如果只需要修改某一个具体账号的主机地址，也可以使用更精确的等值条件，避免误伤其他账号。例如：

UPDATE mysql.user
SET Host = '10.0.1.5'
WHERE Host = '10.0.0.5'
  AND user = 'app_user';

执行完UPDATE之后，MySQL并不会立即感知到权限变化。因为权限信息会缓存在内存中，直接修改底层表不会触发缓存刷新。必须手动执行以下命令让新的Host值生效：

FLUSH PRIVILEGES;

这一步非常关键。如果没有执行FLUSH PRIVILEGES，旧的权限缓存会继续沿用，新改的主机限制不会马上生效，甚至要等到实例重启后才会读取新的表数据。在实际操作中，忘记刷新权限是最常见的疏漏之一。

三、别忘了同步其他权限表

前面提到过，只更新mysql.user表可能不够。如果这个用户除了全局权限，还被授予过库级、表级或其他层级的权限，就必须同步修改对应权限表中的Host列。可以先通过查询判断该用户在哪些权限表中有记录：

SELECT user, host, db FROM mysql.db
WHERE user IN ('app_user', 'report_user');
SELECT user, host, db, table_name FROM mysql.tables_priv
WHERE user IN ('app_user', 'report_user');

如果mysql.db表中有这些用户的记录，就需要执行类似的UPDATE操作，保持宿主信息一致。以同样的网段迁移为例，可以执行：

UPDATE mysql.db
SET Host = REPLACE(Host, '10.0.0.', '10.0.1.')
WHERE Host LIKE '10.0.0.%'
  AND user IN ('app_user', 'report_user');
UPDATE mysql.tables_priv
SET Host = REPLACE(Host, '10.0.0.', '10.0.1.')
WHERE Host LIKE '10.0.0.%'
  AND user IN ('app_user', 'report_user');

不同MySQL版本中权限表的数量和名称可能有差异，但核心思路是一样的：凡是出现旧Host值的权限表，都要一并更新。如果只更新了mysql.user和mysql.db，却漏掉mysql.tables_priv，用户登录后可能在访问某张表时仍然出现权限拒绝。所有涉及的权限表更新完后，建议再执行一次FLUSH PRIVILEGES，确保缓存全部刷新。

四、验证结果与更稳妥的替代方案

更新完成后，不要只凭SQL执行成功来判断操作无误。应当从数据库内部和外部两个角度进行验证。内部可以先查看mysql.user表是否符合预期：

SELECT user, host, plugin FROM mysql.user
WHERE user IN ('app_user', 'report_user');

还可以使用SHOW GRANTS命令查看某个账号在当前主机授权下的权限快照，确认权限没有丢失：

SHOW GRANTS FOR 'app_user'@'10.0.1.%';

外部验证就是实际使用新主机地址连接MySQL。如果条件允许，可以在应用服务器或测试客户端上模拟连接，确认账号可以正常登录并且能够访问原有数据库对象。这种验证能发现仅靠查询无法暴露的问题，比如权限表同步不完整导致的访问被拒。

虽然UPDATE方式看起来直接高效，但MySQL官方更推荐使用RENAME USER语句来修改账号的主机限制。RENAME USER会自动更新所有权限表中的Host字段，不需要手动同步，执行后也会自动刷新权限缓存。语法如下：

RENAME USER 'app_user'@'10.0.0.%' TO 'app_user'@'10.0.1.%';

RENAME USER的缺点是它在批量处理大量账号时需要逐个执行，或者借助脚本循环调用。相比之下，UPDATE语句可以一条SQL同时修改很多行。因此，如果账号数量非常多且权限结构相对简单，UPDATE可能更省事；但如果权限层级复杂、涉及多个数据库和表对象，RENAME USER的安全性明显更高。生产环境中进行这类操作，建议优先选择官方推荐的账号管理命令。

总之，通过UPDATE语句批量修改mysql.user表的主机限制是可行的，但绝不能只盯着这一张表。操作前备份、操作中精确筛选、操作后同步其他权限表并执行FLUSH PRIVILEGES，这几个环节缺一不可。只有在充分理解MySQL权限模型的前提下，直接修改系统表才不会演变成一次数据库事故。