задача такая:
в таблице есть поле param - целочисленное, не уникальное, значения не последовательные
имеем переменную n, произвольное целое число
есть переменная id, содержащая значение соответствующего элемента таблицы

необходимо:
произвести выборку (2*n)+1 строк из таблицы, так, чтобы был выбран рядок с соотв. id + n перед ним и n за ним с сортировкой по param
т.е., к примеру, пусть будут такие param:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
n=3
id=13
результат выборки должем быть таким:
10 11 12 13 14 15 16 
при этом, сумма строк должна быть (2*n)+1, т.е., если сделаем id=1, то с n=3 должно быть:
1 2 3 4 5 6 7

собственно, задача не сложная, на mysql+php решения очевидные, сделал, хоть немного и некрасиво вышло... вот хотелось бы увидеть варианты решения от профи и не только, в частности интересует вариант решения данной задачи за счет согдания одного mysql запроса
просьба не забывать об обязательном условии выборки (2*n)+1 строк
всем заранее мои благодарности   

Добавлено через 1 минуту и 47 секунд
еще раз хочу обратить внимание, на то, что значения param
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
и столбец id - разные столбцы
id, кстати, уникальный, если это пригодится вдруг (но не обязательно последовательный)

Добавлено через 4 минуты и 5 секунд
и еще заодно напомню, что "param - целочисленное, не уникальное, значения не последовательные"
т.е., варианты, когда он будет выглядеть так:
543 6 7863763 4 7657 9746 53252 8585 423423
вполне реальны, нужно выбрать не просто соседние по id, а соседние с сортировкой по param

вот мне в голову пришло:

учитывая выражение в order by, никакой возможности задействовать индексы. запрос-убийца сервера, прям.

skyboy, ух ты! интересный запрос)) надо еще почитать мануальчиков по mysql
благодарю, правда, не работает 
при n=4, id=21 выдает:
id    param
49    8
40    23
41    13
42    14
35    21
34    11
33    1
53    20
54    19
хоть в таблице специально (для наглядности) сделал последовательные param
все верно, только что-то проблемка с сортировкой...


param в индексе... order by разве не работает с индексами??  или это относится к представленному выше варианту?

там выражение. order by <indexed_column> пройдется по индексу и все, а order by abs(<indexed_column>) без вычисления выражения только работой с индексом не определит, что (-2) должно "стоять" раньше "1". при том, что в индексе порядок все же -2,1.

возвращает мне 

что и ожидалось. тут ещё, я так понял, надо сортировку по id сделать?
и я не понял:

и тут же приводишь пример

в случае, если с одной стороны значения param будут идти по порядку, а с другой "стороны" с большим разрывом - то мой запрос действительно не вернет ожидаемого. и лучше сделать двумя разными запросами. каждый чтоб выбирал по 2n-1 записей, а потом силами клиентской стороны выбирать то или иное количество из каждой выборки.

Я бы пошёл по пути создания хранимой процедуры. В ней я бы в 2 временных таблицы скопировал бы
и соответственно <= и desc.
Затем посмотрел бы количество отобранных в каждую таблицу записей и, если хотя бы в одной записей менее n+1, вычислил, сколько из какой таблицы взять (если не меньше - то из каждой по n+1) - и вернул бы union рассчитанного количества записей выборок из этих временных таблиц.

Добавлено через 3 минуты и 5 секунд
PS. Само собой, если на границе оказывается несколько одинаковых param, то какие ID вернутся, а какие нет - фиг знает...

а надо так:
"3"    "3"
"4"    "4"
"5"    "5"
"6"    "6"
"7"    "7"


нет, сортировку по param, id тут нужен лишь для выборки "центральной" строчки



вот:

т.е., если есть возможность взять n-слева и n-справа с сортировкой по param - отлично, если с какой-то из сторон нет - берем сколько есть (0..n-1), разницу компенсируем за счет другой стороны, так чтобы в сумме было (2*n)+1...


я так и сделал... но это кривоватый способ - вначале определяем сколько есть строк в таблице слева нужного нам значения, выбираем если есть, выбираем справа, потом надо проверить сколько мы выбрали справа, если, вдруг, уперлись в правую границу, добираем 3-м запросом слева... не очень красиво  (можно было бы сразу проверять количество удовлетворяющих условиям строк справа-слева, но так не делаю, т.к. ситуации, когда упираемся в левую/правую границу не частые, т.е. так в итоге будет менее выгодно по ресурсам...)

просто чисто для себя хотелось бы увидеть более красивые варианты решения данной задачи   

Akina, тоже вариант, сам так думал     ща проведем эксперементы...))

эврика!



работает как надо.... осталось только добиться, чтобы....


  

всем мои благодарности, слушаю ваши идеи и предложения 
пошел дальше колдовать    

Добавлено через 1 минуту и 32 секунды
т.е. в крайних положениях этот запрос не выдает (2*n)+1, как яспо по лимитам.... и как-то модифицировать его в пределах разумного пока не представляется возможным.... будем копать