MySQLのトリガ、プロセス制御、およびその他の事項

• ビュー
• トリガー
• 業務
• ストアドプロシージャ
• 組み込み関数
• プロセス制御
• 指数

ビュー

1.ビューとは何ですか

ビューが保存され、仮想テーブルを照会することによって得られる、とされ、次は直接使用することができ

2、なぜ見る必要があります

あなたが頻繁に仮想テーブルを使用する場合、クエリを繰り返すことはできません

3、どのように表示するには

create view teacher2course as
select * from teacher inner join course on teacher.tid = course.teacher_id;

ストレスを受け
、1をハードディスクに、テーブル構造にデータファイルは、表だけでなく、ファイルの表示、
2、ビューは通常照会するために使用され、データビューを変更しないようにしよう

drop view teacher2course;

質問：開発プロセスは、ビューを使用するのでしょうか？

ありません！ビュー内の項目の多くを使用する場合、ビューは、関数のmysqlで、それはつまり、あなたは、この関数の機能を使用すると、MySQLでここにする必要がありますを意味し、ビューに変更を加える必要があり、たまたま後者を展開したいとき最初のビューには、少し変更して、部門間のコミュニケーションの問題に関連するSQL文を対応するアプリケーションを、修正するために行くので、通常のビューを使用していませんが、再編集のSQLステートメントを使用して機能を拡張します

トリガー

特定のテーブルのデータを追加満足する場合には、削除、変更、自動的にトリガ関数が呼び出されたトリガ

なぜトリガーします

我々のデータは、特定のテーブルを削除するには、削除、挿入を追加、更新の動作を変更するために特別にトリガし、行動のこの種のは一度だけ実行
実行が自動的にコードのSQLの別のセクションを実行するトリガをトリガします

トリガーを作成するための構文

# 针对插入
create trigger tri_after_insert_t1 after insert on 表名 for each row
begin
    sql代码。。。
end 
create trigger tri_after_insert_t2 before insert on 表名 for each row
begin
    sql代码。。。
end

# 针对删除
create trigger tri_after_delete_t1 after delete on 表名 for each row
begin
    sql代码。。。
end
create trigger tri_after_delete_t2 before delete on 表名 for each row
begin
    sql代码。。。
end

# 针对修改
create trigger tri_after_update_t1 after update on 表名 for each row
begin
    sql代码。。。
end
create trigger tri_after_update_t2 before update on 表名 for each row
begin
    sql代码。。。
end

# 案例
CREATE TABLE cmd (
    id INT PRIMARY KEY auto_increment,
    USER CHAR (32),
    priv CHAR (10),
    cmd CHAR (64),
    sub_time datetime, #提交时间
    success enum ('yes', 'no') #0代表执行失败
);

CREATE TABLE errlog (
    id INT PRIMARY KEY auto_increment,
    err_cmd CHAR (64),
    err_time datetime
);

delimiter $$  # 将mysql默认的结束符由;换成$$
create trigger tri_after_insert_cmd after insert on cmd for each row
begin
    if NEW.success = 'no' then  # 新记录都会被MySQL封装成NEW对象
        insert into errlog(err_cmd,err_time) values(NEW.cmd,NEW.sub_time);
    end if;
end $$
delimiter ;  # 结束之后记得再改回来，不然后面结束符就都是$$了

#往表cmd中插入记录，触发触发器，根据IF的条件决定是否插入错误日志
INSERT INTO cmd (
    USER,
    priv,
    cmd,
    sub_time,
    success
)
VALUES
    ('egon','0755','ls -l /etc',NOW(),'yes'),
    ('egon','0755','cat /etc/passwd',NOW(),'no'),
    ('egon','0755','useradd xxx',NOW(),'no'),
    ('egon','0755','ps aux',NOW(),'yes');

# 查询errlog表记录
select * from errlog;
# 删除触发器
drop trigger tri_after_insert_cmd;

業務

トランザクションとは何ですか

