3.Mysqlストアドプロシージャ

1.コンセプト

ストアドプロシージャと関数は、いくつかのSQL文の集まりとして理解することができ、彼らはデータベースにコンパイルされ、保存されていました。

2.シナリオの使用

データ分析および概要は、時間の独自のシステムのデータ・フォーマット用に変換する必要があります。

作成と呼び出し3.

作ります

create procedure 存储过程名称(参数列表)
	其他修饰符
	存储过程

コール
）（ストアドプロシージャ名を呼びます

4.例

DROP procedure xx_procedure;
create procedure xx_procedure(in x int)  -- in表示输入 
begin
	select * from user where id = x;
end
-- 执行
call xx_procedure(1);

パラメータタイプ
1カテゴリー：OUT、INOUT、で
2.定義：
（1）は、入力パラメータで表される
出力パラメータを示している（2）を
（3）INOUT入力を表すために使用することができる、出力も使用することができます

理解5.

1.ストアドプロシージャSQLの直接実行の結果と彼の結果が同じである、という利点が論理は、データベース側でカプセル化されることで、SQL文と等価です。
2.我々は変更が唯一のデータベース側でのストアドプロシージャを変更する必要があると、それはコール・システムへの影響はありませんロジック、その内部のロジックを理解する必要はありません、ストアドプロシージャを呼び出します。
3.開発者が多くの作業を簡素化することができ、アプリケーションおよびデータベース・サーバー・データベースとの間の伝送の減少は、効率データ処理を向上させることができます。

6.変数

1.保存されたプロセス変数は、その範囲のみ開始...端である、定義された宣言を使用して、定義することができます。
変数の定義2.は冒頭、およびその他のステートメントの前のステートメントでなければなりません。使い捨ては、複数の変数を宣言デフォルト与えられたデフォルト値を使用することができます。
3.構文：宣言変数名1 [、変数名2 ...]変数タイプ[デフォルトデフォルト]
4変数は、デフォルト値を与えることができるが、また、クエリが値を返す受信することができる
セット変数名=値：SET、構文を使用して5.直接割り当てを。
6.また、割当の結果を照会することができ、結果は、テーブル名の他の文から変数名に列名を選択した文法データ要件の一つの行です。

Drop procedure xx_procedure;
create procedure xx_procedure(in x int, out y varchar(20))
begin
	declare s varchar(20);
	select xx_name into s from `user` where id = x;
	set y = s;
end
--执行
call xx_procedure(1, @a);
select @a;

7.データ型

1.数値型：int型、float型、ダブル、小数点以下
2日付タイプ：タイムスタンプ、DATE、今年
3文字列：CHAR、VARCHAR、テキスト

タイムスタンプ：データの最も使用されるタイプである- > 10桁のタイムスタンプの
テキスト：使用するテキストタイプはサブテーブルと考えることができたときに一度;かかわらず、テーブルは、クエリフィールドが一緒にお問い合わせの上、直接でない場合は、理由複数のフィールドがするクエリテキストフィールドがある場合、それは、通常のIDの値は、単独のに応じて、テキストフィールドを取る場合に必要な時間である場合、低速のクエリに遭遇するのは簡単です

8.フロー制御ステートメント他の文法

if 的语法格式为： 
if 条件表达式 then 语句 
	[elseif 条件表达式 then 语句] .... 
	[else 语句] 
	end if 
	
case 的语法格式 
首先是第一种写法：
case 表达式
	when 值 then 语句
	when 值 then 语句 
	... 
	[else 语句]
end case 

然后是第二种写法： 
case 
	when 表达式 then 语句 
	when 表达式 then 语句 
	.... 
	[else 语句] 
end case 

loop 循环 语法格式为：
[标号:] loop 
	循环语句 end loop [标号] 
	while 
	while a>100 do 循环语句 
	End while 

Repeat //游标
	SQL语句1 
	UNTIL 条件表达式 
END Repeat; 

Loop
	SQL语句 
	所有的条件判断和跳出需要自己实现 
End loop 

leave 语句用来从标注的流程构造中退出，它通常和 begin...end 或循环一起使用 leave 标号; 

声明语句结束符，可以自定义: 
DELIMITER [符合]
delimiter $$
$$

