База данных Magento 1.8.1 на ключе дублирования не выполняет обновление в catalog_product_entity_varchar

Я думаю, что это может быть скорее проблемой MySQL, чем проблемой Magento, но я имею дело с базой данных Magento. Вот что я сделал.

Я получил MySQL для регистрации запросов и нашел запрос, похожий на тот, который я собираюсь опубликовать. Этот запрос обновляет catalog_product_entity_varchar table, Я удалил другие атрибуты varchar, которые были обновлены, и просто оставил этот вопрос, чтобы сделать его более простым для чтения (атрибутов много).

INSERT INTO `catalog_product_entity_varchar`
(`entity_type_id`,`attribute_id`,`store_id`,`entity_id`,`value`) VALUES
('4', '187', '0', '352203', 'asdf')
ON DUPLICATE KEY UPDATE `value` = VALUES(`value`)

Этот запрос, независимо от того, поместил ли я весь исходный запрос с целой кучей обновлений атрибутов или просто добавил запрос точно так же, как указано выше, не обновляет строку. Точный запрос выше на самом деле говорит, что две строки были вставлены. В базе данных нет изменений. Это изолированно для этой таблицы только в базе данных. Ошибок не дано. Это просто говорит о том, что Икс количество строк было вставлено.

Я решил вытащить запрос из другой похожей таблицы сущностей. Я выбрал текстовую таблицу. Этот запрос был следующим:

 INSERT INTO `catalog_product_entity_text` (`entity_type_id`,`attribute_id`,`store_id`,`entity_id`,`value`)
VALUES ('4', '83', '0', '352203', 'test'), ('4', '106', '0', '352203', 'test')
ON DUPLICATE KEY UPDATE `value` = VALUES(`value`)

Это сработало, как и ожидалось. Так что я не думаю, что это проблема с рабочей базой данных ON DUPLICATE KEY — она ​​изолирована от таблицы catalog_product_entity_varchar.

Я проверил все таблицы, и никакие таблицы не заблокированы или не используются. Я подумал, что, возможно, мне придется совершить транзакцию, но я не думаю, что это так. Автокоммит включен. Я не верю, что смогу изменить это в зависимости от таблицы, но я не использую START TRANSACTION, поэтому мне все равно не придется совершать коммиты, верно? Я протестировал с COMMIT после заявления, даже подумал, что на 99% уверен, что ничего не должен делать, но результаты не изменились.

mysql> SHOW VARIABLES LIKE "%autocommit%";

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+

Я решил проверить свой сервер разработки (да, это происходит на производстве), и запрос работает отлично. Таким образом, это изолировано от catalog_product_entity_varchar Таблица И это конкретная база данных.

Я проверил структуру между двумя базами данных, они одинаковы. Увидеть ниже

РАЗРАБОТКА СТРУКТУРЫ DUMP