いくつかのSQLステートメントを含めることができ、トランザクションを開き、これらのステートメントは、どちらかと同時に、SQL成功している
かにも成功したコール・トランザクションアトミック考えます

トランザクションの役割

これは、データ操作のためのデータセキュリティを保証します

ケース：コマースは、銀行のATM機の銀行カードの操作を使用して、お金を転送するアカウント

：トランザクションは、4つのプロパティが必要、原子性、一貫性、独立性、耐久性を。これらの4つのプロパティは、通常と呼ばれACID特性。

原子性（アトミック）。トランザクションは、トランザクション内のすべての操作はどちらかが行うか行わないなどが、作業の不可分の単位です。

一貫性（一貫性）。データベーストランザクションは、別の一貫した状態にある一貫した状態から変更する必要があります。一貫性とアトミック性は密接に関連しています。

分離（アイソレーション）。トランザクションの実行は、他のトランザクション干渉することはできません。すなわち、操作および他の同時トランザクションが単離されると同時に実行される各トランザクションの間に互いに干渉することができないトランザクション内のデータを使用します。

持続性（耐久性）。また、恒久（永続性）として知られている持続性は、トランザクションがコミットされると、データベース内のデータを変更する永久なければならないことを意味します。次の操作またはその他の障害は、それらに影響を持つべきではありません。

どのように

create table user(
id int primary key auto_increment,
name char(32),
balance int
);

insert into user(name,balance)
values
('wsb',1000),
('egon',1000),
('ysb',1000);

# 修改数据之前先开启事务操作
start transaction;

# 修改操作
update user set balance=900 where name='wsb'; #买支付100元
update user set balance=1010 where name='egon'; #中介拿走10元
update user set balance=1090 where name='ysb'; #卖家拿到90元

# 回滚到上一个状态
rollback;

# 开启事务之后，只要没有执行commit操作，数据其实都没有真正刷新到硬盘
commit;
"""开启事务检测操作是否完整，不完整主动回滚到上一个状态，如果完整就应该执行commit操作"""

# 站在python代码的角度，应该实现的伪代码逻辑，
try:
    update user set balance=900 where name='wsb'; #买支付100元
    update user set balance=1010 where name='egon'; #中介拿走10元
    update user set balance=1090 where name='ysb'; #卖家拿到90元
except 异常:
    rollback;
else:
    commit;

# 那如何检测异常？

ストアドプロシージャ

ストアドプロシージャは、MySQLに格納されている実行可能なSQLステートメント、ストアドプロシージャのシリーズが含まれている、あなたはその名前を呼び出すことにより、内部のSQLの束を行うことができます

開発モデルの三種類

最初の

"""
应用程序：只需要开发应用程序的逻辑
mysql:编写好存储过程，以供应用程序调用
优点：开发效率，执行效率都高
缺点：考虑到人为因素、跨部门沟通等问题，会导致扩展性差
"""

第2

"""
应用程序：除了开发应用程序的逻辑，还需要编写原生sql
优点：比方式1，扩展性高(非技术性的)
缺点：
1、开发效率，执行效率都不如方式1
2、编写原生sql太过于复杂，而且需要考虑到sql语句的优化问题
"""

第三の

"""
应用程序：开发应用程序的逻辑，不需要编写原生sql，基于别人编写好的框架来处理数据，ORM
优点：不用再编写纯生sql，这意味着开发效率比方式2高，同时兼容方式2扩展性高的好处
缺点：执行效率连方式2都比不过
"""

ストアドプロシージャを作成します。

delimiter $$
create procedure p1(
    in m int,  # in表示这个参数必须只能是传入不能被返回出去
    in n int,  
    out res int  # out表示这个参数可以被返回出去，还有一个inout表示即可以传入也可以被返回出去
)
begin
    select tname from teacher where tid > m and tid < n;
    set res=0;
end $$
delimiter ;

