Basically what happens is, when SQL Server sees a query that it needs to compile, it is going to use the first-time-called parameters to generate the execution plan. This may or may not be a good thing, but it is what happens.

For instance, say you have a table of fruit (100 rows). There are 98 rows that are Apple, and only 2 rows that contain the fruit Orange. If you query that table for Apple, then the plan will most likely compile with a Scan. This is a good thing, as it is optimized for that Apple query. But then when you want to query for the Orange, that Scan is inefficient. But it is the stored plan that is being used.

The fact of the matter is that it happens. It happens all the time. It's typically not an outstanding issue, but in some cases it can be a pretty big problem. A solution to an ongoing bad parameter sniffing problem is that you can utilize the OPTIMIZE FOR query hint to force SQL Server to use certain parameter values when generating the execution plan upon initial compilation.

The reason for the discrepancy is obvious.

When you run

SELECT A.*,B.* FROM (SELECT VERSION() MySQLVersion) A,
(SELECT COUNT(1) MySQLProcColumns FROM information_schema.columns
WHERE table_schema='mysql' AND table_name='proc') B;

you get

mysql> SELECT A.*,B.* FROM (SELECT VERSION() MySQLVersion) A,
    -> (SELECT COUNT(1) MySQLProcColumns FROM information_schema.columns
    -> WHERE table_schema='mysql' AND table_name='proc') B;
+-----------------------+------------------+
| MySQLVersion          | MySQLProcColumns |
+-----------------------+------------------+
| 5.0.51a-community-log |               16 |
+-----------------------+------------------+
1 row in set (0.54 sec)

mysql>

and

mysql> SELECT A.*,B.* FROM (SELECT VERSION() MySQLVersion) A,
    -> (SELECT COUNT(1) MySQLProcColumns FROM information_schema.columns
    -> WHERE table_schema='mysql' AND table_name='proc') B;
+--------------+------------------+
| MySQLVersion | MySQLProcColumns |
+--------------+------------------+
| 5.5.8-log    |               20 |
+--------------+------------------+
1 row in set (0.01 sec)

mysql>

Here is a quick-and-dirty way to fix mysql.proc. Please pay attention:

STEP 01 : On the Slave DB Server, run STOP SLAVE;

STEP 02 : Install MySQL 5.5.26 on a Staging DB Server

STEP 03 : Copy the following files from that Staging DB Server to the Slave DB Server

• /var/lib/mysql/mysql/proc.frm
• /var/lib/mysql/mysql/proc.MYD
• /var/lib/mysql/mysql/proc.MYI

STEP 04 : On the Slave DB Server, run FLUSH TABLES;

STEP 05 : Dump the Stored Procedures on the Master DB Server

MYSQLDUMP_OPTIONS="--routines --no-data --no-create-info --all-databases"
mysqldump -uroot -p ${MYSQLDUMP_OPTIONS} > StoredProc.sql

STEP 06 : Move StoredProc.sql from Master DB Server to /root on the Slave DB Server

STEP 07 : On the Slave DB Server, load the Stored Procedures

mysql -uroot -p -A < /root/StoredProc.sql

STEP 08 : On the Slave DB Server, run START SLAVE;

You should never encounter this issue any more.

Give it a Try !!!

UPDATE 2013-04-22 12:45 EDT

Please run this query

SELECT COUNT(1) FROM information_schema.columns
WHERE table_schema='mysql' AND table_name='user';

For MySQL 5.0, you should get 37. For MySQL 5.5, you should get 42.

If you get 37 on the MySQL 5.5. server, go ahead with running mysql_upgrade.

If you get 42, run my original answer to fix mysql.proc.