若MySQL新增与自定义UDF同名的原生函数，会出现什么情况？

首先直接给你结论：如果未来MySQL推出原生的sha3()函数，你的自定义UDF会被原生函数优先覆盖，这可能带来兼容性风险，但也有明确的规避方法。

冲突发生时的具体表现 #

• 函数优先级规则：MySQL会优先调用内置的原生函数，而非用户自定义UDF。也就是说，一旦原生sha3()上线，所有直接写sha3()的查询都会自动切换到原生实现，你的自定义UDF会被“隐藏”——除非你调用时明确指定UDF所在的数据库/库名前缀（比如your_db.sha3()，如果你的UDF注册在这个库下），但大多数场景下大家不会这么写，所以你的自定义实现会直接失效。
• 兼容性风险：更关键的是，如果原生sha3()和你的自定义实现存在差异（比如支持的哈希位数、参数顺序、输出的大小写/格式），现有依赖自定义sha3()的查询会突然返回不同结果，可能导致数据校验失败、业务逻辑混乱，甚至数据不一致的问题。

如何提前规避这类冲突 #

最稳妥的方式就是给自定义UDF起一个独特的、非通用的名字，比如sha3_custom()、app_sha3()或者结合你的业务前缀命名。这样不管MySQL未来新增什么原生函数，都不会和你的UDF重名。

另外，如果你坚持想用sha3这个名字，也可以把UDF注册到专门存放自定义函数的数据库中，调用时加上数据库前缀（比如custom_udfs.sha3()），但这种方式会增加查询复杂度，不如直接改名来得省心。

关于MySQL SHA-3 UDF的分享 #

如果有其他开发者需要在MySQL中实现SHA-3哈希支持，我已经编写了一个可用的自定义UDF。这里给大家提几个使用注意事项：

• 编译安装时请严格遵循MySQL的UDF开发规范，确保权限设置正确，避免安全风险；
• 建议直接给它起一个非通用的名字，避免未来和原生函数冲突；
• 测试时请和PHP的sha3实现做对齐验证，确保跨语言的哈希结果一致（比如验证相同输入下，MySQL UDF和PHP输出的哈希值完全匹配）。

内容的提问来源于stack exchange，提问作者Brian Leishman