01-25-2021, 03:50 PM
Esta línea está en c.posts.php --> inc --> class --> c.posts.php en la función getPost. (esta consulta actualiza la fecha de visita del usuario logueado al post)
El problema es que después de que el sitio tenga suficiente tiempo online o muchísimas visitas, esta tabla w_visitas llega a tener millones de registros y cuando una tabla así no está indexada tiende a hacer una consulta "FULL SCAN" por lo que básicamente tiene que recorrer todos los registros para poder finalizar su tarea, y en el caso del sitio de pruebas tiene más de 2 millones de registros.
Entonces, para todos aquellos que quieran evitar este pequeño problema de rendimiento a futuro cuando tengan muchas visitas o si ya se les presenta el caso, la solución es ir a su base de datos y ejecutar la siguiente consulta:
Y listo, eso soluciona el problema.
Para que se hagan una idea de los resultados, esta es una consulta antes de agregar el indice:
Y esta es la misma consulta después de agregar el índice:
Estamos hablando de una absurda reducción de 91150% de acuerdo al tiempo de ejecución de MySQL pero realmente pasamos a un tiempo de carga del sitio de unos 6 segundos aprox. a menos de 1 segundo.
Bueno, es un índice que debería ir por defecto en el .sql con el que se instala el script para evitar ese inconveniente a futuro. Seguramente algunas otras secciones críticas del script con el pasar del tiempo y vayan creciendo necesitarán de estos índices para mejorar los tiempos de consulta de la base de datos.
Creditos: Kmario19
Código PHP:
db_exec(array(__FILE__, __LINE__), 'query', 'UPDATE `w_visitas` SET `date` = \''.time().'\', ip = \''.$tsCore->getIP().'\' WHERE `for` = \''.(int)$post_id.'\' && `type` = \'2\' && `user` = \''.$tsUser->uid.'\' LIMIT 1');
El problema es que después de que el sitio tenga suficiente tiempo online o muchísimas visitas, esta tabla w_visitas llega a tener millones de registros y cuando una tabla así no está indexada tiende a hacer una consulta "FULL SCAN" por lo que básicamente tiene que recorrer todos los registros para poder finalizar su tarea, y en el caso del sitio de pruebas tiene más de 2 millones de registros.
Entonces, para todos aquellos que quieran evitar este pequeño problema de rendimiento a futuro cuando tengan muchas visitas o si ya se les presenta el caso, la solución es ir a su base de datos y ejecutar la siguiente consulta:
Código PHP:
ALTER TABLE `w_visitas` ADD INDEX (`for`, `type`, `user`);
Y listo, eso soluciona el problema.
Para que se hagan una idea de los resultados, esta es una consulta antes de agregar el indice:
[img]Registrate o inicia tu sesión para ver este contenido[/img]
Y esta es la misma consulta después de agregar el índice:
[img]Registrate o inicia tu sesión para ver este contenido[/img]
Estamos hablando de una absurda reducción de 91150% de acuerdo al tiempo de ejecución de MySQL pero realmente pasamos a un tiempo de carga del sitio de unos 6 segundos aprox. a menos de 1 segundo.
Bueno, es un índice que debería ir por defecto en el .sql con el que se instala el script para evitar ese inconveniente a futuro. Seguramente algunas otras secciones críticas del script con el pasar del tiempo y vayan creciendo necesitarán de estos índices para mejorar los tiempos de consulta de la base de datos.
Creditos: Kmario19