IdentИнтересуют адаптивные методы оптимизации и хеширования в современных SQL-серверах.
Или же все СУБД принимают решение о выборе пути доступа, опираясь на накопленную статистику и на структуру индексов?
Помимо статистики и индексов, оптимизаторы учитывают сами запросы, требуемый уровень изоляции, доступные ресурсы и текущие нагрузки на сервер - поэтому например у запросов на обычную выборку, на аггрегаты, OLAP функции и рекурсии могут быть совершенно разные планы запросов и способы выбора данных, которые опять же на эти же запросы могут меняться в зависимости от уровня изоляции, ресурсов и нагрузок.

Identа адаптивные системы могли бы за счет обратной связи сравнивать свои оценки с реальной мощностью результата и вычислять поправки для своих оценок
А кто Вам сказал, что оптимизаторы РСУБД этого не делают ? В той же ASA рядом с оптимизатором сидит эвристический анализатор, задача которого отслеживать работу оптимизатора, сравнивать выбранные им планы запросов и их стоимость (время) с фактически полученной стоимостью (временем) выполнения запроса. Анализатор автоматически корректирует статистику по таблицам, вычисляет наиболее эффективные планы часто повторящихся или же тяжелых запросов, забрасывая их в кэш планов, снимая таким образом нагрузку с оптимизатора до тех пор, пока такие сохраненные планы запросов будет отрабатывать эффективно. При резком "проседании" выполнении запроса и периодически по времени на всякий случай анализатор будет заставлять оптимизатор запросов опять самому построить планы, вместо сохраненным в кэше планов, чтобы сравнить с своими в кэше и точно убедиться, что они до сих пор являются эффективными и оптимизатор не построил более удачный по результатам выполнения план. С учетом того, что работа анализатора сохраняется еще и в БД вместе с понравившимися ему планами, на случай перезапуска сервера с целью быстрого подьема БД без начальной потери производительности (чтобы произошло, если бы анализатор с нуля начал свою работу), то можно вполне уверенно сказать, что чем дольше БД с данными крутиться, чем больше запросов на получение данных на ней выполняется, тем точнее на ней статистика и наиболее удачно выбираются планы запросов. Можно сказать этакая саморазвивающаяся БД.

P.S. Все в принципе вышесказанное я процитировал с BOL ASA. Надо думать в большинстве других РСУБД примерно похожие решения.