Когда MySQL пытается обновить индекс для столбца?
Максимальная единица параллелизма - количество разделов. Если вы запустите больше экземпляров, чем количество разделов, избыточные экземпляры будут простаивать.
Операции соединения должны соответствовать следующим требованиям:
-
Входные данные должны быть разделены во время объединения. Это означает, что входные темы, которые нужно объединить, должны иметь одинаковое количество разделов.
-
Обе темы должны иметь одинаковую стратегию разделения, чтобы записи с одинаковыми ключами могли доставляться в одни и те же разделы. Если это не так, есть вероятность потерять записи.
Пример: если topic1 имеет 2 раздела, а topic2 имеет 3 раздела, Join(topic1,topic2) завершится ошибкой из-за неравных разделов. После того, как вы переделите тему, скажем 3. Теперь Join(topic1, topic2) будет работать. Вы можете максимально использовать 3 задачи для этой операции. Каждый раздел будет поддерживать свое состояние в государственном хранилище в виде внутренних тем. По умолчанию KStream использует RocksDB для хранения состояний.
Здесь вы можете увидеть, как обычно процесс работает для преобразования с состоянием: 
Пожалуйста, обратитесь к ним для более подробной информации:
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+Internal+Data+Management https://docs.confluent.io/current/streams /developer-guide/dsl-api.html#streams-developer-guide-dsl-joins
4 ответа
При выполнении того запроса в клиенте MySQL Вы будете видеть что-то как
Соответствия строк: 1, Обновленные строки: 0
Таким образом, MySQL определенно знает, когда строка изменилась или не - я предположил бы оттуда, что они достаточно умны для не обновления индекса оттуда.
Мало того, что MySQL достаточно умен для не обновления индекса, если значение не изменилось, достаточно умно не переписать значение столбца с тем же значением.
Я сделал некоторое тестирование на этом, с mysql 5.0.41, сравнив обновления с двумя идентичными innodb таблицами (7 седел, все целые числа), за исключением того, что одна таблица имела 5 индексов (несколько, которые составляли 2 столбца), и другая таблица не имела никаких индексов. (Каждая таблица имела свой индекс первичного ключа, все же.)
Вот то, что я закончил с (таблица без индексов является A, таблица с индексами является B):
10k updates of an indexed column with a new value:
A: 76.8 seconds
B: 126.7 seconds
10k updates of a non-indexed column with a new value:
A: 27.6 seconds
B: 22.0 seconds
10k updates of a random column with its same value:
A: 1.4 seconds
B: 1.2 seconds
10k updates of a random column with an incremented value:
A: 12.2 seconds
B: 50.0 seconds
10k updates of an indexed column=>same value, non-indexed column=>new value:
A: 7.0 seconds
B: 10.5 seconds
Я предполагаю, что часть причины, те же/увеличивать значения быстрее, - то, потому что я должен был искать строку прежде, чем сделать обновление, таким образом, это будет кэшироваться в некоторой форме в mysql.
Это все в значительной степени заканчивает то, что другие говорят, но дает некоторый взгляд на то, насколько вещи затронуты индексами. Однако в конкретном случае Jim спросил о, похоже, что это мог бы быть целый на 50% медленнее.
Когда Вы выполняете, MySQL UPDATE сообщает о количестве подобранных строк и измененном числе. Выполнение Вашего запроса в качестве примера дает вывод:
Запрос хорошо, 0 затронутых строк (0,00 секунды) строки соответствовал: 1 Измененный: 0 Предупреждений: 0
Я был бы очень удивлен, не использовал ли MySQL затем ту информацию, чтобы определить, обновить ли индекс.