# 小知识点补充，当一张表的字段特别多记录也很多的情况下，终端下显示出来会出现显示错乱的问题
select * from mysql.user\G;

ストアドプロシージャを使用する方法

# 大前提:存储过程在哪个库下面创建的只能在对应的库下面才能使用！！！

# 1、直接在mysql中调用
set @res=10  # res的值是用来判断存储过程是否被执行成功的依据，所以需要先定义一个变量@res存储10
call p1(2,4,10);  # 报错
call p1(2,4,@res);  

# 查看结果
select @res;  # 执行成功，@res变量值发生了变化

# 2、在python程序中调用
pymysql链接mysql
产生的游表cursor.callproc('p1',(2,4,10))  # 内部原理：@_p1_0=2,@_p1_1=4,@_p1_2=10;
cursor.excute('select @_p1_2;')


# 3、存储过程与事务使用举例(了解)
delimiter //
create PROCEDURE p5(
    OUT p_return_code tinyint
)
BEGIN
    DECLARE exit handler for sqlexception
    BEGIN
        -- ERROR
        set p_return_code = 1;
        rollback;
    END;


  DECLARE exit handler for sqlwarning
  BEGIN
      -- WARNING
      set p_return_code = 2;
      rollback;
  END;

  START TRANSACTION;
      update user set balance=900 where id =1;
      update user123 set balance=1010 where id = 2;
      update user set balance=1090 where id =3;
  COMMIT;

  -- SUCCESS
  set p_return_code = 0; #0代表执行成功


END //
delimiter ;

機能

内蔵された機能のみ、SQL文の中でストアドプロシージャは、MySQLとの違いに注意してください！

参考ブログ：http://www.cnblogs.com/linhaifeng/articles/7495918.html#_label2

CREATE TABLE blog (
    id INT PRIMARY KEY auto_increment,
    NAME CHAR (32),
    sub_time datetime
);

INSERT INTO blog (NAME, sub_time)
VALUES
    ('第1篇','2015-03-01 11:31:21'),
    ('第2篇','2015-03-11 16:31:21'),
    ('第3篇','2016-07-01 10:21:31'),
    ('第4篇','2016-07-22 09:23:21'),
    ('第5篇','2016-07-23 10:11:11'),
    ('第6篇','2016-07-25 11:21:31'),
    ('第7篇','2017-03-01 15:33:21'),
    ('第8篇','2017-03-01 17:32:21'),
    ('第9篇','2017-03-01 18:31:21');

select date_format(sub_time,'%Y-%m'),count(id) from blog group by date_format(sub_time,'%Y-%m');

プロセス制御

# if条件语句
delimiter //
CREATE PROCEDURE proc_if ()
BEGIN
    
    declare i int default 0;
    if i = 1 THEN
        SELECT 1;
    ELSEIF i = 2 THEN
        SELECT 2;
    ELSE
        SELECT 7;
    END IF;

END //
delimiter ;

# while循环
delimiter //
CREATE PROCEDURE proc_while ()
BEGIN

    DECLARE num INT ;
    SET num = 0 ;
    WHILE num < 10 DO
        SELECT
            num ;
        SET num = num + 1 ;
    END WHILE ;

END //
delimiter ;

スローインデックスとクエリの最適化

知識レビュー：データ、必然的にハードディスクIO操作の存在にそのクエリのデータを必要としています

また、「キー」と呼ばれるMySQLのインデックスでは、すぐにレコードを検索するために使用されるデータ構造のストレージエンジンです。

• 主キー
• 一意のキー
• インデックスキー

（主キーを外部キーがクエリをスピードアップするために使用されていないことに注意してください、と私たちは、キーの3種類の前に、上記の二つの加速クエリ結果だけでなく、追加の制約に加えて、研究の範囲内ではありません：空でないとのみ、一意のキー：任意の制約関数のないインデックスキーが役立つ一方でのみ）、あなたはクエリをスピードアップ

