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

来源：这里教程网时间：2026-02-28 20:41:58 作者：

MySQL 本身没有用户可定义的函数命名规范强制约束，但实际开发中，为避免冲突、提升可维护性、适配 ORM 或运维工具，必须遵循一套隐性但强效的命名约定。直接说结论：自定义函数名应和表/字段/索引一样，全小写 + 下划线分隔 + 见名知意 + 避开保留字，且需额外注意函数作用域与调用上下文。

MySQL 自定义函数名必须全小写 + 下划线

Linux 环境下 MySQL 默认对函数名大小写敏感（依赖

lower_case_table_names

设置），而绝大多数生产环境设为

（即强制转小写存储）。若你写

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 输入？是否依赖特定时区或变量？这些都该在名字里留出可扩展空间，比如