Осваиваюсь с новой версией MS SQL 2019 , периодически удивляет оптимизатор
Дают простой запрос
select top 10 * from dbo.msg_buffer where MsgCounter>2560000000
order by MsgCounter asc
Он думает 4 минуты, и выдавая план 100% Clustered index scan

Причем индекс там очевидный, что сканировать там неясно. Ну да есть конечно order by , но что получается архисложно первых записей по условию отобрать из индекса?
Вопрос - можно ли это как то ускорить?

ALTER TABLE [dbo].[msg_buffer] ADD CONSTRAINT [PK_msg_buffer] PRIMARY KEY CLUSTERED
(
[MsgCounter] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF)
GO

,
Секционирована, но этот индекс содержит основное поле MsgCounter по которому идет секционирование - поэтому скана по всем секциям быть не должно

15.0.2000.5

Ну с распаралеливанием там есть нюанс в 2019 это во всех редакциях доступно, а до этого было не во всех
https://docs.microsoft.com/ru-ru/sql/sql-server/editions-and-components-of-sql-server-version-15?view=sql-server-ver15
Но на самом деле параллельных запросов по секциям стоит избегать поскольку они будут утыкаться в дисковую подсистему да и поле секционирования в условия включают не просто так а чтобы запрос шел по конкретным сециям