mysql函数命名有哪些规范_mysql代码规范说明

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 更可持续。