Важно, какой engine используют твои таблицы.
Я так вангую, что у тебя InnoDB.

автор1) Насколько я понимаю, в БД есть 2 типа замков: exclusive и shared. Первый ставиться через select.. update,

Или просто UPDATE.

авторвторой - select .. lock in share mode или что-то подобное. Exclusive Lock запрещает все операции с рядом, тогда как Shared Lock позволяет читать и навешивать другие Shared Locks. Правильно ли я понимаю?


Почти.
Exclusive Lock запрещает все операции со строкой, кроме чтения её предыдущей версии.


автор2) Зависит ли описанное в п.1. от уровня изоляции?

От уровня изоляции транзакции ? Нет, не зависит. Почти не зависит. Потому что при разных уровнях накладываются разные блокировки, но поведение их не меняется. Exclusive Lock используется на уровне изоляции 0, т.е. всегда при изменении данных
(SELECT...FOR UPDATE -- это тоже изменение). Shared Lock не используется в InnoDB, но на уровне SERIALIZABLE может использоваться.

автор3) Я попробовал заблокировать ряд через select... update, и одновременно запустил параллельную транзакцию, читающую этот ряд. Она сработала. При попытке записать - не сработала. Почему это так? Можно ли вообще заблокировать ряд на запись, кроме как включив isolation_level = synchronized? У меня стоит дефолтный уровень repeatable_read.

В InnoDB реализован MVCC, и он работает на т.н. snapshot isolation, это нестандартный уровень изоляции, примерно сравнимый по уровню с repeatable_read.

При записи в транзакции транзакция работает на уровне изоляции 0, write commited. При этом накладывается эксклюзивная блокировка на изменяемую строку до конца транзакции. Она запрещает другим транзакциям менять запись, но не запрещает другим транзакциям читать старую версию записи через механизм MVCC. Поэтому конкурентные пишушие транзакции блокируются, а конкуретные читающие -- нет, они просто читают старую версию записи.

автор"Можно ли вообще заблокировать ряд на запись, кроме как включив isolation_level = synchronized?
У меня стоит дефолтный уровень repeatable_read."

Не synchronized, а serializable. Можно, ты же это и сделал -- заблокировал эту запись до конца транзакции на запись.
На чтение заблокировать её нельзя, да и не нужно никому.
От уровня изоляции это не зависит, поскольку блокировка на запись -- это уровень 0 (write commited по Грею), меньше которого не бывает.

netwindMasterZiv, я понимаю шо это форум по ораклу, но откуда вы черпаете сведения о mysql? результаты каких-то оригинальных исследований ?

1. Все 4 уровня изоляции в INNODB реализованы.
2. дополнительно реализована опция SNAPSHOT ISOLATION для REPEATABLE READ.

Я занимался в какое-то время разработкой SolidDB+MySQL. Знаю неплохо InnoDB, потому что наш SolidDB должен был бы быть его заменителем, да и сам он почти 1:1 InnoDB, потому что главный разработчик InnoDB был ранее разработчиком SolidDB, у них почти одна идеология архитектуры.

Ну, и сам сейчас применяю, конечно.

Я конечно могу в каких-то мелочах ошибаться, потому что время идёт, а InnoDB меняется.

Ещё раз, это -- достаточно тонкий вопрос. Все уровни ANSI в INNNODB "поддерживаются", как и в любых других СУБД.
Но проблема как раз в том, что значит это слово "поддерживаются". По сути все уровни изоляции по ANSI имитируются.
Работают только два уровня, SNAPSHOT ISOLATION и SERIALIZABLE. Ну и WRITE COMMITED.

Допишу потом...

netwindMasterZiv, я понимаю шо это форум по ораклу, но откуда вы черпаете сведения о mysql? результаты каких-то оригинальных исследований ?


Я не понял про оракл нифига.

MasterZivДопишу потом...

...

Т.е. важно не то, проглотит ли MySQL

SET TRANSACTION ISOLATION LEVEL XXX

а как при этом каждый уровень будет реализовываться.

netwindЧто плохого то ?

Я разве писал, что это плохо?
Я писал, как это реально работает.

netwindMasterZivпропущено...


Я не понял про оракл нифига.
шутка такая. "sql.ru - форум по ораклу". являющаяся, однако, шуткой лишь частично.

Это фигня какая-то, потому что самый массовый форум на sql.ru - это по MS SQLServer.
Да и спонсоры платят, на сколько я знаю, в основном за него. Ну да ладно, это не по теме.