生产环境建表必须人工审核DDL，重点检查ENGINE、CHARSET、ROW_FORMAT等关键项是否缺失，严控MyISAM、utf8mb4缺失、DATETIME默认时间戳等高危语法，并核验字段类型兼容性、外键索引前提、注释规范及云数据库限制。
直接看 DDL 是否含高危语法
生产环境建表语句必须人工过一遍 show create table 输出，不能只信 navicat 的「生成创建脚本」或「对象信息 → ddl」——后者可能省略 engine、charset、row_format 等关键项，而这些恰恰影响性能与兼容性。
重点盯三类问题：
• engine=myisam：生产库若强制要求 innodb（如需事务、外键、崩溃恢复），这条语句必须拒掉
• 缺少 charset=utf8mb4 或 collate=utf8mb4_unicode_ci：中文、emoji 存储会出乱码，且 mysql 8.0 默认已切换，不显式声明易被忽略
• default current_timestamp on update current_timestamp 在 datetime 字段上：mysql 5.6+ 允许，但某些云 rds（如早期腾讯云 cdb）会报错，得换成 timestamp 或去掉 on update
字段类型是否踩了生产库版本的坑
开发用 MySQL 8.0 写了 JSON 字段，生产还是 5.7？别等上线才爆 ERROR 1064。审核时必须查清两边版本：
• 在生产库执行 SELECT VERSION();，对照MySQL 5.7 官方文档确认支持类型
• 常见陷阱：
– BOOLEAN 实际是 TINYINT(1) 别名，但 Navicat 比对会标为不一致，需确认是否真要改类型
– VARCHAR(255) 在 utf8mb4 下实际占 1020 字节，超索引长度限制（767 字节），建索引前得缩到 VARCHAR(191)
– TEXT 字段加索引必须指定前缀长度，比如 INDEX idx_content (content(255))，否则建表失败
外键和索引是否具备执行条件
DDL 脚本在开发库跑通，不代表能在生产执行成功。审核时必须验证依赖前提：
• 外键字段是否已在父表建好索引？执行 SHOW INDEX FROM parent_table WHERE Column_name = 'id';，没结果就先补索引
• 新增索引是否针对大表？若 user 表超 100 万行，CREATE INDEX 会锁表（MySQL 5.7 默认），必须改成 ALGORITHM=INPLACE, LOCK=NONE（仅 8.0+ 支持）或安排夜间窗口
• 云数据库（如阿里云 RDS）是否禁用外键？检查 SELECT @@FOREIGN_KEY_CHECKS;，若为 0，语句里得显式加 SET FOREIGN_KEY_CHECKS=1;，且注意该设置不跨会话持久化
注释和权限是否符合安全规范
字段注释不是可有可无的装饰：
• 注释长度超 1024 字符会被 Navicat 截断且不提示，生产库字段描述缺失会影响后续审计或低代码平台解析
• 敏感字段（如 id_card、phone）必须带注释标明脱敏规则，例如 COMMENT 'AES-256 加密存储，前端展示前 3 后 4'
• 表级注释要体现业务归属，比如 COMMENT '用户中心-实名认证主表，由 auth-service 维护'，避免 DBA 不敢动、开发不敢删
• 最后核对：Navicat 导出 SQL 时是否勾选了「包括注释」？默认不包含，漏勾等于白写
ENGINE、CHARSET、索引锁表、外键依赖这些“看起来没问题”的细节。审核不是走流程，是提前把生产库的约束条件翻译成 DDL 里的显式声明。
