> Я читаю текущее значение, чтобы присвоить его увеличенное значение позиции новой аудиозаписи.
Действительно. До этого места не проскроллил.
А зачем сохранять позицию?
Первая ошибка: не нужно читать текущее значения счетчика только лишь для того, чтобы сделать инкремент. Достаточно одного апдейта.
Вторая ошибка: счетчики не должны быть чувствительны к транзакциям. От слова совсем. Любые операции со счетчиками обязаны быть атомарными. В Оракле и Постгресе для этого есть т.н. последовательности (SEQUENCES), в убогом MySQL - автоинкремент и MYISAM.
Pavel, ваш ответ достоин эксперта! занес в избранное.
а теперь по теме. беглый поиск в гугле не дал внятного ответа, документакия MySQL тоже. пришлось провести полевой эксперимент.
план обеих запросов примерно одинаков. выборка производится по первичному ключу, т.е. без обращения к самой таблице. время выполнения второго зависит от количества элементов в IN(). при небольшом количестве элементов отличия ничтожны.
тепер о разнице N vs 1. вы забыли один момент, а именно - сетевые издержки. это бутылочное горло любой системы. при выборке по нескольким ключам - у вас одно подключение, один запрос, один fetch. при трех - все время выполнения первого запроса помноженное на количество ключей.
я предполагаю, что вы сейчас мне начнете рассказывать про prepared statements. но даже в этом случае сетевые издержки ни куда не денутся.
я надеюсь, что вы, уважаемый сэр Pavel K, всетаки дадите исчерпывающий ответ, почему же три запроса будут выполняться быстрее, чем один. и приложите ссылочку соответствующую.
заранее признателен.
Действительно. До этого места не проскроллил.
А зачем сохранять позицию?