Это не имеет значения применительно к real_query() по идее. limit 0 втыкаю больше как амулет, потому что упомянутая функция не выдает результата вообще. Там даже num_rows отсутствует, или всегда равен 0, я уже забыл, проверять лень. Чтобы проверить будет вообще результат запроса или нет - надо проверять filed_count, потому что и affected_rows молчат как рыба об лед.

В подробности не вдавался, но суть real_query() по-видимому сводится к перемещению курсора на сервер. Я когда начал майсклю осваивать не мог найти где у них опции этого самого курсора, решил что нету и забил, начал юзать как все - query(). К счастью вспомнил. В PDO вроде есть опции курсора, но PDO мне не стучит.

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

---

Кто там писал что мне запросы писать лень - не лень. На прямой - 3 тире 4 штуки, а на кривой по обстоятельствам еще может быть полдюжины вспомогательных. Это в заднем проходе такие мероприятия - в том самом backend'е. На фроне все в точности наоборот. В моделе может быть один витиеватый запрос вплоть до хмтля в нем.

Ну вообще то, если бы вы читали, в чем проблема с этой директивой (была, по крайней мере), то такого вопроса бы не задали (поскольку проблема в full table scan'е, что никак не связано с джойнами и сортировками ). Я, в принципе, верю, что mysql наконец исправили жуткую хрень с SQL_CALC_FOUND_ROWS (http://forums.mysql.com/read.php?115,29576...6739#msg-296739) только потому что проблеме уже 100 лет в обед. Проверьте это на таблице с миллионами записей и энным количеством текстовых полей, и сравните с count + query. С индексом и без. Когда я проверял это последний раз (все так же потому что кто-то здесь решил, что верно обратное), разница была просто чудовищной.

http://www.mysqlperformanceblog.com/2007/0...alc_found_rows/

Потренировался на том самом шопе. В отличии от схемы автора цитаты, там как я уже писал, много полей, а именно 14, и основная часть - текст (не варчар, текст).

Ну вот, запрос с sql_no_cache лимитом на 30 записей дает 0.00 - 0.01 с, такой же запрос еще и с подсчетом sql_cacl_found_rows дает 0.01 - 0.00, запрос на подсчет без лимита 1 поля которое пк, дает 0.01 - 0.02 с.

В табле 15К записей на 14 полей. Разумеется что если поменять where то циферки поменяются, но пока что ничего криминального я не заметил.

Нашел сообщение об упомянутом баге, самое свежее сообщение за 2009 год, первое за 2006. Что стало с тех пор - не знаю. Но все летает как из пушки как видите.

Про миллион записей я не думал, начну когда будет миллион.