phpEnv下CREATE FUNCTION失败主因是log_bin_trust_function_creators未启用且用户缺SUPER权限；须修改my.ini添加log_bin_trust_function_creators=1，以管理员身份net stop/start MySQL服务，并在函数定义中显式声明DETERMINISTIC等修饰符。
phpEnv 是 Windows 下的轻量级 PHP+MySQL 开发环境套件，它默认使用 MySQL 5.7 或 8.0（取决于版本），但**不默认开启自定义函数（SQL FUNCTION）创建权限**。直接执行 CREATE FUNCTION 会报错 ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration 或更常见的 ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER privilege(s) for this operation —— 这不是你没写对语法，而是 phpEnv 启动的 MySQL 实例默认禁用了该功能。
为什么 phpEnv 下 CREATE FUNCTION 总是失败
phpEnv 自带的 MySQL 配置（my.ini）通常未设置 log_bin_trust_function_creators=1，且启用了二进制日志（log-bin）。MySQL 在启用 binlog 时，为保证主从复制一致性，强制要求：任何自定义函数必须显式声明确定性（DETERMINISTIC）、无副作用（NO SQL）或只读（READS SQL DATA），同时还要有 SUPER 权限 —— 而 phpEnv 默认用户（如 root@localhost）往往没有该权限，且配置未放行。
- 错误现象不止是权限拒绝，还常混杂
ERROR 1418和ERROR 1227交替出现，本质是“配置锁死 + 权限缺失”双重拦截 - 即使你加了
DETERMINISTIC，没开log_bin_trust_function_creators，照样被拒 - phpEnv 的 MySQL 服务是通过 Windows 服务方式运行的，改配置后必须重启服务，仅重启 phpEnv 控制面板不生效
修改 my.ini 并重启 MySQL 服务（唯一可靠方式）
不要尝试用 SET GLOBAL log_bin_trust_function_creators = 1 临时设置 —— phpEnv 的 MySQL 服务在启动时若检测到 binlog 开启但该参数未配置，会在初始化阶段直接忽略该 SET 命令，导致设置无效。
- 找到 phpEnv 安装目录下的
mysql\my.ini（例如：C:\phpEnv\mysql\my.ini） - 在
[mysqld]段落下添加一行：log_bin_trust_function_creators=1 - 保存文件，**以管理员身份打开命令提示符**，执行：
net stop mysql→net start mysql（注意服务名可能为mysql57或类似，可用sc queryex type= service state= all | findstr mysql查看真实服务名） - 登录 MySQL 验证：
SELECT @@log_bin_trust_function_creators;返回1即生效
CREATE FUNCTION 语句必须带 DETERMINISTIC 或等效修饰符
即使权限和配置都 OK，MySQL 仍会校验函数声明。phpEnv 下的 MySQL 对此检查严格，漏写或写错修饰符都会触发 ERROR 1418。
立即学习“PHP免费学习笔记（深入）”；
- 如果你的函数不查表、不调用随机/时间函数、纯计算逻辑（如字符串处理、数值转换），就用
DETERMINISTIC - 如果函数只读数据（如
SELECT ... FROM xxx），必须写READS SQL DATA；若还修改数据，则需MODIFIES SQL DATA（但函数内禁止写操作，实际应改用存储过程） -
NO SQL仅适用于完全不碰数据库的函数（极少见） - 示例（安全写法）：
DELIMITER $$ CREATE FUNCTION format_phone(n VARCHAR(20)) RETURNS VARCHAR(20) DETERMINISTIC BEGIN RETURN CONCAT('(', LEFT(n,3), ') ', MID(n,4,4), '-', RIGHT(n,4)); END$$ DELIMITER ;
函数调用后返回 NULL？检查参数类型与隐式转换
phpEnv 下 MySQL 对参数类型校验较敏感，尤其当传入 NULL 或类型不匹配时，函数体未做防御处理，容易静默返回 NULL，而不是报错。
- 在函数开头加判断：
IF param IS NULL THEN RETURN ''; END IF; - 避免依赖隐式转换：比如把
VARCHAR参数直接用于数值运算，应显式CAST(param AS SIGNED) - 调试技巧：在函数体中用
SELECT无法输出，可改用写日志表（需MODIFIES SQL DATA）或先在外部用SELECT模拟逻辑验证 - 注意 phpEnv 默认字符集多为
gbk或utf8mb3，若函数内处理中文，确保参数声明含CHARACTER SET utf8mb4
真正卡住人的地方不在语法，而在 phpEnv 的 MySQL 服务启动时对 binlog 和函数安全策略的强耦合 —— 改完 my.ini 忘记用 net stop/start 重启服务，或者服务名没找对，就会一直原地打转。别信“重启 phpEnv 就行”，那只是重启了控制面板，MySQL 进程根本没 reload 配置。
