DLSTЕсли используются два столбца из table1
Оставь один, но не table1.id.
А потом сядь и подумай...

Ну первое, что ты забыл - посмотреть на другие поля эксплейна. Попробуй объяснить, почему в первом запросе оптимизатор использовал первичный индекс второй таблицы, а во втором нет. И только когда поймёшь, подумай, как это связано с изменением экстры.

javajdbcили действительно глюк...
подождем что скажет Акина. Он сказал что понял что к чему...Я, конечно, могу и ошибаться, может, и глюк. Но обращать внимание, я думаю, надо именно на различие планов.

Из первой таблицы в обоих запросах используется одно, причём одно и то же, поле ID. Которое ещё к тому же и, как я вижу, не индексировано. Соответственно по всем параметрам (кроме нагрузки на диск) пофиг, сканить таблицу или любой содержащий это поле индекс (если они вообще есть) - и оптимизатор сканит таблицу, тупо using where. C этим вопросов нет.
А вот со второй таблицей - любопытно. Из неё задействуются в первом запросе два поля (причём в условиях, которые интересны оптимизатору - только одно), а во втором запросе - три, причём по делу - опять одно. А разница оптимизации - принципиальная.
Для первого запроса оптимизатор решил, что использовать индекс для отбора/фильтрации по одному полю, а затем обращение к таблице для получения значения второго поля - выгоднее, а потому задействовал индекс (получается индекс со стороны "много" и скан со стороны "один"), потому и экстра пуста.
Для второго же он решил, что дешевле сразу читать всю таблицу, чем сначала индекс, а потом всё равно всю таблицу - поэтому индекс не задействован, а для отбора по совпадению полей двух таблиц приходится использовать join buffer, а т.к. они ещё и неиндексированные - то частичная сортировка и nested loops.

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

Не знаю... я не могу воспринять происходящее как глюк. Какие бы мы не заложили алгоритмы выбора и граничные значения статистик, влияющие на выбор - всегда существуют статистики, попадающие точно в выбранное нами пограничное значение, когда минимальное изменение критерия приводит к смене выбираемой стратегии. Это сродни тому, как написать выбор на основе условия IF x <= 2.2, и удивляться неверному выбору, когда x=2.2, хотя на самом деле где-то глубоко внутри x=2.20000001.

javajdbc"глюков" = "нестабильности пограничного состояния"...
Вот нехрен было делать - почти два часа пробовал воспроизвести такое пограничное состояние на приведённом примере. Как и следовало ожидать - с нулевым результатом.