MySQL 是关系型数据库，本身不支持面向对象的封装、继承、多态，所以不能也不该通过字段命名来“体现 OOP”。强行用命名模拟类/属性/方法（比如
user_name_str、
order_create_datetime_utc、
product_getPrice()）反而破坏 SQL 的简洁性、可读性和可维护性。
为什么字段名不该模仿 OOP 概念
数据库设计目标是准确、无歧义地表达业务实体与关系，不是复刻应用层逻辑。OOP 中的“方法”“getter/setter”“继承链”在 SQL 里没有对应语义，硬套会导致：
user_profile_getAvatarUrl()这类名字无法被 MySQL 解析，只能作为字符串存进
COMMENT，但查询、索引、ORM 映射时完全无效 带类型后缀如
is_active_flag或
created_at_timestamp属于冗余信息——字段类型和约束已在
CREATE TABLE中明确定义，重复表达违反 DRY 原则 层级化命名如
customer_address_street_line1看似“结构清晰”，实则让 JOIN 和 GROUP BY 变得笨重，且掩盖了本应建模为独立表的实体（比如
address表）
真正有效的字段命名原则（兼顾清晰性与一致性）
好的命名服务于人（开发、DBA、产品）和机器（SQL 引擎、ORM、BI 工具），核心是：**见名知义、上下文自洽、无歧义、易拼写**。
用小写 + 下划线分隔（snake_case），如
order_status、
payment_method_id—— 兼容所有 MySQL 版本，避免大小写敏感问题 主键统一用
id，外键用
{table}_id，如 user_id、
category_id—— ORM（Django、Laravel Eloquent、SQLAlchemy）默认识别此约定 布尔字段用
is_或
has_前缀，值为
TINYINT(1)或
BOOLEAN，如
is_deleted、
has_discount—— 避免用
status字段枚举真假（易误判、难索引） 时间字段统一用
created_at/
updated_at/
deleted_at—— 不加
_utc或
_local后缀，时区信息应由应用层或连接配置（
time_zone='+00:00'）控制
哪些命名方式实际踩过坑
这些常见做法看似“规范”，但在协作和演进中暴露明显缺陷：
tbl_user、
fld_name等带类型前缀：表名已由
CREATE TABLE定义，
fld_对 SQL 解析器毫无意义，只增加输入负担
user_name_en、
user_name_zh多语言字段：应拆分为关联表
user_localization（
user_id,
locale,
name），否则新增语言要反复 ALTER TABLE
config_value_json存整个对象：失去字段级索引、校验、变更追踪能力；应拆为原子字段，或用 JSON 类型（MySQL 5.7+）+
JSON_VALID()检查，而非模糊命名
CREATE TABLE `order` (
`id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
`user_id` BIGINT UNSIGNED NOT NULL,
`status` ENUM('pending', 'paid', 'shipped', 'cancelled') NOT NULL DEFAULT 'pending',
`is_paid` TINYINT(1) NOT NULL DEFAULT 0,
`total_amount_cents` INT NOT NULL CHECK (`total_amount_cents` >= 0),
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
INDEX `idx_user_id` (`user_id`),
INDEX `idx_status_created` (`status`, `created_at`)
) ENGINE=InnoDB;
最常被忽略的一点：命名规范必须配合
COMMENT使用。比如
total_amount_cents比
amount更精确，但它的单位和精度仍需注释说明——否则半年后没人记得为什么不用
DECIMAL(10,2)。