インデックスは、ディレクトリブックと同様のデータ構造です。これは、後で調査データは、データディレクトリを見つけるために、最初に行くのではなく、途中のデータページを照会する必要があることを意味します

基本的にランダムイベントはイベントの順序になっているときに、あなたが望む最終結果を取得したいデータの継続的な狭い範囲でフィルタリングすること、それがこの割り出し機構と、言うことで、私たちは常に使用することができます同じデータをロックする方法を見つけます。

影響のインデックス：

• テーブル内の大量のデータの可用性を条件として、インデックスを作成することは遅くなることがあります
• インデックスが作成された後、テーブルにクエリのパフォーマンスが大幅に改善されますが、書き込みパフォーマンスが低下しています

B +ツリー

https://images2017.cnblogs.com/blog/1036857/201709/1036857-20170912011123500-158121126.png

リーフノードのみが実際のデータを格納し、根と枝ノードは、仮想データが存在します

あまり頻繁に階層的な決定木でのお問い合わせの数、低いレベル、

ディスク片の大きさが格納できるデータの一定量がある手段です。ツリー、それの最低レベルを確保するには？ディスク・ストレージ・スペースは、データ項目の比較的小さな断片であります

私たちは私たちのフィールドはインデックスツリーの高さのレベルを減らすことができますどのような内部テーブルを与えるべきだと思う>>>主キーidフィールド

クラスタ化インデックス（主キー）

クラスタ化インデックスは、実際にテーブルに指定されたInnoDBエンジンが主キーを持っている必要があり、テーブルの主キーを指します。最初のストレージエンジンを見てください。

テーブルの構成は、ハードディスクに対応してMyISAMテーブルには、いくつかのファイル（3）を持っていますか？

テーブルの構成は、ハードディスクに対応InnoDBは、いくつかのファイル（2）を持っていますか？FRMファイルがテーブル構造を格納し、IDBテーブルのデータファイル上のデータとのInnoDBインデックスを意味し、インデックスを置くことは不可能です。

：機能入れリーフノードの部分の完全な記録を

セカンダリインデックス（ユニーク、インデックス）

セカンダリインデックス：クエリデータもすべて情報等のフィールド名、パスワードを使用することができる、スクリーニングのIDを条件として使用することはできません、あなたは、クエリのパフォーマンスクラスタ化インデックスをスピードアップするために、この時間を使用することはできません。これは、これらのインデックスがセカンダリインデックスと呼ばれ、他のフィールドにインデックスを作成する必要があります

特徴：次に、リーフノードが格納されている、名前フィールドに従ってインデックスを作成する：{名前に対応する値：レコードが配置されていることをマスターの名前リーフノードは、例えば、補助（の値に対応するレコードのインデックスフィールドの主キーに格納されています}キー）

どこ名= 'ジェイソンユーザーから名前を選択します。

上記のステートメントは、被覆指数と呼ばれている：セカンダリインデックスのリーフノードのみが私たちが望むすべてのデータを発見しました

どこ名=「ジェイソン」は、ユーザからの年齢を選択します。

上記の文は、呼ばれている非カバーインデックスがクエリのフィールド名を打ったとき、しかし、インデックスを、それがマスターキーを使用して、それを見つける必要があるので、年齢のフィールドかどうかを確認します

テストインデックス

レディ

#1. 准备表
create table s1(
id int,
name varchar(20),
gender char(6),
email varchar(50)
);

#2. 创建存储过程，实现批量插入记录
delimiter $$ #声明存储过程的结束符号为$$
create procedure auto_insert1()
BEGIN
    declare i int default 1;
    while(i<3000000)do
        insert into s1 values(i,'jason','male',concat('jason',i,'@oldboy'));
        set i=i+1;
    end while;
END$$ #$$结束
delimiter ; #重新声明分号为结束符号

#3. 查看存储过程
show create procedure auto_insert1\G 

#4. 调用存储过程
call auto_insert1();

# 表没有任何索引的情况下
select * from s1 where id=30000;
# 避免打印带来的时间损耗
select count(id) from s1 where id = 30000;
select count(id) from s1 where id = 1;

