MySQL只读从库报ERROR 1290因read_only=ON禁止所有写类操作，UDF执行被内核视为潜在写行为而拦截；需同时关闭read_only与super_read_only，或改用纯计算型UDF、主库注册同步、应用层下沉等安全方案。
MySQL UDF 在只读从库报错：ERROR 1290 (HY000)
因为 MySQL 的只读模式（read_only=ON）会直接禁止所有写入类操作，而 UDF 的执行在内部被归类为「可能修改服务器状态」的行为——哪怕函数本身只做计算、不碰表。这是 MySQL 内核的硬性限制，不是权限配置问题。
常见错误信息是：ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement。注意它没提权限，也没说函数不存在，而是明确指向 --read-only 状态拦截。
- UDF 加载过程本质是动态链接库调用，MySQL 启动时通过
CREATE FUNCTION注册后，每次调用都需进入服务端执行上下文，内核无法静态判断该函数是否真会写数据，所以一律按“潜在写操作”处理 - 即使你把从库的
read_only关了，如果开启了super_read_only=ON（MySQL 5.7+），依然会被拦住；两者必须同时关闭才可能绕过 - 某些 UDF 实现里若调用了
mysql_real_query()或触发了内部 DML（比如日志写入临时表），还会额外触发ERROR 1786 (HY000)：Statement violates GTID consistency
如何让 UDF 在从库安全可用
核心思路不是强行关只读，而是让 UDF 不依赖运行时写行为。有两条实际路径：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 改用纯计算型 UDF：确保 C/C++ 源码中不调用任何 MySQL C API 的执行接口（如
mysql_query）、不访问THD结构体里的会话变量写入口、不 malloc 大内存触发后台分配策略变更 - 把 UDF 提前注册到主库，并开启
log_bin_trust_function_creators=ON，这样主库创建 UDF 的语句才会被写进 binlog，同步到从库后自动加载——但注意：从库上仍不能执行，只是“存在” - 更稳妥的做法是：把 UDF 逻辑下沉到应用层，或改用 MySQL 8.0+ 原生支持的存储函数（
CREATE FUNCTION ... DETERMINISTIC），这类函数在只读实例上可执行，前提是标记了DETERMINISTIC且没副作用
为什么 SET SESSION read_only=OFF 不起作用
因为 read_only 是全局动态变量，SET SESSION 对它完全无效。你看到的提示其实是 MySQL 的明确拒绝，不是权限不足。想临时放开，必须用：
SET GLOBAL read_only = OFF;
但这要求你有 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限，而且一旦主库 binlog 开启，这个操作本身就会被复制过去，导致从库也退出只读——破坏高可用设计前提。
真正需要 UDF 执行能力的场景（比如实时脱敏、字段解密），往往说明架构上已混入了本该由应用承担的逻辑。这时候更该检查的是：这个函数是不是真的非得在 SQL 层跑？它有没有状态依赖？能不能提前预计算？这些比纠结怎么绕过 read_only 更关键。
