15

我们所做的每件事都有一个驼峰命名约定——从数据库表到对象属性、列、数据库索引和约束。

我们已经在一个新项目上使用这些约定两个月了，一切进展顺利，但昨晚突然之间，我们 6 个数据库中只有一个的所有关系都从驼峰式转换为小写。重要的是要注意只有约束转换 - 索引本身保持驼峰式。

因此，如果我们有一个名为 someColumn 的列和另一个名为 someTable.otherColumn 的列，它来自以下内容：

someColumn => someTable.otherColumn ON DELETE CASCADE ON UPDATE CASCADE

对此：

someColumn => sometable.otherColumn ON DELETE CASCADE ON UPDATE CASCADE

什么可能导致这种情况？我们无法重现此问题 - 我们尝试更改随机约束以查看它是否会全部更改，然后我们尝试重新导入结构并且一切正常，从而阻止导入 camelCase。

我们在 OSX 上工作并部署到 CentOS。

编辑：一位开发人员使用不区分大小写的 OSX。他尝试从他自己机器上的导出中重新导入数据库，但仍然没问题，因此：将转储从不区分大小写的机器导入到区分大小写的 CentOS 中并没有破坏事情。重新启动 mysqld 也未能重现此错误。所有强制小写 mysql 设置均已关闭。迄今为止，我们一直无法让它再次发生。

Edit2：请注意，这只发生在我们的 CentOS 开发服务器上 - 使用不区分大小写操作系统的开发人员之前已经从其他区分大小写的系统上导入了他的数据库，并且每次都一切正常。

4

2 回答 2

6

错误报告 #55897表明这是设计使然，并记录在限制InnoDB表下：

在 Windows 上，InnoDB始终在内部以小写形式存储数据库和表名。

另请参阅MySQL 中不区分大小写的约束名称。

于 2012-09-15T11:48:49.980 回答
4

您需要在 OSX 服务器的 my.cnf 上检查 MySQL 中的两个变量

根据关于lower_case_table_names的 MySQL 文档

如果您在具有不区分大小写文件名的系统（例如 Windows 或 Mac OS X）上运行 MySQL，则不应将此变量设置为 0。如果在这样的系统上将此变量设置为 0 并使用不同的字母大小写访问 MyISAM 表名，则可能会导致索引损坏。在 Windows 上，默认值为 1。在 Mac OS X 上，默认值为 2。

尽管上面的摘录是指 MyISAM，但lower_case_table_names在 OSX中默认值为 鉴于此，如果您有lower_case_table_names=0或lower_case_table_names=1在您的 OSX 的 my.cnf 中，mysqld 可能会有点困惑。

因此，如果任何来自 OSX 服务器的 mysqldumps 移入 CentOS 并没有改变这种情况，请不要感到惊讶。

这很可能是你现在正在与之抗争的东西。

于 2012-09-28T21:13:43.943 回答