Нет, нет, я абсолютно с вами согласен, это и называется непредсказуемое поведение, и с первого (да и не только с первого) взгляда это поведение кажется не логичным, и конечно это огромный минус такого запроса, т.к. может привести к нестабильности в работе приложения.

Просто я не пойму почему вы считаете что реплейс это заведомо лучший аналог on duplicate key во всех ситуациях? Разным задачам — разные инструменты.

Значит это только для меня его поведение оказалось непрогназируемым :(
Я считал что что он обязан поменять на сс=4 в обеих строках, так как в обеих возникает повтор уникального индекса.
А в такой трактовке — «…следует избегать использования…» можно лишь говорить о непредсказуемости результата. Ведь вы не можете сказать первую или вторую стоку он изменит…
Если вначале был создан индекс «aа», а потом «bb», то изменит в первой строке. А если у меня коротнуло базу и я восстановил/пересоздал индекс «aa», то он уже будет менять вторую строку! Непрогнозируемо…
Да и услови «не использовать таблицы с множеством уникальных индексов» в реальной жизни редко встречается, ведь как минимум Автоинкрементное поле ID наверняка созаём уже не задумываясь…

А вообще смысл моего комментария был: Можно тремя запросами (как начинающие), можно двумя запросами (как у вас), а можно и одним…

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

В общем случае, следует избегать использования ON DUPLICATE KEY на таблицах со множеством уникальных (UNIQUE) ключей.

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

Боюсь ошибиться (специально не заглядывал в мануал), но обновится одна из двух строк. Скорее всего та с которой mysql обнаружит первый конфликт.

Работают они действительно по разному…
REPLACE — медленней (ведь там по сути удаление и вставка)
а ON DUPLICATE KEY — не прогнозируемый!

Например, есть у вас таблица с полями aa, bb, cc
aa уникальный
bb уникальный
Заполняем таблицу:
insert table (aa,bb,cc) values (1,null,0)
insert table (aa,bb,cc) values (null,2,0)
и после этого ваш:
insert table (aa,bb,сс) values (1,2,3) on duplicate key update сс=4
и угадайте, какая строка получит cc=4 ?

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

А в статье я больше делал акцент на преимущество использования индексов. Казалось бы это уже банально и об этом все знают, но вот большинство моих друзей-программистов удивлялись когда я им рассказывал о преимуществе использования индексов.

Но вы правы, зря я не упоминул про REPLACE)

mysql_query("REPLACE `logs` (`ip`, `data`) VALUES ('".$ip."', '".$data."')");

Вот основные:

• «Базы данных. Проектирование, реализация и сопровождение. Теория и практика» — Томас Коннолли, Каролин Бегг
• «Введение в системы баз данных.» — Крис Дейт

А вообще книг на эту тематику много, попробуйте погуглить ;)