The answer is yes – kind of.

Stored procedures are implemented in a MySQL Server and can be used regardless of the storage engine being used for a specific table. One inference from this is that they won’t work when accessing the Cluster database directly through the NDB API.

This leads to the question of whether or not that limitation actually restricts what you can achieve. This article gives a brief introduction to stored procedures and looks at how the same results can be achieved using the NDB API.

Stored procedures provide a rudimentary way of implementing functionality within the database (rather than in the application code). They are implemented by the database designer and have the ability to perform computations as well as make changes to the data in the database. A typical use of stored procedures would be to control all access to the data by a user or application – for example, to impose extra checks on …

Last time I demonstrated a case where stored procedures are slow.  There were a few comments that I should include selects in the stored procedure to make the tests  more realistic.  From experience I already knew the answer so I didn’t go into that level of detail, but since stored procedures are all about database access this is a reasonable comment. 

This is a simple stored procedure that selects data and then summarizes it by customer.  No one would actually write this as it is far too easy to use a SQL statement instead.    Assume the logic is more complex and can’t be done easily by the standard SQL techniques of case statements, temp tables, etc, and then this makes more sense.  

The end result is this stored procedure takes 696 seconds to run. 

create procedure slowCounter()
begin

    declare done int …

Yes, if compared to code in Java or C#. For example, this overly simple code took 284 seconds.

CREATE PROCEDURE CountTest()
begin
    declare counter int default 0;
    select now();
    repeat
        set counter = counter + 1;
    until counter > 120000000
    end repeat;
    select counter;
    select now();
end

Ignoring my off by one error, here is equivalent code in C# (the language I’m currently learning).  It took 419 milliseconds, or MySQL took 677 times longer to execute. From my experience, Java isn’t going to be any slower.

 int counter = 0;
while (counter < 120000000)
{
    counter++;
}

Slow stored procedure …

MySQL has a stored procedure language. People have told me how bad it is, how inefficient, how it had to be there to make MySQL appear more professional. Yes, it’s far from perfect, it’s not pre-compiled so not necessarily any faster than running single statements by hand. However, it works and you can do many useful things with it. The complaints however miss the point of stored procedure languages as used inside a database. They are generally used for 3 things:

1. To hide the implementation from the database user, so that the implementation can change but the interface remains stable.
2. To simplify the DBAs day to day tasks of maintaining the database.
3. To speed up complex queries.

While MySQL doesn’t excel at point 3, it can be used in the other two cases. I’ve used Sybase for quite a while and many maintenance tasks could be fully programmed inside the database, just as you would write a …

What does that mean? Should we wait two …

I recently spent 3 hours pulling my hair out trying to fix a MySQL stored procedure that wasn’t working as expected. I’ve boiled the ultimate problem down to a simple example below. Can you spot the problem?

# First, let's create some sample data
CREATE TABLE TrendicsTest (
DateTime DATETIME NOT NULL,
Value INT NOT NULL,
UNIQUE KEY DateTime (DateTime)
);
INSERT INTO TrendicsTest VALUES ('2008-01-01 01:00', 1);
INSERT INTO TrendicsTest VALUES ('2008-01-01 02:00', 2);

# Next, lets' define a stored procedure to query the sample data
DELIMITER |
DROP PROCEDURE IF EXISTS summarizeTrendicsTest|
CREATE PROCEDURE summarizeTrendicsTest(dateTime DATETIME)
BEGIN
SELECT @endDateTime := DATE_ADD(dateTime, INTERVAL 1 HOUR);
SELECT * FROM TrendicsTest WHERE DateTime=@endDateTime;
END;
|
DELIMITER ;

…

This is not about how to write a Stored Procedure (SP), But how to efficiently write a SP.

MySQL Query Browser

The easiest way to write a SP is to use a MySQL Query Browser, Just select the database and right click the dB and "Create Stored Routite..." This shall help you do easily modify, edit and create procedures.

Command Line

Unfortunately, not many of the dB guys could have access to GUI and create/edit access permissions, they may have to rely on the CLI. This is where create / edit of SPs is the most tedious. Lets set something in our system, before we log into MySQL.

• In your ~/.bashrc add the following...
  

  export EDITOR=vim VISUAl=vim
  

• Create / Edit ~/.vimrc file, and add the following...
  

  set noai
  set nonu
  

• Log into the MySQL CLI, and set the following command
  

  delimiter //

…

This is not about how to write a Stored Procedure (SP), But how to efficiently write a SP.

MySQL Query Browser

The easiest way to write a SP is to use a MySQL Query Browser, Just select the database and right click the dB and "Create Stored Routite..." This shall help you do easily modify, edit and create procedures.

Command Line

Unfortunately, not many of the dB guys could have access to GUI and create/edit access permissions, they may have to rely on the CLI. This is where create / edit of SPs is the most tedious. Lets set something in our system, before we log into MySQL.

• In your ~/.bashrc add the following...
  

  export EDITOR=vim VISUAl=vim
  

• Create / Edit ~/.vimrc file, and add the following...
  

  set noai
  set nonu
  

• Log into the MySQL CLI, and set the following command
  

  delimiter //

…

I just read about OLAP4ALL's Materialized Views for MySQL software that "offers the functionality of Materialized Views in MySQL that are not natively supported in the MySQL database.".

What nags me about this is the fact that it is "implemented as a separate Java program running on the server where MySQL is installed".

The server-side of this should be doable using Stored Procedures and/or Triggers. For the client-side a bit of convenience functionality for query rewriting would be needed.

Sounds like an interesting project that I would like to pursue when I find the time.

…