Magento MySQL：指定的键太多；最多允许 64 个键答案

【问题标题】：Magento MySQL: Too many keys specified; max 64 keys allowedMagento MySQL：指定的键太多；最多允许 64 个键
【发布时间】：2012-01-31 14:03:55
【问题描述】：

我在运行CREATE TABLE 的Magento PHP 文件中遇到以下错误：

SQLSTATE[42000]: Syntax error or access violation: 1069 Too many keys specified; max 64 keys allowed

触发它的代码是：

CREATE TABLE IF NOT EXISTS {$this->getTable('attributesplash_page')} (
    `page_id` int(11) unsigned NOT NULL auto_increment,
    `option_id` int (11) unsigned NOT NULL default 0,
    `store_id` smallint(5) unsigned NOT NULL default 0,
    `display_name` varchar(255) NOT NULL default '',
    `image` varchar(255) NOT NULL default '',
    `short_description` varchar(255) NOT NULL default '',
    `description` TEXT NOT NULL default '',
    `url_key` varchar(180) NOT NULL default '',
    `page_title` varchar(255) NOT NULL default '',
    `meta_description` varchar(255) NOT NULL default '',
    `meta_keywords` varchar(255) NOT NULL default '',
    `display_mode` varchar(40) NOT NULL default 'PRODUCTS',
    `cms_block` int(11) unsigned NOT NULL default 0,
    `is_enabled` int(1) unsigned NOT NULL default 1,
    PRIMARY KEY (`page_id`),
    KEY `FK_OPTION_ID_SPLASH_PAGE` (`option_id`),
    CONSTRAINT `FK_OPTION_ID_SPLASH_PAGE` FOREIGN KEY (`option_id`) REFERENCES `{$this->getTable('eav_attribute_option')}` (`option_id`) ON DELETE CASCADE ON UPDATE CASCADE,
    KEY `FK_STORE_ID_SPLASH_PAGE` (`store_id`),
    CONSTRAINT `FK_STORE_ID_SPLASH_PAGE` FOREIGN KEY (`store_id`) REFERENCES `{$this->getTable('core_store')}` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='AttributeSplash: Page';

ALTER TABLE {$this->getTable('attributesplash_page')} ADD UNIQUE (option_id, store_id);

在我看来，它似乎只在其中添加了 3 个键。额外的来自哪里？

研究问题只是发现我需要减少用于键的项目，但我看不到代码中多余的项目在哪里。

还有其他有用的信息吗？

【问题讨论】：

标签： php mysql magento key

【解决方案1】：

只需检查所有属性并将它们是否“用于产品列表”设置为“否”，“用于在产品列表中排序”设置为“否”。

我在最近的 Magento 版本中没有遇到过这个问题，但是，上述方法对我有用一次。然后，我能够重新思考我真正需要具备哪些属性以及在哪里。

【讨论】：

我遇到过关于升级 Magento 有时会出现问题的讨论。我只是不确定这里是否会出现这种情况，因为它不是核心模块。我无法破译上面的 SQL 来确定密钥的来源。无论是来自属性，还是与模块表有关。
你试一试了吗？我认为/猜测（！）您仍然在eav_attribute_option 上添加新功能，“通常的解决方案”可能值得一试。无论如何，祝你好运，你的模块看起来很有野心！
我最终将它传递给了原始开发人员。但是您的答案似乎是针对其他板上此类问题的建议，因此我标记为已接受。感谢您的帮助。