先明确一个核心事实：在MySQL 8.0里，你找不到一个叫ALTER TABLE ... READ ONLY的语法。这不是什么隐藏功能，也不是被废弃的特性，而是它压根就不存在。如果你照着某些教程去执行，只会立刻收到一个熟悉的错误提示：
ERROR 1064 (42000): You ha ve an error in your SQL syntax...
原因很简单，MySQL的ALTER TABLE命令支持的子句列表里，从来就没有包含过控制表只读的选项。所以，想通过一条DDL语句直接给表上个“只读锁”，这条路从一开始就走不通。
MySQL 8.0 不支持 ALTER TABLE ... READ ONLY
直接说结论：ALTER TABLE 语句在 MySQL 8.0 中**没有 READ ONLY 语法**。你查不到官方文档、执行会报错，也不是被隐藏或废弃的特性——它根本不存在。
常见错误现象：运行类似 ALTER TABLE users READ ONLY = 1 或 ALTER TABLE users SET READ ONLY，MySQL 立即返回：
ERROR 1064 (42000): You ha ve an error in your SQL syntax...
这是因为 MySQL 的 ALTER TABLE 支持的子句里不包含只读控制项。表级只读不是靠 DDL 实现的，而是靠权限、锁或实例级配置间接达成。
真正能“让一张表只读”的可行方式
那么，如果业务上确实需要让某张表“只读”，该怎么办呢？所谓“表只读”，本质就是阻止对它的写入操作。MySQL虽然没有直接的开关，但提供了三条迂回路线，每条路的适用场景和“副作用”都大不相同：
- 会话级表锁：使用
LOCK TABLES t1 READ。这能立刻阻止其他会话写入，但当前会话自己也不能写了。更重要的是，这个锁是会话绑定的，一旦会话断开或执行了UNLOCK TABLES，锁就自动释放了，无法实现持久化的只读状态。 - 精确的权限控制：这是最常用、也最可控的方法。通过
GRANT SELECT ON db.t1 TO 'user'@'%'授予查询权限，同时务必记得用REVOKE INSERT, UPDATE, DELETE, DROP, ALTER ON db.t1 FROM 'user'@'%'收回所有写权限。它的核心逻辑是控制“谁”能写，而不是控制“表”本身。 - 库级只读（MySQL 8.0.22+）：使用
ALTER DATABASE db_name READ ONLY = 1。这个命令威力很大，会对指定数据库下的所有表立即生效。但问题是，它是“库”级别的，无法精确到单张表。
为什么不能像数据库一样给表设 READ ONLY？
你可能会好奇，既然数据库都能设只读，为什么表就不行？这背后是MySQL的设计逻辑。它的READ ONLY机制在设计上就只覆盖了两个层级：
- 实例级：通过
read_only和super_read_only系统变量控制，影响整个MySQL实例。 - 数据库级：从8.0.22版本开始，支持
ALTER DATABASE ... READ ONLY = 1，其状态会写入INFORMATION_SCHEMA.SCHEMATA_EXTENSIONS.OPTIONS。
而表级，无论是InnoDB存储引擎本身，还是MySQL Server层的数据字典，都没有为“是否只读”这个状态预留存储位置或处理钩子。所以，如果你在网上看到声称MySQL支持该语法的文章，很可能是将PostgreSQL或MariaDB的功能张冠李戴了。
容易被忽略的关键点
了解了方法，更关键的是避开实践中的那些“坑”。生产环境里最容易出问题的，往往不是语法，而是对机制理解的偏差：
LOCK TABLES的陷阱：这个锁是会话绑定的。在现代使用连接池的应用中，一个请求锁了表，如果结束后没有显式UNLOCK TABLES，当连接被放回池里给下一个请求使用时，可能导致意想不到的阻塞。- 权限回收不彻底：只执行
GRANT SELECT是远远不够的。如果用户原本拥有UPDATE或ALL PRIVILEGES权限，你必须显式地REVOKE掉。这在迁移老旧账号时特别容易遗漏。 - 库级只读的“威力”：使用
ALTER DATABASE ... READ ONLY = 1后，连ANALYZE TABLE、OPTIMIZE TABLE这类维护操作都会被拒绝。因为它们本质上会修改表的统计信息或重建表，属于“隐式写入”。
说到底，要想稳健地实现表级读写控制，最靠谱的组合拳依然是：基于表的精确权限管理 + 定期审计（SHOW GRANTS FOR）+ 在应用层杜绝动态拼接的写SQL。没有银弹，只有对机制透彻理解后的组合运用。
