Запросы SELECT и UPDATE с тем же предложением где получают разные результаты подсчета строк? - PullRequest
Новая
       24

Запросы SELECT и UPDATE с тем же предложением где получают разные результаты подсчета строк?

0 голосов
/ 10 апреля 2020

Использование MySQL 5.6.

Я использовал запрос на обновление 

UPDATE listtimeentry 
SET quoteId = 5683, 
lastAlteredQte="2020-04-10 11:06:14", 
userIdQte=1112, 
roleIdQte=10 
WHERE soId = 2488 AND quoteId IS NULL;

, который сообщал мне, что были затронуты 0 строк, были сопоставлены 0 строк, поэтому ничего не обновлялось. Это смутило меня, так как я знал, что это за данные, и знал, что должно быть что-то, что было затронуто. Так что я сделал SELECT с теми же критериями - 

SELECT * FROM listtimeentry
WHERE soId = 2488 AND quoteId IS NULL;

, и это возвращало мне 4 строки. Как мой UPDATE ни на что не влияет, в то время как SELECT с теми же критериями показывает, что должно быть что-то затронутое? Дополнительным фактом об этой базе данных является то, что SQL_SAFE_UPDATES выключен.

Как это может быть и как я могу изменить свой оператор UPDATE, чтобы он влиял на 4 строки, которые захватывает мой оператор SELECT?

Редактировать: если я запускаю запрос на выбор, я получаю это 

id    soId    quoteId    userIdQte    roleIdQte    lastAlteredQte
=======================================================
101   2488    NULL       NULL         NULL         NULL
106   2488    NULL       NULL         NULL         NULL
192   2488    NULL       NULL         NULL         NULL
206   2488    NULL       NULL         NULL         NULL

И соответствующие части SHOW CREATE статистики 

CREATE TABLE `listtimeentry` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `soId` int(11) DEFAULT NULL,
  `roleIdQte` int(11) DEFAULT NULL,
  `userIdQte` int(11) DEFAULT NULL,
  `lastAlteredQte` datetime DEFAULT NULL,
  `lastAlteredAfterConfirmationQte` datetime DEFAULT NULL,
  `notNeeded` int(11) DEFAULT NULL,
  `qteNeeded` int(11) DEFAULT '0',
  `quoteId` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `userIdQte` (`userIdQte`),
  CONSTRAINT `listtimeentry_ibfk_3` FOREIGN KEY (`userIdQte`) REFERENCES `listusers` (`idx`)
) ENGINE=InnoDB AUTO_INCREMENT=118783 DEFAULT CHARSET=latin1;

Существует один триггер для таблица listtimeentry, которая запускается после INSERT

BEGIN
    INSERT INTO `tab`.`listlineitems` SET 
    `listlineitems`.`itemId` = NEW.`id`,
    `listlineitems`.`type` = 1;
END

Редактировать: Закрытие. С моим сервером что-то не так. Каким-то образом я получал кэшированные результаты с моим оператором SELECT, но когда UPDATE попытался запустить его, это не удалось. Я перезапустил свой сервер MySQL 5.6, и все работает отлично, знаю. К сожалению, я не знаю, что вызвало это.

1 Ответ

0 голосов
/ 10 апреля 2020

При запуске оператора UPDATE - MySQL не будет обновлять столбцы, в которых новое значение совпадает со старым значением. Это создает возможность того, что количество затронутых строк может фактически не совпадать с количеством совпадающих строк, а только количество строк, которые были буквально затронуты запросом.

Если вы хотите, вы можете использовать оператор REPLACE, который сначала удаляет запись с тем же первичным ключом, а затем вставляет новую строку.

...