Обновился с 8.0.28 на 8.0.29 Сломались геоиндексы. Разрабы что-то в оценке

оптимизатора нахимичили.
Запрос:
EXPLAIN ANALYZE
SELECT id, PropertyLatitude
FROM geotable f-- FORCE INDEX (PropertyPoint)
WHERE MBRContains(@line, PropertyPoint)


8.0.28 - корректно использует SPATIAL индекс по полю PropertyPoint
-> Filter: mbrcontains(<cache>((@line)),f.PropertyPoint) (cost=22641.47 rows=50311) (actual time=1.648..3.275 rows=10 loops=1)
-> Index range scan on f using PropertyPoint over (PropertyPoint unprintable_geometry_value) (cost=22641.47 rows=50311) (actual time=0.755..2.104 rows=10 loops=1)


8.0.29 - делает фулскан, индекс без подсказки не использует, работает долго
-> Filter: mbrcontains(<cache>((@line)),f.PropertyPoint) (cost=136546.39 rows=1108445) (actual time=2.049..10850.772 rows=10 loops=1)
-> Table scan on f (cost=136546.39 rows=1108445) (actual time=0.031..2636.929 rows=1176031 loops=1)


8.0.29 с FORCE INDEX (PropertyPoint), индекс использует, работает быстро, но в расчётных cost'ах и rows'ах, какие-то дикие значения
-> Filter: mbrcontains(<cache>((@line)),f.PropertyPoint) (cost=2234848043.44 rows=4828713394) (actual time=0.431..0.568 rows=10 loops=1)
-> Index range scan on f using PropertyPoint over (PropertyPoint unprintable_geometry_value) (cost=2234848043.44 rows=4828713682) (actual time=0.403..0.477 rows=10 loops=1)

очевидно что оптимизатор не выбирает данный индекс потому что думает что ему надо будет просмотреть 4828713682 строк, хотя у меня всего 1.1кк строк в таблице

Кто-нть сталкивался с таким?

Да, это типичное поведение оптимизатора.

Чёт не совсем типичное... 3 года все версии 5.7 и 8.0.х выбирали корректный индекс и примерно верный кост, а тут дичь какая то

Ничего супер необычного, разные версии ПО работают по разному

Также, значение стоимости не важно, важно относительные величины двух значений стоимости в разных планах