I'm using mysql on a windows development machine, and all was good for a long time.

But today my PC was running slowly, and I noticed mysqld.exe is using between 25% and 40% CPU.

I've tried rebooting and giving it some time, but the CPU usage is fairly constant even when idleing on the desktop. I've noticed the hard drive is working quite hard too, probably because of mysqld

I'm certain nothing is using the server as the only thing that would connect to it is the application on my local machine that I am developing, and that is not running.

But, just to be sure I ran the following statements

C:\Program Files\MySQL\MySQL Server 5.6\bin>mysqladmin -u root -p status
Enter password: **********
Uptime: 995  Threads: 1  Questions: 2  Slow queries: 0  Opens: 67  Flush tables: 1
Open tables: 60  Queries per second avg: 0.002

C:\Program Files\MySQL\MySQL Server 5.6\bin>mysqladmin -u root -p processlist
Enter password: **********
| Id | User | Host           | db | Command | Time | State | Info             |
| 2  | root | localhost:1775 |    | Query   | 0    | init  | show processlist |

which also seem to show the sever isn't doing anything.

So, what gives? What is mysqld doing?

Edit: I did recently kill an update statement that was taking a long time. Could this have anything to do with it?

2 Answers 2


It's probably good that you added that afterthought, because that's very likely what you're experiencing... the server is rolling back the work it had already done before you killed the large update.

If a big transaction is slowing down server performance, rolling it back can make the problem worse, potentially taking several times as long to perform as the original DML operations.

Even after a reboot? Yes...

Killing the database process does not help, because the rollback starts again on server startup.


InnoDB saved the data in the rows it was changing, and queries against that changes that are still being rolled back should be answered transparently using the data that's still in the undo log.

You'll probably also find the large amount of disk activity is associated with mysqld:

$ sudo apt-get install iotop
$ sudo iotop

There is a way to dispense with a runaway rollback, also explained at the link I've cited for the quotes, above... but your safest bet is to just let it churn for a while.

  • Thanks, this is most likey what was going on. I left it on overnight and CPU usage has finaly returned to normal. Thanks for your help!
    – Derek
    Jun 25, 2014 at 15:32
  • This is what happens to my DBs now ... high CPU usage with nothing in process list after a kill statement, AND high disk IO. My poor NVME hates me.
    – adrianTNT
    Jul 13, 2022 at 19:23

Yes, your kill statement is the likely cause.

The command SHOW PROCESSLIST will only show you what is happening in foreground threads. InnoDB is likely rolling back the transaction in the background. Some diagnostics you might find useful:

  • SHOW ENGINE INNODB STATUS - see what is happening inside of InnoDB. Under 'TRANSACTIONS' you should see your killed staetment being rolled back.

  • SELECT * FROM performance_schema.threads - show all threads in MySQL.

  • MySQL Workbench 6.1 includes Performance Schema Reports, exposing some of this data in a visual form.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.