Qué campo debería indexar?

[ldp]

Perdonen que no haya mirado más en el foro, pero me urge mucho una respuesta, ahora iré informándome.

Me gustaría saber qué campo debería indexar en una tabla que me da problemas de uso excesivo de CPU. Voy a intentar explicar cómo es la tabla. La tabla almacena los enlaces que mandan los usuarios donde se guarda el nombre, dirección, descripción y también los votos. Estos enlaces vienen después mostrados en orden por los votos. Los votos son un número entero, no tiene que hacer más operaciones que poner por orden descendente.

Pero no sé si debería indexar el campo con los votos para que no me dé problemas, qué opinan?

EDITO: La tabla tiene poco más de 100 registros. Por si sirve de algo, aquí dejo la estructura de la tabla:

Código:

CREATE TABLE IF NOT EXISTS `links_page` (
  `link_id` int(10) unsigned NOT NULL auto_increment,
  `link_name` varchar(30) NOT NULL,
  `link_url` varchar(200) NOT NULL default '',
  `link_version` varchar(200) NOT NULL default '',
  `link_realmlist` varchar(100) NOT NULL default '',
  `link_cuenta` varchar(200) NOT NULL default '',
  `link_estadist` varchar(200) NOT NULL default '',
  `link_expe` varchar(40) NOT NULL default '',
  `link_lugar` varchar(30) NOT NULL default '',
  `link_description` text NOT NULL,
  `link_button` varchar(100) NOT NULL default '',
  `link_category` tinyint(3) unsigned NOT NULL default '0',
  `link_order` int(10) unsigned NOT NULL default '0',
  `link_refer` int(10) unsigned NOT NULL default '0',
  `link_open` tinyint(1) unsigned NOT NULL default '0',
  `link_class` tinyint(3) unsigned NOT NULL default '0',
  `link_datestamp` int(10) unsigned NOT NULL default '0',
  `link_author` varchar(255) NOT NULL default '',
  `link_numvotos` int(10) unsigned NOT NULL default '0',
  `link_votantes` text NOT NULL,
  PRIMARY KEY  (`link_id`),
  UNIQUE KEY `link_realmlist` (`link_realmlist`),
  UNIQUE KEY `link_name` (`link_name`),
  UNIQUE KEY `link_url` (`link_url`),
  UNIQUE KEY `link_author` (`link_author`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=283 ;

[Genetix]

Todo campo que se encuentre dentro de los WHERE es candidato a indexarse, puedes empezar por ahi.
También puedes usar explain para poder para optimizar tus consultas

[ldp]

Lo siento, pero no sé muy bien cómo usar el EXPLAIN. La consulta que causa los problemas es:

Código:

SELECT l.*
FROM #links_page AS l
LEFT JOIN #links_page_cat AS lc ON lc.link_category_id = l.link_category
WHERE l.link_class REGEXP '".e_CLASS_REGEXP."' AND lc.link_category_class REGEXP '".e_CLASS_REGEXP."' ".$cat."
GROUP BY l.link_id
ORDER BY link_numvotos

El únicco WHERE que hay no creo que sea el causante, lo que hace es sacar los enlaces de la categoría.

[jurena]

Una pregunta: ¿por qué usas regexp? Al parecer las expresiones regulares no hacen uso de los índices. Yo te diría que antes que nada, si puedes hacer esas búsquedas con LIKE o =, la hagas así y, como te ha dicho Genetix, indexes esos campos que busques con el where...
Y por otra parte tal vez la búsqueda la tendrás que hacer tras el group by y usando having...
Mira a ver si es algo de eso.

[ldp]

No me preguntes eso del regexp porque esa parte no la he programado yo, pero sí te digo que probé con like y = pero no funcionaban.

Sobre lo de indexar, hay algún peligro? Es reversible? Serían 2 campos: 1 que da la categoría del enlace donde todos los registros son iguales porque sólo hay una categoría (al menos por ahora) y el otro campo decide si mostrar o no el enlace. Importa que el indice se haga sobre una columna con campos todos iguales?

Sobre el GROUP BY, la verdad es que no sé para qué sirve, si está ordenado por votos no le encuentro la necesidad de agrupar por id, sobre todo porque las ids no se pueden repetir.

EDITO: estoy probando con el código así:

Código:

SELECT l.*, lc.*
FROM #links_page AS l
LEFT JOIN #links_page_cat AS lc ON lc.link_category_id = l.link_category
WHERE l.link_class = 0 AND lc.link_category_class = 0
ORDER BY numvotos

Pero sin poder medir los recursos que consume es muy difícil decir si va mejor o no.

[jurena]

ponle delante a esa consulta y también a la otra esto:
EXPLAIN
te quedaría EXPLAIN SELECT...
y luego mira el resultado. Si no lo sabes interpretar, cuélgalo aquí y alguien con experiencia te echará una mano. De todas formas, creo que es importante que conozcas todo el proceso antes de hacer cambios. Me explico, si tú no lo has programado y el resultado era el esperado y ahora con los cambios no, está claro que lo primero que deberías saber es exactamente lo que quieres que haga la consulta y ponernos algún ejemplo con datos concretos. No me parece a mí que una consulta de este tipo con 100 registros pueda suponer ningún problema para la CPU. Ponnos un ejemplo más concreto a ver si resolvemos el problema...

[ldp]

El ejemplo más concreto que te puedo dar es que lo veas en mi web. Esta es la página que causa problemas: http://gratiswow.com/e107_plugins/li...inks.php?cat.1. Probablemente es una de las páginas de mi web con más visitas.

EDITO2: Me ha venido la duda de que el problema no fuera del renderizado de la lista, sino de cualquier otro módulo, así que he medido el tiempo con la página como era originalmente, de la página sin el módulo en cuestión y de la página sin el módulo y con el SELECT como me habéis aconsejado. Después de medir los tiempos de ejecución en la web obtengo esto:

- PÁGINA ORIGINAL:
Tiempo de renderizado: 0.7787 seg, 0.5029 de éstos para llamadas sql. Llamadas sql: 79. Uso memoria: 2,972kb
Tiempo de renderizado: 0.2813 seg, 0.1595 de éstos para llamadas sql. Llamadas sql: 79. Uso memoria: 2,972kb
Tiempo de renderizado: 0.2999 seg, 0.1732 de éstos para llamadas sql. Llamadas sql: 79. Uso memoria: 2,979kb
Tiempo de renderizado: 0.7641 seg, 0.6361 de éstos para llamadas sql. Llamadas sql: 79. Uso memoria: 2,979kb

CON FUNCIÓN ORIGINAL y SIN EL MÓDULO:
Tiempo de renderizado: 0.2490 seg, 0.1423 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,888kb
Tiempo de renderizado: 0.1145 seg, 0.0049 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,888kb
Tiempo de renderizado: 0.1128 seg, 0.0053 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,888kb
Tiempo de renderizado: 0.1611 seg, 0.0097 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,888kb

FUNCION OPTIMIZADA Y SIN EL MÓDULO:
Tiempo de renderizado: 0.1284 seg, 0.0082 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,887kb
Tiempo de renderizado: 0.1645 seg, 0.0104 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,887kb
Tiempo de renderizado: 0.1088 seg, 0.0048 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,887kb
Tiempo de renderizado: 0.1544 seg, 0.0146 de éstos para llamadas sql. Llamadas sql: 40. Uso memoria: 2,887kb


Podría concluir que el problema era del módulo o no tiene relación con el consumo de CPU?