На с.д. вопрос qu-qu был очень красивый. Надо было просто его более точно спозиционировать, что речь идет не о банальном ORDER BY, а о внутреннем устр-ве стр-р хр-я данных в SQL Server. Т.е. как и когда он выбирает принадлежащие объекту страницы: по 2-направленному списку, по битовой карте аллоцирования или еще как-то. Вот мои 2 цента к задаче qu-qu.\r
\r
1. \r
use Northwind\r
\r
drop table t\r
create table t (id int identity, a char(8000) default replicate(\'*\', 8000))\r
go\r
set identity_insert t on\r
declare @i int\r
set @i = 10\r
while @i < 20 begin\r
set @i = @i + 1\r
insert t (id) values (@i)\r
end\r
\r
select * from t\r
\r
--Все вроде по порядку, как вставляли. Ну-ка еще немного:\r
\r
declare @j int\r
set @j = 0\r
while @j < 10 begin\r
set @j = @j + 1\r
insert t (id) values (@j)\r
end\r
\r
select * from t\r
\r
--Пошли в конец, потому что их добавили потом. Ну что ж пока вроде все логично. Проведем еще эксперимент:\r
\r
2.\r
select * into Ords from Orders\r
\r
set identity_insert Ords on\r
declare @i int\r
set @i = 9000\r
while @i <= 9975 begin \r
insert Ords (OrderID) values (@i)\r
set @i = @i + 1\r
end\r
\r
--Смотрите-ка, а здесь новодобавленные записи почему-то выдаются сначала. Может, это таблица такая?\r
\r
declare @j int\r
set @j = 9976\r
while @j <= 10000 begin \r
insert Ords (OrderID) values (@j)\r
set @j = @j + 1\r
end\r
\r
--А теперь insertы идут в конец таблицы. Фигня какая-то. М.б. кто-нибудь объяснит?\r
-----------------------------------------------------------------------------------------------------\r
\r
declare @NorthwindID int, @OrdsID int\r
select @NorthwindID = db_id(\'Northwind\'), @OrdsID = object_id(\'Ords\')\r
dbcc traceon(3604)\r
dbcc tab(@NorthwindID, @OrdsID)

"При этом я подозреваю что сначала смотрятся не устаревшие страницы в кеше, а потом уже, если не хватает, он головкой дергает туда-сюда"

drop table Ords
select * into Ords from Orders

--Посмотрим ест.порядок чтения стр-ц
select * from Ords

--Создадим индекс, чтобы положить в кэш последнюю стр-цу данных
create index ix on Ords(OrderID)

--Посмотрим, какие страницы принадлежат таблице Ords
declare @NorthwindID int, @OrdsID int
select @NorthwindID = db_id('Northwind'), @OrdsID = object_id('Ords')
dbcc traceon(3604)
dbcc tab(@NorthwindID, @OrdsID)

--Очистим кэш
dbcc dropcleanbuffers

--И положим ее туда
select top 1 * from Ords order by OrderID desc

--Видите: за вычетом служебных и индексных страниц сейчас в буфере сидит одна-единственная последняя страница данных
dbcc buffer('Northwind', 'Ords')
/* В моем случае это
PAGE: (1:97427)
---------------

BUFFER:
-------

BUF @0x00DD6B40
---------------
bpage = 0x1D44A000 bhash = 0x00000000 bpageno = (1:97427)
bdbid = 6 breferences = 0 bstat = 0x9
bspin = 0 bnext = 0x00000000

PAGE HEADER:
------------

Page @0x1D44A000
----------------
m_pageId = (1:97427) m_headerVersion = 1 m_type = 1
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8020
m_objId = 1074102867 m_indexId = 0 m_prevPage = (1:97426)
m_nextPage = (0:0) pminlen = 58 m_slotCnt = 37
m_freeCnt = 912 m_freeData = 7206 m_reservedCnt = 0
m_lsn = (22278:131:53) m_xactReserved = 0 m_xdesId = (0:10398703)
m_ghostRecCnt = 0 m_tornBits = 1
*/

--По идее данные с нее должны выдаться раньше, чем с остальных, к-е лежат на диске. Проверяем:
select * from Ords

--И видим, что это не так. Порядок чтения страниц не изменился. Может, он головкой как-то не так двигает?

2YellowMan
"Т.е. Вы думаете, что select top 1 * from Ords order by OrderID desc прочтет только последнюю страницу с диска?"
Вах. Канэшн. Вы же видите, что в кэше болтается только она (ну плюс еще 3 индексных стр-цы, по к-м он к ней спускался, но у них m_indexId = 2). Если Вы сомневаетесь, что она это действительно она, сделайте dbcc page('Northwind', 1, 97427, 1) и посмотрите последний заполненный слот:

Slot 36, Offset 0x1b5e
----------------------
Record Type = PRIMARY_RECORD
Record Attributes = NULL_BITMAP VARIABLE_COLUMNS
1D44BB5E: 003a0030 00002b45 00410052 00540054 0.:.E+..R.A.T.T.
1D44BB6E: 00010043 00000000 8c4f0000 00000000 C.........O.....
1D44BB7E: 8c6b0000 00000000 00000000 00020000 ..k.............
1D44BB8E: 4d340000 00000001 000e0000 00060020 ..4M........ ...
1D44BB9E: 009e0080 00b800b4 00c800c2 00610052 ............R.a.
1D44BBAE: 00740074 0065006c 006e0073 006b0061 t.t.l.e.s.n.a.k.
1D44BBBE: 00200065 00610043 0079006e 006e006f e. .C.a.n.y.o.n.
1D44BBCE: 00470020 006f0072 00650063 00790072 .G.r.o.c.e.r.y.
1D44BBDE: 00380032 00370031 004d0020 006c0069 2.8.1.7. .M.i.l.
1D44BBEE: 006f0074 0020006e 00720044 0041002e t.o.n. .D.r...A.
1D44BBFE: 0062006c 00710075 00650075 00710072 l.b.u.q.u.e.r.q.
1D44BC0E: 00650075 004d004e 00370038 00310031 u.e.N.M.8.7.1.1.
1D44BC1E: 00550030 00410053 0.U.S.A.

0x2b45 это как раз 11077 = значение OrderID в последней записи таблицы Ords.

Ваш вариант с max(OrderID) действительно не годится, но по другой причине, чем предполагаете Вы. Просто при наличии индекса он возьмет его с индексной странички и не полезет в данные. Поэтому вы увидите в кэше только три индексных странички. А в отсутствие индекса он, наоборот, должен будет прочитать все, чтобы определить max(OrderID), поэтому в кэше после этого будут сидеть все страницы таблицы, а не только последняя, к-я нам нужна.

Почему SQL Server не берет ее первой несмотря на то, что она в кэше, а остальные на диске? Ну все очень просто. В данном случае ему нужно прочесть всю таблицу. В кэш она заведомо ложится, поэтому он ее всю туда и засасывает за исключением последней страницы, которая там уже есть и которая просто становится более MRUшной. В связи с этим появляются еще две интересных задачи. Что будет происходить, если таблица в кэш не помещается? Счастливые обладатели 6.х могут просто увеличить долю процедурного кэша при пом. sp_configure, в SQL Server 7.0 и выше баланс определяется динамически, поэтому придется придумать что-нибудь похитрее. И вторая задача (копирайт шефа) - сохранится ли порядок выдачи страниц, если для чтения таблицы SQL Server применяет параллельный план?

2qu-qu
Ну такие, скорее, философские рассуждения по поводу целесообразности несколько более глубокого, нежели дает документация, понимания предмета. Я не знаю, не уверен, нужно ли призывать к этому стремиться. Не требуется же от водителя досконального знания устройства автомобиля. Как и любой инструмент, SQL Server предназначен для решения вполне конкретных задач, и вполне достаточно, если человек, который им рулит, будет знать, как этого достичь. Ну вот были ткачи, досконально познавшие секреты ткацкого мастерства. История учит, что победа остается за мануфактурами, за централизованным массовым производством. Именно поэтому Oracle, для нормальной работы которого администратор должен был знать массу фенечек и нюансов настройки, стал проигрывать SQL Server. Пусть опытный админ мог решить задачу лучше и оптимальней, чем было заложено в алгоритмы динамической конфигурации SQL Server 7.0, но фишка в том, что он худо-бедно умел справляться с этим сам с минимальным участием DBA. Вероятно, мы слишком обожествляем ту область, в которой варимся. Все программирование в целом - не более чем средство автоматизации задач бизнес-логики. Поэтому машинные коды сменились ассемблерами, те - высокоуровневыми языками программирования и т.д. На смену C++ пришел C# с автоматической сборкой мусора и другими наворотами. Нет слов, С++ много гибче в плане управления памятью, но человек есть человек - забыл освободить объект и готова утечка памяти. Поди найди ее потом, когда это погребено под тоннами кода. Т.е. требуется держать в голове не только цель (бизнес-логику), но и специфичные вещи более низкого уровня. Конечно, программист на С++ прекрасно разберется и с C#, знания лишними не бывают. Его низкоуровневые знания дадут ему возможность не только более быстро освоить, но и писать более красивые программы. Но он растворится в лавине новичков, которым просто не нужны его знания, чтобы добиваться цели при помощи нового инструмента. (Пусть и несколько коряво с точки зрения патриарха). Мораль: мы с Вами - динозавры и вымрем в скором времени к чертовой матери. Не то, чтобы я слишком испереживался по этому поводу (против эволюции не попрешь), так - слегка выплеснуть эмоции. Не взыщите.