Mucho cuidado con este tipo de usos porque no siempre funcionará bien, por ejemplo tu dices que para contar la cantidad total de registros haces esto:
$ssql = "select * from pais " . $criterio;
Si haces eso en una base de datos transaccional con varios cientos de miles de registros tu consulta se puede demorar facilmente hasta unos 7 o 15 segundos dependiendo del hardware del servidor sin mencionar que vas a utilizar muchisima memoria ram para poder almacenar tu resultado en una tabla temporal y poderla leer.
En estos casos se pueden hacer varias cosas:
Primero que nada nunca usar asterisco para contar registros porque puedes tener campos que no necesariamente están en el índice de la base de datos, asi que si vas a contar debes contar índices:
SELECT COUNT(id) FROM pais WHERE ...
MySQL tiene un registroi propio con la cantidad de índices por tabla asi que una consulta sin condicionales (sin wheres) te va a arrojar un resultado instantaneo porque no cuenta nada, solo te retorna el número que tiene guardado en una variable de conteo interno.
Ahora, cuando haces un where el tema es distinto, digamos que tu consulta arrojó 300 mil resultados, entonces mysql tendrá que mandar a una tabla temporal en memoria de 600 mil registros, uno con tu conteo y otro con tu resultado (independiente del limit ya que el limit se resuelve después de toda la selección), por lo tanto tu consulta puede tardar muchisimo tiempo si tienes una cantidad considerable de columnas como por ejemplo los datos de una persona v/s los datos de una empresa, ahora si haces joins olvidate, puedes estar pegado esperando por lo menos de 30 a 60 segundos que resuelva.
Para prevenir estas situaciones se utiliza el argumento "SQL_CALC_FOUND_ROWS" el cual se encarga de enviar a una variable la cantidad de registros de tu consulta evitando tener que hacer dos consultas.
Por ejemplo:
SELECT SQL_CALC_FOUND_ROWS * FROM pais WHERE ... LIMIT 0, 10
Eso te retornará los primeros 10 registros de tu búsqueda, ahora desde una segunda consulta sql obtienes el valor de la cantidad de registros que habian:
SELECT FOUND_ROWS()
Y te devolverá la cantidad exacta de registros sin considerar la propiedad limit, como por ejemplo 300 mil.
Otro tema es acelerar las búsquedas indexando columnas y utilizando la propiedad fulltext para la indexación de campos, tablas de caché temporal para busquedas muy grandes con muchos joins, etc.
Un buén amigo mio una ves me dijo que cuando uno necesita hacer busquedas en bases de datos transaccionales con muchos miles o millones de registros necesitaba utilizar servidores de búsqueda y no hacer las consultas directamente hacia la base de datos, como por ejemplo apache solr (
http://lucene.apache.org/solr/ ), pero como yo soy porfiado utilizo tablas en memoria (si, mysql soporta tablas en memoria que son ultra rápidas) el cual contiene todas mis busquedas.
Por ejemplo yo necesito buscar un médico y en el campo de texto puedo buscar por nombre, apellido, especialidad, localización, nombre del centro médico y en cualquier orden. Ahora, imaginense cuantos joins debo hacer, aproximadamente 18 donde cada una tiene alrededor de 400 mil registros con campos de tipo text (gigantes) los cuales no puedo indexar por su tamaño y la cantidad de columnas son alrededor de 20 por tabla. En este caso yo tengo una tabla llamada cache_busqueda el cual tiene el campo id, usuario_id, payload, orden_natural, entonces yo tengo esta consulta SQL con muchos joins en un php llamado mantenedor el cual cuando lo hago correr me hace la consulta que se demora varios minutos y procesa uno por uno los medicos tomando todos los datos y uniendo todos los valores en un solo campo de tipo text en la columna "payload", luego lo unico que debo hacer cuando quiero buscar un médico es hacer un like a esa columna y ordenar por la columna orden_natural el cual tiene una serie de reglas como por ejemplo "comienza con la letra A si tiene una foto, continua con la letra A si tiene x campo, luego el apellido y luego el nombre", de esta manera se ordenan alfabeticamente y prioriza los que tienen fotos, pero la consulta de búsqueda no ordena nada, el orden es natural de la tabla asi que el motor ya no tiene que ordenar 400 mil registros y se ahorra mucha memoria, tampoco debe hacer joins ni nada.
Ahora, esa selección que yo hago solo obtengo el id del usuario medico y luego con esos 10 items retornados los cargo completamente, nombres, edad, sexo, etc etc.
Para mantener esta tabla viva lo que hago es actualizarla cada ves que se actualiza un medico, pero solo actualizo ese registro, no toda la tabla y eso no se demora mas de 0.01 segundos asi que jamás pierdo la integridad de los datos.
Esto me da la ventaja de hacer consultas grandes en servidores pequeños, con 400 mil registros una busqueda de esta magnitud no me demora mas de 1 segundo en un servidor compartido con una cpu doble nucleo.
--------
Terminando con el post, quiero decir que esta es una manera extrema de llevar el rendimiento de una búsqueda SQL, ustedes si tienen la posibilidad de utilizar un servidor optimizado para búsquedas, haganlo.
Saludos.
Mostrar Mensajes
a pesar de las actualizaciones, incluso siento que con el tiempo anda cada ves mas rápido.
, en el video aparece el que canta con un instrumento que parece cuerno y muestran a un hombre y a una mujer caminando hacia atras por toda una ciudad hasta que al final del videoclip se encuentran y comienzan a bailar 
yo ya lo busqué en youtube, googleé bastante y no pillo nada 