hvlad писал(а):Т.е. для cid='2290000' есть ID, близкий к максимальному ?
Да, причем я так подобрал, чтобы все имеющиеся записи имели ID близкий к максимуму. Максимальный ID=1690161, а записи с CID 2290000 имеют ID=1690115, 1690112, 1690110
1506 фетчей чётко указывает на долгий скан индекса.
Я на это тоже обратил внимание. Хотя по смыслу сканирование индекса дожно было прекратиться после того, как все 3 записи выведены, а он все отсканировал. В моей голове это не укладывается.
Вопрос самый что ни на есть корректный, просто нужно подумать немного.
А ответ будет одинаковый для всех СУБД с индексами - ключи в индексе упорядочены прежде всего по значению ключа, а не номеру записи.
Давай своё "придумывается легко", посмотрим
Он корерктен в контексте СУБД, про которую известно, что индекс там предназначен только для получения ноемра записи по ключу
Я же задавал вопрос без такого знания.
Ну а "придумывается легко" - это, например, доп. индекс, для перевода номера записи в порядковый номер при упорядоченном выводе. Дороже по памяти, дороже по добавлению данных, дешевле в случае упорядоченного вывода маленького набора. Но это - теоретизирование.
pticelov писал(а):А из разряда вполне очевидных идей есть такая мысль к разработчику: а почему ФБ не пытается после построения битмапа оценить количество записей в выборке и при небольшом их числе (относительно размера индекса) просто отключить использование индекса в сортировке? Вроде бы идея очевидная.
НЕТ НИКАКОЙ СОРТИРОВКИ в плане с ORDER, когда ты это поймёшь ?!
Я не очень корректно сформулировал свою идею, хвост следует читать как: "отключить использование индекса при упорядоченном выводе и сделать как обычно без индекса - прочитать все записи и отсортировать". То, что упорядоченный вывод по индексу не требует сортировки - я понял уже.
План выполнения запроса строится на этапе prepare.
И динамическое изменение плана запроса (во время выполнения) не так просто, как кажется.
И я не знаю ни одной СУБД, в которой это было бы реализовано.
Ну я не знаю, как устроен ФБ, но это напрашивается. Верю, что внутри есть какие-то проблемы.
В jet'е как-то данная проблема обходится - он не подтормазивает на таких запросах. Отчего я и наступил на граблю со всего размаху при переходе с него на ФБ. Вроде привык с этим жить уже, чутка редизайнил софт, разбив все на 2 коннкшна к БД для предсказуемых и непредсказуемых запросов, чтобы реалтайм часть не тормозилась, случись что. Еще бы с вопросом, который у меня в начале этого комментария разобраться - и все будет хорошо.
Кстати, небольшой вопрос про embedded: у обыного ФБ я мог уоткрыть сколько угодно коннешнов он одного приложения, но если я хочу, чтобы запросы выполнялись параллельно, я должен все открывать по TCP. А что делать с embedded?