问题标签 [mysql-error-1071]

我有一个MySQL包含 3 个字段的表，我想在其中两个字段之间强制执行唯一性。这是表格DDL：

该ID字段是代理键（此表正在加载 ETL）。这CLIENT_NAME是一个包含客户名称的字段 这OWNER_ID是一个 id 表示客户所有者。

CLIENT_NAME我以为我可以在and上使用唯一索引来强制执行此操作OWNER_ID，

但 MySQL 给了我一个错误：

执行 SQL 命令更新表时出错。指定的密钥太长；最大密钥长度为 765 字节（错误 1071）

其他人有什么想法吗？

当我执行以下命令时：

我收到此错误消息：

关于 column1 和 column2 的信息：

我认为varchar(20)只需要 21 个字节，而varchar(500)只需要 501 个字节。所以总字节数为 522，小于 767。那为什么我会收到错误消息？

我改成300，250没关系。但我不太明白。

原因

我该怎么办？

这是我的数据库编码：

在我将字符集从 latin1 更改为 utf8 之后，我试图导入我的备份，现在在我的导入过程中，我在第 2137 行收到了这个错误 ERROR 1071 (42000): Specified key is too long; 最大密钥长度为 1000 字节尝试更改 my.cnf 并将所有字符集和连接设置为 utf8，但现在幸运，我不想回到 latin1，我知道这会解决问题，但 utf8 我的监狱有什么线索吗？我知道拉丁语 1 字节 = 1 char 和 utf8 3 字节 = 1 ..

我有一个完整的操作语言环境 django 应用程序，但是在迁移到 site5 服务器时遇到了麻烦。

当我启动 django 的syncdb命令时，我的所有模型的表都被创建了，但是（我猜它是在创建关系表时），我得到了以下错误：

当我要求 django 同步语言环境数据库时，我没有任何问题，这个错误只发生在服务器中......

任何想法？

这是我第一次真正地用第三范式创建数据库。我成功地创建了 DDL 脚本（在我继续构建脚本之前，我已经将逻辑模型验证为 3NF），但是我遇到了很多我不确定修复的错误。对于这个特殊情况，我可能咬得比我能咀嚼的更多，但我不想放弃——这对我来说是一个很大的学习曲线，在一些帮助下，我可以克服这个并继续前进。

首先，这是我的 DDL 脚本：

这是我的 DML 脚本（注意：到目前为止，该脚本仅尝试在“人”、“学校”和“玩家”详细信息中插入记录。如果我到目前为止遇到的问题得到解决，这可以帮助我稍后的..）：

这是两个脚本生成的 MySQL 命令行界面的输出 - 将显示有关错误的更多信息：

这是逻辑模型（如果有人发现任何关系存在问题 - 特别是多：多关系，请告诉我）。

如果我提供了太多信息，我深表歉意，但我认为如果我提供了所有这些信息，它会让想要帮助我的人变得更容易。我花了 3 个小时对 DDL 脚本进行调整，但花了这么长时间后，我意识到我需要有更多经验的人来帮助我。我已经向具有数据库行业经验的人展示了这个逻辑模型，他们认为它符合 3NF。做概念模型和逻辑模型对我来说并不是那么糟糕，它试图将逻辑模型转换为工作脚本并成功插入数据（我想为每个表插入至少 10 条记录），这已成为最大的障碍。

提前致谢！

我正在使用 mysql 5.0.91，我需要保存 URL（有些很小，有些很长）。我想使用varchar(2000)，但出现错误：

#1071 - 指定的密钥太长；最大密钥长度为 1000 字节

使用 mysql 5.0.91 在我的主机上保存 URL 的最佳方法是什么？

我正在创建一个索引大量测量值的表，分布在各种文件中。在不同的表中，对于不同类型的数据，我使用数据文件的绝对路径作为唯一索引。这工作得很好。

但是，当我现在尝试在新表中重现该设置时，我得到

mysql> alter table weights 改变列路径 path varchar(1000); ERROR 1071 (42000)：指定的密钥太长；最大密钥长度为 767 字节

这很奇怪，因为我的另一个表中的同一列的特征是：

那么，我上次是如何绕过这个限制的呢？我应该告诉我自从创建第一个表以来我已经重新安装了 linux (& mySQL)，所以很可能在我不知情的情况下更改了一些默认值。

当我启动 mySQL 时，欢迎消息是：

当我搜索以前的答案时，一般的反应似乎是“嗯，就是这样”，但显然不是？

先感谢您 ：）

在服务器 1 上转储 mysql 数据库

在服务器 2 上导入

我知道关于这个错误有很多问题和答案，但它仍然让我感到困惑。

会不会是版本问题？我怀疑没有。

如果我使用 --force 选项运行它，它会变得更加奇怪：

到底是怎么回事？

我的意思是除了解决这个问题之外，我还想了解哪些设置会影响简单的转储导入操作，以及为什么这些设置不能在我的转储文件中明确显示并设置为导入。

我更喜欢不必调试实际错误，这必须在高层次上解决。

更新：解决方案，弗雷德里克为我指出了正确的方向。基本上我的转储试图用 INNODB 引擎设置 db，但是服务器 2 上的 mysql 在 /etc/my.cnf

通过简单地删除此选项并重新启动 mysqld，我的导入运行没有呱呱叫。我很伤心这样一个简单的事情，比如一个不可用的引擎不值得警告或错误，而不是因为默默地退回到 myISAM 而导致的密钥长度问题。唔。那么是时候切换到 posgresql 了吗？蒙哥？:)