MySQL自定义函数名应全小写、下划线分隔、见名知意、避开保留字，并与表/字段命名风格统一；需注意作用域、调用上下文及上线后改名的高成本。
MySQL 本身没有用户可定义的函数命名规范强制约束，但实际开发中，为避免冲突、提升可维护性、适配 ORM 或运维工具，必须遵循一套隐性但强效的命名约定。直接说结论：自定义函数名应和表/字段/索引一样，全小写 + 下划线分隔 + 见名知意 + 避开保留字，且需额外注意函数作用域与调用上下文。
MySQL 自定义函数名必须全小写 + 下划线
Linux 环境下 MySQL 默认对函数名大小写敏感（依赖 lower_case_table_names 设置），而绝大多数生产环境设为 1（即强制转小写存储）。若你写 CREATE FUNCTION GetUserName()，MySQL 会存成 getusername，后续调用 SELECT GetUserName(...) 可能报错或行为不一致。
所以统一用小写+下划线，既是兼容性底线，也是团队协作前提：
CREATE FUNCTION user_full_name(user_id INT) RETURNS VARCHAR(100) READS SQL DATA DETERMINISTIC BEGIN RETURN (SELECT CONCAT(first_name, ' ', last_name) FROM users WHERE id = user_id); END;
✅ 正确：user_full_name
❌ 危险：UserFullName、get_user_name（虽语法通过，但和索引/字段风格割裂，易被误认为是 ORM 方法）
别碰 MySQL 保留字，哪怕加了反引号也不推荐
像 order、group、rank、match 这些词，即使你用反引号包起来能创建成功（`rank`），但在跨语言调用（如 Python 的 SQLAlchemy、Java 的 MyBatis）或导出为 DDL 脚本时，极易引发解析失败或静默错误。
- ❌ 避免：
CREATE FUNCTION rank_by_score(...)→rank是保留字，即便没报错，SQL 解析器可能歧义 - ✅ 替代：
user_rank_by_score、score_ranking（加业务前缀或换词） - 查保留字清单用：
SELECT * FROM INFORMATION_SCHEMA.KEYWORDS WHERE RESERVED = 1;
函数名要体现“做什么”，而不是“怎么做的”
MySQL 函数不是过程式脚本，它会被嵌入到 SELECT、WHERE 甚至触发器中。名字必须让调用者一眼明白语义，否则极易误用或重复造轮子。
- ❌ 模糊：
calc_val、do_something—— 完全无法判断输入输出和副作用 - ✅ 清晰：
format_phone_cn（格式化中国手机号）、is_valid_email（校验邮箱格式）、days_since_last_login（返回距上次登录天数） - ⚠️ 注意：
is_前缀仅用于返回BOOLEAN/TINYINT(1)的函数；若返回字符串或数字，别硬套，比如is_user_active合理，is_user_name就很怪
和表/字段命名保持同一套语义体系
一个项目里如果表叫 t_user_basic、字段叫 create_time、索引叫 idx_user_status，结果函数却叫 GetUserCreationDate()，这种混搭会让新人完全失去命名线索，也阻碍自动化工具识别（比如 DBA 工具扫描所有 user_* 对象）。
- 统一前缀示例：
– 用户相关：user_is_vip、user_total_orders、user_avatar_url
– 订单相关：order_is_paid、order_amount_with_tax - 字段名和函数名语义对齐：
若字段是status（TINYINT），对应函数就该是user_status_label而非getUserStatusText - 禁止缩写歧义：
usr_name_len不如user_name_length明确（usr可能被读作 “user” 或 “usurper”）
真正容易被忽略的是：函数名一旦上线，改名成本极高——不只是改函数定义，还要全局搜索所有 SQL、视图、存储过程、应用代码里的调用点。所以第一次命名就得想清楚边界：它只处理单行？是否允许 NULL 输入？是否依赖特定时区或变量？这些都该在名字里留出可扩展空间，比如 user_name_normalized 比 user_name_trim 更可持续。