9.カーソル

カーソルも呼ぶことができる
ループ処理中に格納された結果に
ステップ：オープン宣言し、値を閉じました。

文法

DECLARE test_cursor CURSOR FOR 结果集; //声明游标 
OPEN test_cursor; //打开游标 
CLOSE test_cursor; //关闭游标 
DECLARE CONTINUE HANDLER FOR NOT FOUND //结果集查询不到数据自动跳出

概要

カーソルを宣言するための構文：クエリの宣言カーソル名カーソル。
カーソルの構文を開きます：オープンカーソル名を、
カーソル・データを取得します：変数名1にカーソル名を取得[、変数名2 ...]
カーソルの構文を閉じます：近くにカーソル名を、
基本的な手順は、カーソル：処理サイクルに基づいてテーブルの上に、条件を決定するために、サイクルの終わりには、次のカーソルのレコードを見つけることができませんフェッチ、カーソルをオフにして、プロセスを終了します撮影条件で発見されていません。
データ出力変数、条件、カーソル、アプリケーションの動作確認は、一時テーブルに配置されています知っているパスカルプログラミング経験の友人を持っていたかもしれない、宣言の順序はSQLに、我々は定義がある宣言の順序を使用し、また重要です、およびカーソルのデータを読み出します

ケース

delimiter $$ 
create procedure exchange(out count int ) 
begin 
	declare supply_id1 int default 0;
	declare amount1 int default 0; -- 游标标识 
	declare blag int default 1; -- 游标 
	declare order_cursor cursor for select supply_id,amount from order_group; 
	-- not found 这个异常进行处理 
	declare continue handler for not found set blag = 0; set count = 0; 
	-- 打开游标 
	open order_cursor; 
	-- 遍历 
	read_loop: LOOP 
		fetch order_cursor into supply_id1,amount1; 
		if blag = 0 then 
			leave read_loop; 
		end if; 
		if supply_id1 = 1 then 
			set count = count + amount1;
		end if; 
	end loop read_loop; 
end; 
$$
delimiter ;
call exchange(@count);
select @count;

ストアドプロシージャの利点

最初のポイントの利点は、速い実行速度です。各SQLステートメントがコンパイルされ、すべての必要性私たちがいるので、その後、実行されますが、ストアドプロシージャを直接実行する、直接の後にコンパイルされます。
第2の利点は、ネットワークトラフィックが減少することです。私たちは、SQL文の数が多い頭上はるかに小さい輸送よりも、ストアドプロシージャを運びます。
第3の利点は、システムのセキュリティを改善することです。手順は、ストレージアクセス制御ために使用することができる、およびストアドプロシージャのパラメータが有効SQLインジェクション攻撃を防ぐことができます。その安全性を確保するために。
第4の利点は、結合が減少することです。私たちのテーブル構造を調整したり、変更しなければならないとき、我々はストアドプロシージャを変更することができ、私たちのアプリケーションは、より小さな場所にある程度変更する必要があります。
第五ポイントの利点は、再利用性の強いです。私たちは、ストアドプロシージャ呼び出しを記述した後、再び、単一の名前、または必要があるため、「一度書き込みを、どこでも呼んで」とストアドプロシージャも強化モジュラーことができます使用します。

ストアドプロシージャの欠点

第1の欠点は、貧しい移植です。ストアドプロシージャとデータベースがバインドされているので、我々はデータベースなどの操作を交換したい場合、あなたは多くの場所で変更する必要があります。
第二の欠点は、不便で修飾されています。ストアドプロシージャのために、我々は、デバッグに特に効果的ではないので、それはいくつかのバグがアプリケーションのリスクを増加させ、ずっと後に見つけることができるのです。
第3の欠点は、明らかな利点と余分な機能よりも大きいです。小規模なWebアプリケーションの場合、我々は、ステートメント・キャッシュを使用する場合、SQLのコンパイルのオーバーヘッドが大きくない見つけましたが、彼らは、オーバーヘッドのようなものを必要な権限を確認するためのストアドプロシージャの使用は、これらの機能は、ある程度以上の余分よりもパフォーマンスの足かせになります。

OK - 誰

リリース3元の記事・ウォンの賞賛0 ・ビュー35

プライベートの手紙の懸念