MYSQL: Parallel execution of multiple statements within a stored procedure?

I have a procedure (procedureA) that loops through a table and calls another procedure (procedureB) with variables derived from that table.

Each call to procedureB is independent of the last call.

When I run procedureA my system resources show a maximum CPU use of 50% (I assume that is 1 out of my 2 CPU cores).

However, if I open two instances of the mysql terminal and execute a query in both terminals, both CPU cores are used (CPU usage can reach close to 100%).

How can I achieve the same effect inside a stored procedure?

I want to d开发者_如何学编程o something like this:

BEGIN
    CALL procedureB(var1); -> CPU CORE #1
    SET var1 = var1+1;
    CALL procedureB(var1); -> CPU CORE #2
END

I know its not going to be that easy... Any tips?

---

Within MySQL, to get something done asynchronously you'd have to use an CREATE EVENT, but I'm not sure whether creating one is allowed within a stored procedure. (On a side note: async. inserts can of course be done with INSERT DELAYED, but that's 1 thread, period).

Normally, you are much better of having a couple of processes/workers/deamons which can be accessed asynchronously by you program and have their own database connection, but that of course won't be in the same procedure.

---

You can write your own daemon as a stored procedure, and schedule multiple copies of it to run at regular intervals, say every 5 minutes, 1 minute, 1 second, etc.

use get_lock() with N well defined lock names to abort the event execution if another copy of the event is still running, if you only want up to N parallel copies running at a time.

Use a "job table" to list the jobs to execute, with an ID column to identify the execution order. Be sure to use good transaction and lock practices of course - this is re-entrant programming, after all.

Each row can define a stored procedure to execute and possibly the parameters. You can even have multiple types of jobs, job tables, and worker events for different tasks.

Use PREPARE and EXECUTE with the CALL statement to dynamically call stored procedures whose names are stored in strings.

Then just add rows as needed to the job table, even inserting in big batches, and let your worker events process them as fast as they can.

I've done this before, in both Oracle and MySQL, and it works well. Be sure to handle errors and log them somewhere, as well as success, for that matter, for debugging and auditing, as well as performance tuning. N=#CPUs may not be the best fit, depending on your data and the types of jobs. I've seen N=2xCPUs work best for data-intensive tasks, where lots of parallel disk I/O is more important than computational power.