数据库迁移加外键需先确认主键类型、字符集、存储引擎一致，InnoDB支持而MyISAM不支持；被引用列须有索引，字段类型须严格匹配（如INT与UNSIGNED INT不兼容）；应显式指定ON DELETE行为，避免默认风险，并检查外键命名防重复。
数据库迁移里怎么加外键约束
加外键不是写个 alter table 就完事，得先确认被引用表的主键类型、字符集、存储引擎是否一致。mysql 里 innodb 支持外键，myisam 不支持——很多线上库混用引擎，一加就报错 error 1215 (hy000): cannot add foreign key constraint。
实操建议：
- 先查两边字段类型是否严格一致：
DESCRIBE table_a和DESCRIBE table_b，注意INT和UNSIGNED INT算不兼容 - 被引用列必须有索引（通常是主键或唯一索引），否则加外键会失败
- 建外键时显式指定
ON DELETE CASCADE或ON DELETE RESTRICT，别依赖默认行为，协作中有人删父记录却没意识到子表联动风险 - 用
SHOW CREATE TABLE table_name检查已有外键命名，避免迁移脚本里重复定义同名约束导致执行失败
共享图纸的元数据怎么和数据库版本对齐
图纸文件（比如 .dwg、.skp）本身不带 Git 友好结构，直接丢进仓库会导致 diff 失效、合并冲突无法解决。真正能版本控制的是它的元数据：项目编号、关联设备表 ID、审批状态、修订人——这些必须存在数据库里，且和图纸文件名/哈希值绑定。
实操建议：
- 上传图纸时自动生成唯一标识，比如用
sha256(file_content)当作file_hash字段存入drawings表 - 在
drawings表里加version_tag字段，值来自 Git commit hash 或语义化版本号（如v2.1.0），每次发布新图纸就插一条带新 tag 的记录 - 禁止把图纸二进制内容塞进数据库 BLOB 字段——查起来慢、备份膨胀、Git 无法跟踪变更
- CI 流水线里加一步校验：
git diff HEAD~1 -- metadata/drawings.yaml若有变更，自动更新对应drawings表记录
多人同时改一张图纸的关联配置时怎么防覆盖
问题不在图纸本身，而在它关联的配置项——比如一张配电柜图纸，A 改了接线端子映射，B 改了保护定值表，两人提交的 drawing_config JSON 字段若无结构化设计，merge 后大概率只剩一方改动。
实操建议：
- 把大块配置拆成独立表，例如
drawing_terminals、drawing_protections，每张图纸用drawing_id关联，避免单字段存整个 JSON - 关键配置表加
updated_at+updated_by，应用层写入前查最新时间戳，冲突时拒绝非最新版本的 UPDATE（乐观锁） - 前端编辑器保存时传
revision_number，后端比对数据库当前值，不一致就返回409 Conflict并附上当前最新配置供拉取 - 不要用 ORM 的“全量更新”方法（如 Django 的
save()默认行为），明确只更新变化字段
上线后怎么验证关联关系没被误删或绕过
开发阶段加的外键、触发器、视图，在部署到生产环境后可能因权限限制、SQL_MODE 差异或运维手动操作而失效。最常见的是 DBA 为提速临时禁用外键检查：SET FOREIGN_KEY_CHECKS = 0，之后忘了开回来。
实操建议：
- 每周定时跑校验脚本，查
information_schema.KEY_COLUMN_USAGE确认外键是否存在，再用SELECT COUNT(*) FROM child_table WHERE parent_id NOT IN (SELECT id FROM parent_table)扫异常数据 - 在监控系统里埋点：每次 INSERT/UPDATE 涉及关联字段时，记录是否触发了预期的约束或触发器（可通过
SHOW ENGINE INNODB STATUS中的死锁/约束失败日志反推） - 上线 checklist 必须包含：“检查目标库
FOREIGN_KEY_CHECKS值是否为 1”，不能只信本地开发环境 - 所有绕过约束的操作（如修复脏数据）必须走带审批的 SQL 工单，且执行后立即补校验，而不是“先跑再说”
关联关系不是加完外键就一劳永逸的事，它活在代码、SQL、权限、流程和人习惯的交界处。最容易漏掉的是跨环境一致性——开发库有外键，测试库关了，生产库又因为历史原因没加，这种断层往往要等出问题才暴露。
