В описании есть все подробности.

Да....
1. Спасибо.
2. Прочитал, но..., возможно мало виски выпил...
Во второй функции пример, надо полагать, сложного запроса.
И что такое не сложный запрос, где нет условий выборки?... (WHERE....)?

// Запрос 
    $res  = mysql_query("SELECT * FROM `table` WHERE `text` LIKE '%2%'");

Если я буду обрабатывать этот запрос первой функцией,
что не сработает?
Там стоит

 $result = mysql_query("SELECT COUNT(*) AS `cnt` FROM ". $table[1]);

Мне кажется, что в $table[1] будет стоять
`table` WHERE `text` LIKE '%2%.
И функцию SELECT SQL_CALC_FOUND_ROWS
с успехом выполнит обычный COUNT(*).
Где ошибка в моих рассуждениях?
То есть пока не понимаю - на черта эта вторая функция????

P.S.
Еще по ходу вопрос.

public function calcQuery($query) 
    {
        // Заменяем SELECT на SELECT SQL_CALC_FOUND_ROWS
        $query = preg_replace('#SELECT#i', 'SELECT SQL_CALC_FOUND_ROWS ', $query);

Это во второй функции.
Почему preg_replace используется,
а не substr_replace(), то есть зачем из пушки по воробьям...?

А что не так?

ну как, что... Возможно, тут ограничения пагинатора какие-то, но наличие одного-двух джойнов вовсе не значит, что нужно считать ряды SQL_CALC_FOUND_ROWS. SQL_CALC_FOUND_ROWS в сравнении с каунтом не использует индексы, а потому на больших выборках он все хуже и хуже становится. Используйте каунт, правильно стройте запрос и индексируйте таблицы

Вообще говоря единственное место, где я бы его мог посоветовать использовать - запросы на одну таблицу с условиями выборки, не покрытыми индексами. Хотя как по мне, то лучше покрыть их индексами и выбирать каунтом

Я это все прекрасно понимаю, я даже делал замеры и сюда выкладывал, лень искать.
Вот цитата из описания пагинатора:

glock18
Ну я помню нашу бталию на этот счет. Тут два момента. Я делал упор на простоту интеграции раз и касаемо сложных запросов и каунта ты меня тогд не убедил. Я потому и делал замеры. Я нашел ту тему, но к сожалению результаты были на картинке, а она не сохранилась.

Так вот. у меня большое сомнение, что повторный сложный динамически меняющийся многотабличный запрос, да еще если с вложенными запросами и попутными вычислениями, будет работать быстрее, чем SQL_CALC_FOUND_ROWS. Ведь дело не в том, что результатом будет COUNT(*). Все равно придется повторно объединять таблицы, делть эти вычисления и так далее. А SQL_CALC_FOUND_ROWS просто дошлепает до конца текущего запроса и выдаст результат. Могу ошибаться конечно, повторные замеры делать лень. Но интуиция подсказывает, что если даже это и медленнее, то не столь значительно для того, чтобы отказаться от интеграции одной строчкой.

1. Thanks за информацию.
2. Нет, сложный запрос, это допустим составной запрос. Из нескольких таблиц, с применением JOIN, UNION и так далее. В таком запросе невозможно подсчитать к-во строк в таблице. Таблиц то несколько и результат непредсказуем.
Все же с определениями не совсем идеально.
"это допустим составной запрос". Допустим..., значит еще какие-то
варианты сложного запроса имеются? Какие тогда?
2.1 В таком запросе невозможно подсчитать к-во строк в таблице
Видимо верно, если UNION использовать.
А если JOIN, то вроде без проблем.
А то что "Таблиц то несколько" мне кажется вообще роли не играет.
Какая разница скажем

SELECT b.id AS bd, b.name_sort AS bs,  b.name AS bn, b.year_begin,
						  b.year_end,b.name_2, b.music_kind, b.main_rating, b.rating_art,
                		  b.music_kind_2, c.name AS cn
                 FROM countries AS c, band AS b
                 WHERE  b.id_country = c.id 
				 AND (b.category = 1 OR b.category = 4)
				 AND year_end is not null
                 ORDER BY $sort $sort_asc";

и

SELECT count(*)
                 FROM countries AS c, band AS b
                 WHERE  b.id_country = c.id 
				 AND (b.category = 1 OR b.category = 4)
				 AND year_end is not null
                 ORDER BY $sort $sort_asc";

А... извините,
забыл имя-пароль ввести, предыдуший
Guest я был.

Vladimir67
Рзница в том, что придется выполнять два запроса. И большой разницы нет, получаем мы количество строк каунтом или значения полей. Запрос все равно должен выполниться. В случае с SQL_CALC_FOUND_ROWS сложный запрос выполняется один раз. Просто результат выдается по уровню лимита, а сам запрос продолжает выполняться полностью, пока не пройдет все строки. И потом мы вытаскиваем количество. Насколько я помню, это быстрее, чем второй запрос с каунтом.

Другой вопрос, что для подсчета строк можно использовать другой, более легкий запрос. Но это оправдано тогда, когда складывается ряд обстоятельств. Допустим огромные таблицы, тяжелые запросы, высокие нагрузки и достаточная квалификация программиста. В остальных случаях, а их наверняка больше 90% этим приростом скорости можно спокойно пренебречь в пользу простоты интеграции скрипта. А ставка делалась именно на это. Чтобы любой начинающий программист мог не мудрствуя лукаво двумя-тремя строчками внедрить пагинатор в действующую систему.

1. Ну, теперь, вроде, понятно...,но,
2. Возникла следующая мысля.
Сделали основной запрос, без лимитов, все равно какой-
простой, сложный, сверхсложный...
В результате есть таблица результатов.
Можно ведь теперь просто средствами PHP
посчитать кол-во строк, то есть получить тот же результат,
который дает нам COUNT(*) и в базу понятно никакая собака не лезет,
чтобы SQL_CALC_FOUND_ROWS или COUNT(*) использовать.
Что здесь не так?
3. Могу ли я (в смысле имею право) использовать данный пагинатор,
с небольшими изменениями на своем личном сайте (рок-музыка)?
Вроде усе, спасибо.

Akuchkovsky

Хм...
Ну а если таблица весит несколько гигов, её всю целиком в пыху тащить? А где набрать столько оперативки?

1. В моем PC 4 ГБ.
Я полагал, что на сервере (приличном) сейчас проблемы
с опер. памятью практически отсуствуют.
2. Данные из базы берутся (речь о PHP, разумеется),
чтобы далее клиентам через браузер выдать.
Какой же разработчик будет десятки, сотни тысяч строк
в одном запросе на юзера вываливать?
3. Спасибо за пагинатор-класс,
как руки дойдут, всобачу в сайт (кое-как доделываю),
потом похвастаюсь.....

Twin
Надеюсь просто тупая описка здесь

/**
* Constructor
* @param int $page
* @param int $rows 
* @param int $columns 
*/    
    public function __construct($page = 1, $rows = 1, $columns = 1) 
    {
        if($rows > 1)
            $this->NumPage     = (int)$page;    
    
        if($rows > 1)
            $this->NumRows     = $rows;

        if($columns > 1)
            $this->NumColumns  = $columns; 
            
                  
    } 

В первой строчке должно быть

 if($page > 1)
            $this->NumPage     = (int)$page;    

И еще

 public function createLimit()
    { 
     
        $this->TableTotal = intval(($this->TableCount - $this->NumColumns) / $this->NumRows * $this->NumColumns) - 1;
          
        if($this->NumPage < 1) 
            $this->NumPage = 1;
            
        if(empty($this->TableTotal) || $this->TableTotal < $this->TableCount)
            $this->TableTotal = $this->TableCount;
                          
        if($this->NumPage > $this->TableTotal) 
            $this->NumPage = $this->TableTotal; 
              
        $start = $this->NumPage * $this->NumRows * $this->NumColumns - $this->NumRows * $this->NumColumns;
         
        if($start < 0)
           $start = 0;
             
        return ' LIMIT '. $start .', '. $this->NumRows * $this->NumColumns;
       
    }

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

 if(empty($this->TableTotal) || $this->TableTotal < $this->TableCount)
            $this->TableTotal = $this->TableCount;

Мне кажется его спокойно можно
к чертям собачьим......
Или чего-то не учитываю?