MySql编写一个存储过程?

MySql编写一个存储过程?,第1张

1、delimiter // ,声明分隔符:DELIMITER是分割符的意思,因为MySQL默认以""为分隔符,如果我们没有声明分割符,那么编译器会把存储过程当成SQL语句进行处理,则存储过程的编译过程会报错,所以要事先用DELIMITER关键字申明当前段分隔符,这样MySQL才会将""当做存储过程中的代码,不会执行这些代码(这里如果不懂的话,你可以通过试错的方法来理解)。2、编写存储过程的格式:CREATE PROCEDURE([[IN |OUT |INOUT ]参数名数据类形...])例子:1)create procedure proc1(out s int) // 只有输出2)create procedure proc2(in p_in bigint) // 只有输入3)create procedure proc15() // 没有输入与输出4)create procedure demo_multi_param(in id bigint,in name varchar(32),out c int) //多输入与输出3、过程体的开始与结束使用BEGIN与END进行标识。4、select count (*) into s from student// 过程体,一系列的逻辑语句,sql语句5、delimiter 用完了之后要把分隔符还原。

MySQL通过内部两阶段提交协议来提交事务,如下图

具体实现如下图:

第一阶段 :InnoDB prepare,持有prepare_commit_mutex,并且write/sync redo log;将rollback设置为Prepared状态,binlog prepare不作任何 *** 作;

第二阶段 :包含两步,write/sync Binlog及 InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex);

考虑mysql以binlog的写入与否作为事务提交成功与否的标志,如果 在写入innodb commit标志时崩溃(binglog已经写文件但是还没有提交) ,则恢复时,会重新对commit标志进行写入;此时的事务崩溃恢复过程如下:

1)扫描最后一个Binlog文件,提取其中的xid;

2)InnoDB维持了状态为Prepare的事务链表,将这些事务的xid和Binlog中记录的xid做比较,如果在Binlog中存在,则提交,否则回滚事务。

但其中也会存在2个问题:

并发危机:全局大锁prepare_commit_mutex

Mysql5.6.5前的做法,加锁,串行化

无锁方案:如果能保证binlog write 和  Innodb commit的顺序一致性就可以解决该问题。

性能问题:参数sync_binlog =1 ,innodb_flush_log_at_trx_commit =1时,fsync *** 作频繁

数据持久化到磁盘:调用fsync将缓存中的数据刷新到磁盘(普通硬盘150次/s和SSD 1200次/S),影响TPS;Group Commit *** 作,在多个事务并发时,将等待fsync的多个事务合并为仅调用一次fsync *** 作,以解决innodb fsync的问题,对binlog 的fsync也适用

对上述两个问题的解决:

针对并发问题

Group *** 作,三个阶段都在维护一个队列。第一个进队列的线程称为leader线程,负责对队列里所有线程进行 *** 作;之后进入队列的线程称作follower线程,follower 线程进入队列后睡眠,等待leader完成 *** 作后将他们唤醒。注意:前一个队列leader进入后一个队列时,会把自己原队列的follower全加入进去。

针对一致性问题 

Group commit 分为三个阶段,每个阶段有一个线程在执行。分阶段的目的在于各个阶段可以并发执行,提升效率。

涉及参数说明:

sync_binlog =1 :启用group commit之后,其实已经不是一个事务去刷一次磁盘了,而是一组事务刷一次磁盘。图中1、2分别代表sync_binlog 不同配置下,通知其他线程(如dump线程)binlog 已经更新了,当配置为1时,要严格等到sync完毕之后才会发送广播通知, 如果sync_binlog配的是别的值,MySQL会把通知提前到1的位置

binlog_group_commit_sync_no_delay_count(组提交sync无延迟时间最大event数)及binlog_group_commit_sync_delay(组提交sync延迟时间,单位:毫秒):一般来说我们认为group commit 中最耗时的 *** 作是sync阶段,于是我们可以在sync阶段在leader真正sync之前进行一个等待,以便让fsync一次性刷新更多的事务。这对需要等待sync 完之后才能进行的 *** 作(比如dump线程)可能有性能提升。

两阶段提交:

MYSQL_BIN_LOG作为协调者


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/6095893.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-14
下一篇 2023-03-14

发表评论

登录后才能评论

评论列表(0条)

保存