Estoy buscando ayuda para comprender qué sucede cuando se ejecuta la siguiente línea de comando:

root@prodn$ service mysqld stop

Sí, apaga el servidor MySQL, por lo que el acceso a él ya no está disponible hasta que el servicio se inicia nuevamente. Sin embargo, más específicamente, ¿ocurre algo más cuando se detiene el servicio? Perdone mi novacidad aquí, pero cuando mysqld se reinicia, ¿significa que se borraron los registros, se liberó algo de memoria, se vaciaron las cachés, etc.?

La razón por la que pregunto es la siguiente:

Nuestra base de datos de almacenamiento de datos es una base de datos MySQL y en los últimos 4 meses, ha tomado un promedio de 8.5 horas.

El miércoles pasado, detuve el servicio mysql y luego lo reinicié después de 30 minutos. Desde entonces, comienzo a notar una mejora masiva en el rendimiento general : los procesos SELECT / INSERT / UPDATE / DELETE fueron más eficientes. DW terminó casi 4 horas antes con la misma cantidad de filas de datos

Sin embargo, con cada día que pasa, de 15 a 20 minutos se agrega de alguna manera a la hora de finalización. Por lo tanto, sospecho que es posible que deba reiniciar el servicio semanalmente.

¿Hay alguna explicación para este comportamiento? No sé qué otras preguntas son relevantes, pero sería genial saber qué sucede cuando se mysqldreinicia el servicio.

¿Alguien puede arrojar algo de luz sobre esto, por favor?

Cuando emite service mysql stop, sucede mucho más que simplemente cortar la conectividad de DB. El enlace en el comentario de @ethrbunny ya explica qué sucede.

Me gustaría centrarme en un aspecto particular: el InnoDB Buffer Pool. InnoDB tiene que vaciar las páginas sucias del InnoDB Buffer Pool. Si desea saber cuánto, ejecute esto antes de apagar:

SELECT CONCAT(dpbytes/power(1024,expo),' ',SUBSTR(units,expo*2+1,2)) DirtyPages FROM
(SELECT dpbytes,FLOOR(LOG(dpbytes)/LOG(1024)) expo FROM
(SELECT dirty_pages*page_size dpbytes FROM
(SELECT VARIABLE_VALUE dirty_pages FROM information_schema.global_status
WHERE VARIABLE_NAME='Innodb_buffer_pool_pages_dirty') AAA,
(SELECT VARIABLE_VALUE page_size FROM information_schema.global_status
WHERE VARIABLE_NAME='Innodb_page_size') BBB) AA) A,(SELECT ' BKBMBGBTB' units) B;

Esto le indicará cuántos datos se deben vaciar del InnoDB Buffer Pool.

Tenga en cuenta que InnoDB tiene muchas partes móviles en el espacio de tabla del sistema (el archivo ibdata1). Haga clic aquí para ver la representación pictórica de toda la infraestructura de InnoDB .

Parte de la información transaccional está escrita de tal manera que Crash Recovery se realiza cuando se ejecuta service mysql start.

OPCIONAL

Puede obtener todos los datos vaciados y todas las transacciones confirmadas limpiamente desde ibdata1 y los Registros de transacciones ( ib_logfile0, ib_logfile1) ejecutando esto

SET GLOBAL innodb_fast_shutdown = 0;

antes de correr

service mysql stop

Darle una oportunidad !!!

ACTUALIZACIÓN 2013-04-24 07:17 EDT

Dado que tiene MyISAM como el motor de almacenamiento principal, lo único que sucede es el vaciado de los cambios de índice en todos los .MYIarchivos que tienen cambios pendientes.

También me gustaría recomendar que la próxima vez que cierre mysqld, ejecute esto de antemano en otra sesión:

tail -f /var/log/mysqld.log

y mire los mensajes que pasan y vea que le dice qué está haciendo mysqld con cualquier motor de almacenamiento. Si no tiene absolutamente ninguna tabla InnoDB en uso, debería pensar en deshabilitar InnoDB con

[mysqld]
skip-innodb

ya que esto permitirá un inicio más rápido y posiblemente un apagado más rápido.