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

我使用此SQL查询创建表：

CREATE TABLE IF NOT EXISTS `local_sysDB`.`hashtags` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `hashtag` VARCHAR(255) NOT NULL COMMENT 'hashtag must be unique. Must be saved without #',
  `accountId` INT NULL,
  `startTracking` DATETIME NOT NULL COMMENT 'When tracking of the hashtag start',
  `endTracking` DATETIME NOT NULL COMMENT 'When tracking of the hashtag ends',
  `channelInstagram` TINYINT(1) NOT NULL DEFAULT 1,
  `channelTwitter` TINYINT(1) NOT NULL DEFAULT 1,
  `channelYoutube` TINYINT(1) NOT NULL DEFAULT 1,
  `postLimit` INT NOT NULL,
  `suspendOnLimit` TINYINT(1) NOT NULL DEFAULT 1,
  `created` TIMESTAMP NOT NULL DEFAULT NOW(),
  `updated` TIMESTAMP NULL ON UPDATE CURRENT_TIMESTAMP,
  `approveBeforeView` TINYINT(1) NOT NULL DEFAULT 0 COMMENT 'If account should approve posts before being displayed public',
  `suspended` TINYINT(1) NOT NULL DEFAULT 0,
  `InstagramSubscriptionId` INT(10) UNSIGNED NULL,
  `deleted` TINYINT(1) NULL DEFAULT 0 COMMENT 'if hashtag is marked for deletion',
  `collectedPosts` BIGINT(50) UNSIGNED NULL DEFAULT 0,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `hashtags_hashtag` (`hashtag` ASC)  KEY_BLOCK_SIZE=255,
  INDEX `hashtags_accounts_accountId` (`accountId` ASC),
  INDEX `hashtag_trackingDate` (`startTracking` ASC, `endTracking` ASC),
  INDEX `hashtag_collectedPosts` (`collectedPosts` ASC),
  INDEX `hashtag_updated` (`updated` ASC),
  FULLTEXT INDEX `hashtag_search` (`hashtag` ASC),
  CONSTRAINT `hashtags_accounts_accountId`
    FOREIGN KEY (`accountId`)
    REFERENCES `local_sysDB`.`accounts` (`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
ROW_FORMAT = COMPRESSED
KEY_BLOCK_SIZE = 16;

当我尝试运行此操作时，出现以下错误：

SQL查询：

MySQL-meldt:Documentatie

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

我已经发现这与：

767字节是InnoDB表的指定前缀限制-its MyISAM表的长度为1000字节

根据对该问题的回复，您可以获得要应用的密钥 通过指定列的子集而不是整个金额。 即：

altertable

mytable

addunique（第1列（15），第2列（200））；扭 因为你需要得到申请的钥匙，但我想知道这是否值得 检查您关于此实体的数据模型以查看是否存在 允许您实现预期业务的改进 不受MySQL限制的规则

我尝试向索引添加长度，但MySQL Workbench一直将它们重置为0。

---

我想知道这个问题是否有其他原因，或者解决这个问题的其他方法。

我刚刚学会了一种解决方法。。。获取5.5.14或5.6.3（或更高版本），执行此处指示的设置，并使用动态或压缩：

SET GLOBAL innodb_file_per_table = ON,
           innodb_file_format = Barracuda,
           innodb_large_prefix = ON;
CREATE TABLE so29676724 (
  `id` INT NOT NULL AUTO_INCREMENT,
  `hashtag` VARCHAR(255) NOT NULL COMMENT 'hashtag must be unique. Must be saved without #',
   PRIMARY KEY (`id`),
  UNIQUE INDEX `hashtags_hashtag` (`hashtag` ASC)
)
ENGINE = InnoDB
DEFAULT CHARACTER SET  utf8mb4
ROW_FORMAT = COMPRESSED;

SHOW CREATE TABLE so29676724\G

mysql> CREATE TABLE so29676724 (
    ->   `id` INT NOT NULL AUTO_INCREMENT,
    ->   `hashtag` VARCHAR(255) NOT NULL COMMENT 'hashtag must be unique. Must be saved without #',
    ->    PRIMARY KEY (`id`),
    ->   UNIQUE INDEX `hashtags_hashtag` (`hashtag` ASC)
    -> )
    -> ENGINE = InnoDB
    -> DEFAULT CHARACTER SET  utf8mb4
    -> ROW_FORMAT = COMPRESSED;
Query OK, 0 rows affected (0.09 sec)

“哈希”通常是十六进制，而不是UTF-8。散列通常比255短得多

如果其中一个适用，那么

`hashtag`
       VARCHAR(160)           -- this
       CHARACTER SET ascii    -- and/or this

将是一个解决方案，可以在任何版本上工作，而不需要指定任何innodb设置

---

（注意：191是使用

utf8mb4

的

VARCHAR

的截止值，但很少有标准哈希需要这么多。）

（1）使用

mysql

命令行界面，以及（2）针对Workbench--bugs.mysql.com编写错误报告。您使用utf8mb4吗？如果不是，那么哪个索引给出了错误？@RickJames是的，我使用的是

utf8mb4

@RostD-更新版本可能足够，也可能不够。5.7变更和违约；这可能不会过滤到任何现有表中。

`hashtag`
       VARCHAR(160)           -- this
       CHARACTER SET ascii    -- and/or this