navicat本身不校验数据库命名规范，新建数据库时仅做语法高亮和发送sql，不拦截非法命名；真正落地需依赖模板sql脚本、环境变量占位符和标准连接共享等外部协同机制。

navicat 本身不强制、也不校验数据库命名规范，统一靠流程+配置+人工协同，不是点几下就能自动生效的事。

Navicat 没有命名规则检查功能

你新建数据库时，Navicat 不会拦截 db@prod、MyDB123 或 test_db_2024 这类名字——只要 MySQL 允许（即符合 identifier 规则），它就让你创建成功。它不提供正则校验、大小写警告、关键字提示或历史命名比对。

常见误判是以为「导出连接」或「环境变量」能约束命名，其实它们只管连接参数替换，和数据库名无关。

• 新建数据库对话框里填的 数据库名 字段，纯字符串输入，无校验
• 执行 CREATE DATABASE SQL 语句时，Navicat 只做语法高亮和发送，不介入语义检查
• 即使你用 Navicat Data Modeler 设计模型，导出的 .ndml 文件也只存逻辑结构，不带命名策略元数据

真正能落地统一命名的三个抓手

靠人盯人不行，得把规范嵌进团队日常操作链路里：

navicatmysql

Navicat For MySQL

下载

• 建库前必走模板 SQL 脚本：在共享代码仓（如 Git）中维护一个 create_db_template.sql，内容固定为：

  CREATE DATABASE <db_name> DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;</db_name>

  要求所有人复制修改 <db_name></db_name> 后执行，而非在 GUI 里手输
• 连接配置里预置常用库名占位符：在 Navicat 「环境变量」中设 DB_NAME=blog_platform，再配合连接「高级」→「MySQL session variables」里加 init_command=USE ${DB_NAME}（注意：这只影响默认库，不改 CREATE 行为）
• 用 Navicat on-prem server 统一发布标准连接：管理员导出已按规范命名的连接（如 prod-blog-platform），并设为只读共享；成员导入后，右键「新建数据库」时自然倾向沿用上下文命名习惯

为什么直接重命名数据库不是好办法

有人想“先随便建，再统一改”，但 RENAME DATABASE 在 MySQL 5.7+ 已被移除，Navicat 的「重命名数据库」功能本质是执行：

DROP DATABASE old_name;<br>CREATE DATABASE new_name;

这会导致：

• 所有依赖该库的账号权限丢失（GRANT 需重配）
• 视图、存储过程里的 old_name.table 引用全部失效
• 应用连接池缓存的库名未更新，报 Unknown database
• Navicat 自己的查询历史、代码段、模型文件里硬编码的库名全要手动搜改

所以命名必须在 CREATE 那一刻定下来，事后补救成本远高于事前卡点。

最易被忽略的是：命名规范一旦写进 CI/CD 流程（比如部署脚本校验 CREATE DATABASE 语句中的库名是否匹配正则 ^[a-z][a-z0-9_]{2,31}$），Navicat 就只是个执行终端，真正的约束力来自外部工具链。