MYSQL5.1で以下のようなストアドプロシージャを作成したとします。

http://doruby.kbmj.com/toma_on_rails/20090327/_MySQL

http://idocsq.net/page/16

http://tt-house.com/2008/11/procedure-on-mysql.html

このあたりが参考になります。

delimiter //
CREATE PROCEDURE TEST(IN startIdx INT, IN endIdx INT, OUT cnt INT)
BEGIN
	SELECT COUNT(*) INTO cnt FROM
	(
		SELECT TEST1, TEST2
		FROM TESTA
		WHERE ID = 4
		UNION ALL
		SELECT TEST3, TEST4
		FROM TESTB
		WHERE ID = 5
	);
	SELECT HTL.TEST1, HTL.TEST2 FROM
	(
		SELECT TEST1, TEST2
		FROM TESTA
		WHERE ID = 4
		UNION ALL
		SELECT TEST3, TEST4
		FROM TESTB
		WHERE ID = 5
		LIMIT startIdx-1, endIdx
	)
	AS AA ;
END

http://dev.mysql.com/doc/refman/5.1/ja/call.html

動かしてはおらんが、何もないよりましだろう。

delimiter //
CREATE PROCEDURE TEST(st INT, ed INT, INOUT c INT)
BEGIN
  SELECT count(*) INTO c FROM (
    SELECT TEST1, TEST2 FROM TESTA WHERE ID = 4
    UNION ALL
    SELECT TEST3, TEST4 FROM TESTB WHERE ID = 5
  ) AS AA;
  SELECT TEST1, TEST2 FROM (
    SELECT TEST1, TEST2 FROM TESTA WHERE ID = 4
    UNION ALL
    SELECT TEST3, TEST4 FROM TESTB WHERE ID = 5
  ) AS AA
  LIMIT st, ed;
END
//
delimiter ;

SET @cnt = 0;
CALL TEST(1, 10, @cnt);
SELECT @cnt;

話は変わるが、これはphpとの組み合わせで使うことになるのであろう？　VIEWのほうが良いかもしれぬぞ。

mysql_num_rowsで総数を数え、LIMITを組み込んだSQLを発行という流れなど、よければ、少し考えてみるよろし。

MySQLのストアドはCREATE時には簡単な構文チェックのみで実行コードへの変換等は行われない。すなわち、呼び出す度に変換が行われ、そのあと実行という２段階になる。もっと重要な問題がクエリーキャッシュが効かない事。（下記参照）ストアドの利用は高速化という意味での恩恵はあまりないどころか下手に使うと負荷増大＆低速化という可能性が高まる。

http://dev.mysql.com/doc/refman/5.1-olh/ja/query-cache-operation...

次のようなクエリーにはキャッシュは使用されません。

*クエリーが外部クエリーのサブクエリーである場合

*ストアドファンクション、トリガー、イベントなどのボディ内で実行したクエリー

ストアドを共通ルーチンと位置付けて管理していくというのであれば、そちらのほうが高速化よりも重要かもしれぬが、当然ながらphpファイルの一覧とは別にストアドの一覧のようなものを作成して、管理運営していかねばならぬという管理コストも発生する。

対してVIEWはテーブルに近い感覚で動作し、扱う事ができる分、ストアドよりは比較的、お気軽お手軽。

しかし、INDEXを使えないなど欠点は多い（下記参照）し、サブクエリ内でUNIONを使っておるからこちらもクエリキャッシュは効かんはずじゃ、よりパフォーマンスを求めるとなるとテーブル構成やアプリ側の対処までの広範囲で設計見直したほうが良いじゃろう。

http://dev.mysql.com/doc/refman/5.1/ja/view-restrictions.html

以上簡単じゃが、データベース設計段階で考えるべきお話じゃから、このあたりまでにする。がんばりなされ。