【问题标题】:Aurora Serverless MySQL Gives "Index Column Size Too Large" Despite Proper Settings尽管设置正确,Aurora Serverless MySQL 仍给出“索引列大小太大”
【发布时间】:2019-05-20 20:33:08
【问题描述】:

作为 Invision 社区论坛升级过程的一部分,我正在尝试向现有表添加索引。该数据库托管在兼容 MySQL 5.6 的 AWS Aurora Serverless 中。但是,每次,我都会收到错误:

ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.

以下是有关表和架构的详细信息:

+---------------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+-------------+-------------+------------+--------------------+----------+--------------------+---------+
| Name          | Engine | Version | Row_format | Rows  | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation          | Checksum | Create_options     | Comment |
+---------------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+-------------+-------------+------------+--------------------+----------+--------------------+---------+
| ibf_core_tags | InnoDB |      10 | Dynamic    | 36862 |            299 |    11026432 |               0 |     13189120 |   4194304 |          95183 | NULL        | NULL        | NULL       | utf8mb4_unicode_ci |     NULL | row_format=DYNAMIC |         |
+---------------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+-------------+-------------+------------+--------------------+----------+--------------------+---------+
+--------------------+--------------+------+-----+---------+----------------+
| Field              | Type         | Null | Key | Default | Extra          |
+--------------------+--------------+------+-----+---------+----------------+
| tag_id             | bigint(20)   | NO   | PRI | NULL    | auto_increment |
| tag_aai_lookup     | char(32)     | NO   | MUL |         |                |
| tag_aap_lookup     | char(32)     | NO   | MUL |         |                |
| tag_meta_app       | varchar(200) | NO   | MUL |         |                |
| tag_meta_area      | varchar(200) | NO   |     |         |                |
| tag_meta_id        | int(10)      | NO   |     | 0       |                |
| tag_meta_parent_id | int(10)      | NO   |     | 0       |                |
| tag_member_id      | int(10)      | NO   | MUL | 0       |                |
| tag_added          | int(10)      | NO   | MUL | 0       |                |
| tag_prefix         | int(1)       | NO   |     | 0       |                |
| tag_text           | varchar(255) | YES  |     | NULL    |                |
+--------------------+--------------+------+-----+---------+----------------+

表的默认字符集是 utf8mb4,innodb_large_prefix 设置是 ON

我想做的操作是:

ALTER TABLE `ibf_core_tags` ADD KEY `tag_text` (`tag_text`(191));

我认为 191 * 4 = 764,小于它说我超过的 767 字节值。这是 Aurora Serverless 中的错误吗?有没有办法解决这个问题?我尝试将表更改为 MyISAM 以添加索引,但实际上我在尝试时遇到了同样的错误。

使用 MySQL 5.6 的本地安装,我能够在同一个数据库上运行这个 ALTER TABLE 查询,所以我不确定为什么 Aurora Serverless 有什么不同。

我最终在一个非无服务器的 Aurora 实例上尝试了这个并且遇到了同样的问题。

【问题讨论】:

  • Aurora 不是 InnoDB,它是 Amazon 出品的闭源存储引擎。 Aurora 忽略了许多 InnoDB 配置选项。
  • 如果将tag_text改为varchar(191),然后声明索引而不尝试使用索引前缀语法,是否有效?
  • 询问支持团队。然后在这里发布答案。
  • 实际上,我建议将列的大小调整为 varchar(191),然后在其上创建索引。但我很高兴它对你有用。我猜极光不支持索引前缀?我不知道。这是 Aurora 的问题之一。他们已经更改了存储引擎的大量内部结构,但并不太愿意提供有关更改的确切信息。
  • 对不起,我说错了:我的意思是我将列的大小调整为 191,然后在其上创建了一个索引。我想知道如果我将列的大小再次调整为 255 会发生什么。如果你不指定索引前缀长度,我对会发生什么很模糊。

标签: mysql aws-serverless amazon-aurora aws-aurora-serverless


【解决方案1】:

我在使用 Laravel 进行数据库连接的 Slim PHP 项目中遇到了同样的问题。默认情况下,AWS Aurora Serverless 使用 Antelope 的文件格式,默认为 COMPACT 的行格式。我们需要Barracuda 的文件格式和DYNAMIC 的行格式以允许大索引键前缀(reference)。

我创建了一个自定义参数组并明确设置了以下参数:

  • innodb_file_format = Barracuda
  • innodb_file_per_table = 1
  • innodb_large_prefix = 1

这些参数允许根据AWS's Aurora Serverless documentation设置。

设置这些参数本身并不能解决问题。仍在使用行格式COMPACT 创建表。在数据库连接参数中,我还必须设置'engine' => 'InnoDB ROW_FORMAT=DYNAMIC' (reference)。此语法适用于 Laravel,但希望它能为其他人指明正确的方向,因为我花了整整一个下午才弄清楚:)

【讨论】:

  • 我会在不久的将来尝试一下,看看它是否能解决我的问题,谢谢!
猜你喜欢
  • 1970-01-01
  • 2021-07-16
  • 2017-06-21
  • 1970-01-01
  • 2016-01-06
  • 2019-09-05
  • 1970-01-01
  • 2011-03-28
  • 2021-10-21
相关资源
最近更新 更多