可以限制为只读，但前提非常明确：目标 MySQL 用户不能残留任何其他写入权限。具体做法是，先通过SHOW GRANTS核查当前权限，再显式使用REVOKE回收所有写操作相关权限，以及GRANT OPTION、SUPER这类高风险权限。同时，还需要收紧库级SELECT授权范围，并限制可登录的主机IP段。完成这些设置后，建议使用新连接重新验证，确认执行INSERT等写入语句会报错，并且SHOW GRANTS结果中仅保留SELECT相关权限。
只授 SELECT 权限就能实现只读吗
可以实现，但有一个关键前提：用户**不能保留任何其他写权限**。MySQL 权限机制属于“显式授予”，并不是“默认拒绝”——GRANT SELECT 只是新增权限，不会自动移除已有权限。如果该用户之前拿到过 ALL PRIVILEGES，或者继承了某个角色（例如 mysql.backup），那么即使现在只执行 GRANT SELECT，他依然可能执行 UPDATE、DROP，甚至继续把权限 GRANT 给其他账号。
因此必须先确认当前权限状态：SHOW GRANTS FOR 'user'@'host';
重点检查输出中是否存在 INSERT、UPDATE、DELETE、DROP、ALTER、LOCK TABLES、TRUNCATE、GRANT OPTION 等权限。只要还保留其中任意一项，就不能称为真正的只读用户。
- 新建 MySQL 只读用户时，建议严格分两步执行：
CREATE USER→GRANT SELECT ON db_name.*，不要混写在一起 - 针对已有用户，必须显式回收权限：
REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, INDEX, LOCK TABLES, EXECUTE, TRIGGER, GRANT OPTION ON db_name.* FROM 'user'@'host'; - 全局权限（例如
REVOKE ALL PRIVILEGES ON *.*）需要单独清理，因为库级REVOKE并不会覆盖全局授权
GRANT SELECT 的作用范围怎么选才安全
授权范围过大容易暴露系统信息，范围过小又会增加维护成本、导致漏授。实际生产环境中，最常见也最推荐的是库级授权：GRANT SELECT ON `myapp_prod`.* TO 'ro_user'@'192.168.10.%';。这种做法比 *.* 更安全，也比逐表授权更容易维护。
应当坚决避免：GRANT SELECT ON *.* —— 这会让用户访问到 mysql.user（包含密码哈希）、performance_schema（包含 SQL 执行细节）、sys（包含敏感诊断视图）等系统级信息。
- 如果业务场景只需要读取单张表（例如日志归档表），可以采用表级授权：
GRANT SELECT ON `logdb`.`events_202408`，但要同时检查分区表其他分区、临时表以及物化视图依赖表是否会被间接访问 - 如果是跨多个数据库的只读需求，应逐库授权：
GRANT SELECT ON `sales`.*、GRANT SELECT ON `reports`.*，不要尝试使用通配符匹配库名 - 主机来源不要直接写成
'%'，生产环境至少应限制为内网网段，例如'10.20.30.%'
为什么用户还能执行 SHOW CREATE TABLE 或查表结构
原因在于，这类操作并不属于“查询业务数据”，而是访问元数据，默认情况下并不完全受 SELECT 数据权限限制。只要用户对某张表拥有 SELECT 权限，就可能通过 INFORMATION_SCHEMA.TABLES、COLUMNS 等系统表推断数据库中的表名、字段名和部分结构信息。
如果希望进一步限制表结构和元数据访问，需要单独处理相关权限：
- MySQL 8.0.12+ 支持：
REVOKE SELECT ON `INFORMATION_SCHEMA`.* FROM 'user'@'host'; - 如果必须保留部分元数据访问能力（例如让 BI 工具自动识别字段），可以采用精细授权：
GRANT SELECT ON `INFORMATION_SCHEMA`.`COLUMNS` TO 'user'@'host';，但不要授予TABLES或VIEWS SHOW CREATE TABLE通常需要SELECT+ 对应对象的SHOW VIEW权限（针对视图）或SELECT（针对普通表），但底层本质上仍与INFORMATION_SCHEMA的元数据访问有关
列级 SELECT 权限到底能不能防住敏感字段
不能把它当成真正的安全边界，更适合作为一种轻量级提示或访问约束。MySQL 的列级权限检查，只校验 SQL 中**直接写出的字段名**，并不能完全拦截 JOIN、子查询、函数计算等间接访问路径。
例如即使只授予了 SELECT(id, name)，下面这些方式仍可能造成绕过：
SELECT u1.id, u2.phone FROM users u1 JOIN users u2 ON u1.id = u2.id;（只要对users具备任意列的SELECT权限，JOIN 可能暴露未授权字段）SELECT id, (SELECT phone FROM users LIMIT 1) FROM users LIMIT 1;（子查询会独立做权限校验，只要子查询中的字段在可访问范围内，就可能被放行）- 字段名如果包含特殊字符（例如
user-id），必须使用反引号：GRANT SELECT(`user-id`, `full name`) ON db.table，若直接写成user-id会报语法错误
如果确实要隔离敏感字段，创建视图才是更稳妥、更可靠的方案：CREATE VIEW safe_users AS SELECT id, name FROM users;，然后再 GRANT SELECT ON safe_users。视图的定义受定义者权限控制，调用者通常无法直接穿透到底层敏感列。