# 给id做一个主键
alter table s1 add primary key(id);  # 速度很慢

select count(id) from s1 where id = 1;  # 速度相较于未建索引之前两者差着数量级
select count(id) from s1 where name = 'jason'  # 速度仍然很慢


"""
范围问题
"""
# 并不是加了索引，以后查询的时候按照这个字段速度就一定快   
select count(id) from s1 where id > 1;  # 速度相较于id = 1慢了很多
select count(id) from s1 where id >1 and id < 3;
select count(id) from s1 where id > 1 and id < 10000;
select count(id) from s1 where id != 3;

alter table s1 drop primary key;  # 删除主键 单独再来研究name字段
select count(id) from s1 where name = 'jason';  # 又慢了

create index idx_name on s1(name);  # 给s1表的name字段创建索引
select count(id) from s1 where name = 'jason'  # 仍然很慢！！！
"""
再来看b+树的原理，数据需要区分度比较高，而我们这张表全是jason，根本无法区分
那这个树其实就建成了“一根棍子”
"""
select count(id) from s1 where name = 'xxx';  
# 这个会很快，我就是一根棍，第一个不匹配直接不需要再往下走了
select count(id) from s1 where name like 'xxx';
select count(id) from s1 where name like 'xxx%';
select count(id) from s1 where name like '%xxx';  # 慢 最左匹配特性

# 区分度低的字段不能建索引
drop index idx_name on s1;

# 给id字段建普通的索引
create index idx_id on s1(id);
select count(id) from s1 where id = 3;  # 快了
select count(id) from s1 where id*12 = 3;  # 慢了  索引的字段一定不要参与计算

drop index idx_id on s1;
select count(id) from s1 where name='jason' and gender = 'male' and id = 3 and email = 'xxx';
# 针对上面这种连续多个and的操作，mysql会从左到右先找区分度比较高的索引字段，先将整体范围降下来再去比较其他条件
create index idx_name on s1(name);
select count(id) from s1 where name='jason' and gender = 'male' and id = 3 and email = 'xxx';  # 并没有加速

drop index idx_name on s1;
# 给name，gender这种区分度不高的字段加上索引并不难加快查询速度

create index idx_id on s1(id);
select count(id) from s1 where name='jason' and gender = 'male' and id = 3 and email = 'xxx';  # 快了  先通过id已经讲数据快速锁定成了一条了
select count(id) from s1 where name='jason' and gender = 'male' and id > 3 and email = 'xxx';  # 慢了  基于id查出来的数据仍然很多，然后还要去比较其他字段

drop index idx_id on s1

create index idx_email on s1(email);
select count(id) from s1 where name='jason' and gender = 'male' and id > 3 and email = 'xxx';  # 快 通过email字段一剑封喉 

共同インデックス

select count(id) from s1 where name='jason' and gender = 'male' and id > 3 and email = 'xxx';  
# 如果上述四个字段区分度都很高，那给谁建都能加速查询
# 给email加然而不用email字段
select count(id) from s1 where name='jason' and gender = 'male' and id > 3; 
# 给name加然而不用name字段
select count(id) from s1 where gender = 'male' and id > 3; 
# 给gender加然而不用gender字段
select count(id) from s1 where id > 3; 

# 带来的问题是所有的字段都建了索引然而都没有用到，还需要花费四次建立的时间
create index idx_all on s1(email,name,gender,id);  # 最左匹配原则，区分度高的往左放
select count(id) from s1 where name='jason' and gender = 'male' and id > 3 and email = 'xxx';  # 速度变快

概要：右はLeheを見たときに、これらの操作の上に、あなたは、あなたに興味を持っていませんが、興味を持ってノックすることはできませんノックノックすることができます。ライン上の理論を習得

スロークエリログ

すべてのSQL文を検出する時間を設定すると、時間変化を超え、その後、最適化の対象！