CREATE TABLE IF NOT EXISTS `catalog_product_entity_varchar` (
`value_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Value ID',
`entity_type_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity Type ID',
`attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute ID',
`store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store ID',
`entity_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity ID',
`value` varchar(255) DEFAULT NULL COMMENT 'Value',
PRIMARY KEY (`value_id`),
UNIQUE KEY `UNQ_CAT_PRD_ENTT_VCHR_ENTT_ID_ATTR_ID_STORE_ID` (`entity_id`,`attribute_id`,`store_id`),
KEY `IDX_CATALOG_PRODUCT_ENTITY_VARCHAR_ATTRIBUTE_ID` (`attribute_id`),
KEY `IDX_CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID` (`store_id`),
KEY `IDX_CATALOG_PRODUCT_ENTITY_VARCHAR_ENTITY_ID` (`entity_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='Catalog Product Varchar Attribute Backend Table' AUTO_INCREMENT=211079 ;

--
-- Constraints for dumped tables
--

--
-- Constraints for table `catalog_product_entity_varchar`
--
ALTER TABLE `catalog_product_entity_varchar`
ADD CONSTRAINT `FK_CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID_CORE_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE     CASCADE ON UPDATE CASCADE,
ADD CONSTRAINT `FK_CAT_PRD_ENTT_VCHR_ATTR_ID_EAV_ATTR_ATTR_ID` FOREIGN KEY (`attribute_id`) REFERENCES `eav_attribute` (`attribute_id`) ON DELETE     CASCADE ON UPDATE CASCADE,
ADD CONSTRAINT `FK_CAT_PRD_ENTT_VCHR_ENTT_ID_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`entity_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON     DELETE CASCADE ON UPDATE CASCADE;

ПРОМЫШЛЕННАЯ КОНСТРУКЦИЯ

    CREATE TABLE IF NOT EXISTS `catalog_product_entity_varchar` (
`value_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Value ID',
`entity_type_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity Type ID',
`attribute_id` int(10) unsigned NOT NULL COMMENT 'Attribute ID',
`store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store ID',
`entity_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity ID',
`value` varchar(255) DEFAULT NULL COMMENT 'Value',
PRIMARY KEY (`value_id`),
UNIQUE KEY `UNQ_CAT_PRD_ENTT_VCHR_ENTT_ID_ATTR_ID_STORE_ID` (`entity_id`,`attribute_id`,`store_id`),
KEY `IDX_CATALOG_PRODUCT_ENTITY_VARCHAR_ATTRIBUTE_ID` (`attribute_id`),
KEY `IDX_CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID` (`store_id`),
KEY `IDX_CATALOG_PRODUCT_ENTITY_VARCHAR_ENTITY_ID` (`entity_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='Catalog Product Varchar Attribute Backend Table' AUTO_INCREMENT=2147483647 ;

--
-- Constraints for dumped tables
--

--
-- Constraints for table `catalog_product_entity_varchar`
--
ALTER TABLE `catalog_product_entity_varchar`
ADD CONSTRAINT `FK_CATALOG_PRODUCT_ENTITY_VARCHAR_STORE_ID_CORE_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE,
ADD CONSTRAINT `FK_CAT_PRD_ENTT_VCHR_ATTR_ID_EAV_ATTR_ATTR_ID` FOREIGN KEY (`attribute_id`) REFERENCES `eav_attribute` (`attribute_id`) ON DELETE CASCADE ON UPDATE CASCADE,
ADD CONSTRAINT `FK_CAT_PRD_ENTT_VCHR_ENTT_ID_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`entity_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE;

Я понятия не имею, почему это происходит. Я весьма озадачен.

Кроме того, я только недавно восстановил эту базу данных из резервной копии, но это происходило до этого восстановления. Я использую Percona — последнюю версию. Настройки для базы данных были потеряны, поэтому я настроил ее с нуля. Вот все настройки, которые, я думаю, могут помочь.

mysql> SHOW VARIABLES LIKE "%version%";
+-------------------------+-----------------------------------------------------    -+
| Variable_name           | Value                                                    |
+-------------------------+-----------------------------------------------------    -+
| innodb_version          | 5.6.23-72.1                                              |
| protocol_version        | 10                                                       |
| slave_type_conversions  |                                                          |
| version                 | 5.6.23-72.1                                              |
| version_comment         | Percona Server (GPL), Release 72.1, Revision 0503478     |
| version_compile_machine | x86_64                                                   |
| version_compile_os      | Linux                                                    |
+-------------------------+-----------------------------------------------------    -+
7 rows in set (0.00 sec)

my.cnf

    [mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Skip reverse DNS lookup of clients
skip-name-resolve

# optimisations for Magento
# changed open_files_limit to 65535
open_files_limit = 65535
max_allowed_packet = 16M
wait_timeout = 360
# changed kbs from 128M to 32M
key_buffer_size = 32M
# changed query_cache_type = 0 and size to 0
query_cache_type = 1
query_cache_size = 16M
sort_buffer_size = 1M
thread_cache_size = 50
# changed innodb bps to 36G from 20G after RAM upgrade 24GB-48GB
innodb_buffer_pool_size = 39G
# innodb_buffer_pool_instances = 8
innodb_additional_mem_pool_size = 20M
innodb_log_buffer_size = 8M
innodb_file_per_table = 1
innodb_lock_wait_timeout = 1200

ft_min_word_len=2

# Added July 29, 2014
myisam_recover = FORCE,BACKUP
max_connect_errors = 1000000
expire_logs_days = 14
max_connections = 500
table_definition_cache = 4096
table_open_cache = 4096

innodb_flush_method = O_DIRECT
innodb_log_files_in_group = 2
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1

general_log_file=/var/log/general_log.log

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid