SpinxQL PDO LIMIT

[new_forward]

Доброго времени суток, использую PDO для запросов, все норм, только вот если LIMIT 0,35

$conn = new PDO( 'mysql:host=127.0.0.1;port=9306;', 'user', 'pass' );
$query_data = $conn->query("SELECT * FROM index WHERE approve='1' AND allow_main='1' ORDER BY id DESC LIMIT 0,35");
$result = $query_data->fetchAll(PDO::FETCH_ASSOC);
print_r($result);

Как только ofsset > 0.... LIMIT 35,35 , уже ничего не возвращает... в чем изюм?

Ошибочка, только что проверил даже с нулевым возвращает пустой массив. Версия сфинкса :

Sphinx 2.2.11-id64-release (95ae9a6)
Copyright (c) 2001-2016, Andrew Aksyonoff
Copyright (c) 2008-2016, Sphinx Technologies Inc (Для просмотра ссылки Войди или Зарегистрируйся)

Пробовал вставить в конфиг max_matches, так ругается....

 

[Black Hat]

С консоли:

mysql --port=9306 --host=127.0.0.1

Затем

SELECT * FROM index WHERE approve='1' AND allow_main='1' ORDER BY id DESC LIMIT 0,35
SHOW META;

выхлоп сюда

 

[new_forward]

Выхлоп:

ERROR 1064 (42000): index index: unsupported filter type 'string' on int column

Спасибо!!!

 

[new_forward]

Доброго времени суток, это опять я.... запрос с большим офсетом не проходит:

MySQL [(none)]> SELECT * FROM index WHERE approve=1 AND allow_main=1 ORDER BY id DESC LIMIT 349965,35;
ERROR 1064 (42000): offset out of bounds (offset=349965, max_matches=1000)

Добавил:
OPTION max_matches=10000000

Заработало, но sphinx начал есть процессор....

Если сравнить выполнение одного и того же запроса в MySQL = 0.5617s и Sphinx = 1.36s


Вообще хочу сделать пагинацию.... но что то наверно не получиться...

 

[Black Hat]

Проблема решена?
349965/35=9999 страница поиска. Она вам точно нужна? Сделайте "на следующую страницу результатов" чтобы не думать о пагинации.
У мускула банально лимит памяти мог быть больше, а сфинкс возился с подкачкой из файлов. В цикле загрузите по очереди обе базы на выполнение запросов и смотрите `sudo iotop` а также потребление памяти через top или htop.
Какое значение из конфига docinfo? Для хранения в памяти и скорости должно быть extern

Search-time memory requirements for extern storage are (1+number_of_attrs)*number_of_docs*4 bytes, ie. 10 million docs with 2 groups and 1 timestamp will take (1+2+1)*10M*4 = 160 MB of RAM. This is PER DAEMON, not per query. searchd will allocate 160 MB on startup, read the data and keep it shared between queries. The children will NOT allocate any additional copies of this data.

Ну и какой-то странный способ использования Сфинкса. У него хорошо с индексами по нативному языку, а вот другие индексы могут работать хуже чем у Мускула.
Про Сфинкс 3 Аксенов говорил, что будет в 2 раза быстрее, чем во втором.

 

[new_forward]

Проблема не решена, так как мускул быстрее работу делает... будем ждать 3 версию.

Если даже делать:

SELECT id FROM index WHERE approve=1 AND allow_main=1 ORDER BY id DESC LIMIT 349965,35 OPTION max_matches=350000;

Получается 0,58

 

[Black Hat]

Что его ждать? Он уже есть Для просмотра ссылки Войди или Зарегистрируйся
Потом зачем в Сфинкс кидать работу мускула? Он не для этого заточен

 

[new_forward]

В начале темы думал по другому. Теперь только один вариант, это разбитие огромной таблицы на много 100000 записей в каждой... тогда офсет маленький будет....

Кстати если сделать на сфинксе индексы по 100000, на время обработки вообще не влияет.... видимо точно только под поиск заточен.