应统一使用下划线命名（如user_profile），避免驼峰、连字符等；禁用MySQL保留字作表名；表名长度≤20字符，加业务前缀（如user_）；优先单数形式（如order而非users）。
表名用驼峰还是下划线？直接选下划线
MySQL本身不强制命名风格，但实际协作中必须统一用lower_case_with_underscores。Linux服务器默认开启lower_case_table_names=1，表名会自动转小写；若混用驼峰（如UserOrder），在大小写敏感系统上可能查不到表，或导致Table 'db.UserOrder' doesn't exist这类错误。
下划线分隔还能避免ORM框架（如MyBatis、Django ORM）解析失败——它们默认按snake_case映射字段，驼峰名需额外配置mapUnderscoreToCamelCase=true，一漏就查不到数据。
- 错误：
userProfile、UserInfo - 正确：
user_profile、user_info - 特别注意：连字符
-、点号.、空格都不合法，只能用_
为什么不能用MySQL保留字当表名？
像order、group、key这些词是MySQL语法关键字，直接用作表名会导致ERROR 1064 (42000): You have an error in your SQL syntax。即使加反引号`order`能绕过语法错误，后续维护成本极高：所有SQL里都得带引号，ORM生成语句容易漏，备份恢复时也可能出错。
更隐蔽的问题是，某些云数据库服务（如阿里云PolarDB、AWS RDS）2025年起已内置命名合规检查，检测到order类名称会直接拒绝建表。
- 高危保留字示例：
order、group、index、desc、range - 安全替代方案：
user_order、user_group、search_index - 查保留字列表：执行
SELECT * FROM INFORMATION_SCHEMA.KEYWORDS WHERE RESERVED = 'YES';
表名长度和前缀要不要加？
MySQL单个表名最大64字符，但实际应控制在20字符内。过长的表名（如user_account_transaction_history_log_backup_2023）不仅难读，还会让SHOW CREATE TABLE输出折行，影响自动化脚本解析；外键约束名、索引名也受此限制，容易触发Identifier name 'xxx' is too long错误。
前缀不是可选项，而是模块隔离刚需。比如user_profile和sys_config一眼可知归属，避免不同业务线建出同名表引发冲突。但前缀不能滥用：t_user这种泛化前缀已过时，推荐按职责分： user_（用户域）、biz_（核心业务）、log_（日志）、tmp_（临时表）。
- 允许：
user_address、biz_product_sku、log_login_attempt - 禁止：
t_user（无业务含义）、user1（数字后缀）、user_info_v2（版本号应通过迁移而非改名实现） - 中间关联表统一用
_map后缀：user_role_map，别用user_role_relation
为什么复数表名反而容易出问题？
表面上users比user更“自然”，但实际带来三处隐患：一是ORM映射混乱（Hibernate默认按单数找实体类，users对应User.java却要配@Table(name="users")）；二是字段名歧义（users.name vs user.name，后者语义更稳）；三是团队认知割裂——前端传参常带user_id，后端表却叫users，review时容易忽略外键指向是否准确。
单数命名+清晰上下文才是稳定解：表代表“一类实体的集合”，名字描述这个实体本身（order表示订单这个概念），而不是强调“多条”。只要字段设计合理（order_status、order_amount），没人会误以为它只存一条记录。
- 行业共识：MySQL官方文档示例全用单数（
country、city） - 例外仅限明确集合语义的场景：
enum_values（枚举值集合）、allowed_hosts（白名单主机列表） - 最危险的是混用：
user表配user_addresses表——后者该叫user_address
表名规范真正难的不是记规则，而是每次建表时抵抗“先快速跑通再统一”的惯性。一个tmp_test表没删干净，半年后就成了线上故障的根因。
