Solución:
En lugar de matar el proceso, sería más seguro si lo hiciera dentro de MySQL:
$ mysqladmin processlist -u root -p
Enter password:
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example | Sleep | 297 | | |
| 407 | root | localhost | | Query | 0 | | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
La consulta con ID 174 es la que bloquea la eliminación de la base de datos de ‘ejemplo’, por lo que antes de matar cualquier proceso, primero deje que MySQL intente terminar la consulta:
$ mysqladmin kill 174
Ejecutar el processlist comando anterior nuevamente para confirmar que fue eliminado.
Si esto no funciona, entonces quizás podría considerar matar el proceso errante, pero antes de eso, puede intentar reiniciar el servidor MySQL.
También puede ejecutar comandos como ‘SHOW FULL PROCESSLIST’ y ‘KILL 174’ en el shell de MySQL, por ejemplo, si solo tiene el cliente MySQL instalado. El punto principal es evitar matar el proceso usando ‘kill’ en el shell a menos que sea absolutamente necesario.
En términos generales, puede utilizar mysql o mysqladmin. Sin embargo, no debería necesitar ejecutar comandos como este con tanta frecuencia; una vez que comienza a eliminar las consultas con regularidad, algo definitivamente está mal y es mejor que solucione ese problema (eliminar el proceso de consulta es solo tratar el síntoma).
Aunque pensé que el proceso de importación había muerto, probablemente aún se estaba ejecutando.
los DROP DATABASE El comando probablemente esperó a que la base de datos terminara de importar antes de ejecutarse.
Entonces, en lugar de DROP DATABASE tomando mucho tiempo, probablemente fue solo la importación.
1.)
Si alguien más lee esto y está tratando de cancelar una importación de base de datos y eliminar la base de datos, le recomiendo que primero busque el PID (ID de proceso) para la importación y ejecute esto desde una terminal diferente:
$ kill [PID]
…dónde [PID] sería el PID real del proceso.
Debería ver que la importación se detiene inmediatamente si el otro terminal todavía está conectado.
2.)
También podrías correr SHOW PROCESSLIST en la pestaña phpMyAdmin SQL. La tabla resultante muestra los procesos en ejecución, y hacer clic en la ‘x’ junto a la fila que desea eliminar debería ser suficiente. Este sería el mismo efecto que la respuesta aceptada o matar al mysql proceso desde el mysql línea de comando.
Entonces corre
DROP DATABASE `database_name`;
Y todo debe estar limpio.
Otra respuesta sugirió que matar el proceso dentro de mysql es mejor que hacerlo desde fuera. No he probado esa respuesta, pero suena muy plausible. Así que la he marcado como la “respuesta aceptada” en lugar de esta.
Me enfrenté al mismo problema . Pero esta vez verifiqué mostrar lista de procesos; decía comprobar los permisos durante más tiempo. Luego descubrí que mysqld_safe se estaba ejecutando como root, mientras que los permisos de nivel de carpeta eran solo para el usuario de mysql. Por lo tanto, eliminé la consulta, por supuesto, me tomó mucho tiempo decir que estaba en estado eliminado, pero esperé a que reaccionara, luego eliminé la consulta y cambié los permisos de nivel de carpeta a la raíz también agregándolo al grupo y chmod a 770. Luego ejecuté la misma base de datos de caída, bla; funcionó para mí en 2 segundos para una base de datos de 20 GB.