寫一個(gè)存儲(chǔ)過程,在存儲(chǔ)過程里寫一個(gè)事物,再把你要的mysql 多條語句寫在事物里面就行了,要用的時(shí)候調(diào)用一下存儲(chǔ)過程.大致格式是這樣的:
創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),廣陽企業(yè)網(wǎng)站建設(shè),廣陽品牌網(wǎng)站建設(shè),網(wǎng)站定制,廣陽網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,廣陽網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
drop procedure if exists accessCount;
delimiter $
create procedure accessCount()
BEGIN
DECLARE t_error INTEGER DEFAULT 0;/*設(shè)置錯(cuò)誤增量*/
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET t_error=1;
START TRANSACTION;/*開啟事物*/
xxxx(你的語句)
IF t_error = 1 THEN /*執(zhí)行失敗回滾*/
ROLLBACK;
ELSE
COMMIT;
END IF;
end $
delimiter ;
DELIMITER $$
BEGIN
DECLARE t_error INTEGER DEFAULT 0;
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET t_error=1 ;
START TRANSACTION;
UPDATE table1 SET a = '111';
INSERT INTO table2 (b) VALUES ('222');
INSERT INTO table3 (c) VALUES ('333');
IF t_error = 1 THEN
ROLLBACK;
ELSE
COMMIT;
END IF;
END$$
DELIMITER ;
1、為什么auto_increament沒有回滾？
因?yàn)閕nnodb的auto_increament的計(jì)數(shù)器記錄的當(dāng)前值是保存在存內(nèi)
存中的，并不是存在于磁盤上，當(dāng)mysql
server處于運(yùn)行的時(shí)候，這個(gè)計(jì)數(shù)值只會(huì)隨著insert改增長(zhǎng)，不會(huì)隨著delete而減少。而當(dāng)mysql
server啟動(dòng)時(shí)，當(dāng)我們需要去查詢auto_increment計(jì)數(shù)值時(shí)，mysql便會(huì)自動(dòng)執(zhí)行：SELECT
MAX(id)
FROM
表名
FOR
UPDATE;語句來獲得當(dāng)前auto_increment列的最大值，然后將這個(gè)值放到auto_increment計(jì)數(shù)器中。所以就算
Rollback
MySQL的auto_increament計(jì)數(shù)器也不會(huì)作負(fù)運(yùn)算。
2、MySQL的事務(wù)對(duì)表操作的時(shí)候是否是物理操作？
MySQL的事務(wù)是有redo和undo的，redo操作的所有信息都是記錄到
redo_log中，也就是說當(dāng)一個(gè)事務(wù)做commit操作時(shí)，需要先把這個(gè)事務(wù)的操作寫到redo_log中，然后再把這些操作flush到磁盤上，當(dāng)
出現(xiàn)故障時(shí)，只需要讀取redo_log,然后再重新flush到磁盤就行了。
而對(duì)于undo就比較麻煩，MySQL在處理事務(wù)時(shí)，會(huì)在數(shù)據(jù)共享
表空間里申請(qǐng)一個(gè)段叫做segment段，用保存undo信息，當(dāng)在處理rollback，不是完完全全的物理undo，而是邏輯undo,就是說會(huì)對(duì)之
前的操作進(jìn)行反操作，但是這些共享表空間是不進(jìn)行回收的。這些表空間的回收需要由mysql的master
thread進(jìn)程來進(jìn)行回收。
當(dāng)啟動(dòng)Binlog后，事務(wù)會(huì)產(chǎn)生Binlog Event，這些Event被看做事務(wù)數(shù)據(jù)的一部分。因此要保證事務(wù)的Binlog Event和InnoDB引擎中的數(shù)據(jù)的一致性。所以帶Binlog的CrashSafe要求MySQL宕機(jī)重啟后能夠保證：
- 所有已經(jīng)提交的事務(wù)的數(shù)據(jù)仍然存在。
- 所有沒有提交的事務(wù)的數(shù)據(jù)自動(dòng)回滾。
- 所有已經(jīng)提交了的事務(wù)的Binlog Event也仍然存在。
- 所有沒有提交事務(wù)沒有記錄Binlog Event。
這些要求很好理解，如果重啟后數(shù)據(jù)還在，但是Binlog Event沒有了，就沒辦法復(fù)制到其他節(jié)點(diǎn)上了。如果重啟后，數(shù)據(jù)沒了，但是Binlog Event還在，那么不存在的數(shù)據(jù)就會(huì)被復(fù)制到其他節(jié)點(diǎn)上，從而導(dǎo)致主從的不一致。
為了保證帶Binlog的CrashSafe，MySQL內(nèi)部使用的兩階段提交(Two Phase Commit)。
2 - MySQL的Two Phase Commit(2PC)
在開啟Binlog后，MySQL內(nèi)部會(huì)自動(dòng)將普通事務(wù)當(dāng)做一個(gè)XA事務(wù)來處理：
- 自動(dòng)為每個(gè)事務(wù)分配一個(gè)唯一的ID
- COMMIT會(huì)被自動(dòng)的分成Prepare和Commit兩個(gè)階段。
- Binlog會(huì)被當(dāng)做事務(wù)協(xié)調(diào)者(Transaction Coordinator)，Binlog Event會(huì)被當(dāng)做協(xié)調(diào)者日志。
想了解2PC，可以參考文檔：【。】
- 分布式事務(wù)ID(XID)
使用2PC時(shí)，MySQL會(huì)自動(dòng)的為每一個(gè)事務(wù)分配一個(gè)ID，叫XID。XID是唯一的，每個(gè)事務(wù)的XID都不相同。XID會(huì)分別被Binlog和InnoDB記入日志中，供恢復(fù)時(shí)使用。MySQ內(nèi)部的XID由三部分組成：
- 前綴部分
前綴部分是字符串"MySQLXid"
- Server ID部分
當(dāng)前MySQL的server_id
- query_id部分
為了保證XID的的唯一性，數(shù)字部分使用了query_id。MySQL內(nèi)部會(huì)自動(dòng)的為每一個(gè)語句分配一個(gè)query_id，全局唯一。
參考代碼：sql/xa。h的struct xid_t結(jié)構(gòu)。
- 事務(wù)的協(xié)調(diào)者Binlog
Binlog在2PC中充當(dāng)了事務(wù)的協(xié)調(diào)者（Transaction Coordinator）。由Binlog來通知InnoDB引擎來執(zhí)行prepare，commit或者rollback的步驟。事務(wù)提交的整個(gè)過程如下：
1. 協(xié)調(diào)者準(zhǔn)備階段(Prepare Phase)
告訴引擎做Prepare，InnoDB更改事務(wù)狀態(tài)，并將Redo Log刷入磁盤。
2. 協(xié)調(diào)者提交階段(Commit Phase)
2.1 記錄協(xié)調(diào)者日志，即Binlog日志。
2.2 告訴引擎做commit。
注意：記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫入磁盤)之后，這點(diǎn)至關(guān)重要。
在MySQ的代碼中將協(xié)調(diào)者叫做tc_log。在MySQL啟動(dòng)時(shí)，tc_log將被初始化為mysql_bin_log對(duì)象。參考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= mysql_bin_log;
而在事務(wù)提交時(shí)，會(huì)依次執(zhí)行：
tc_log-prepare()；
tc_log-commit()；
參考代碼：sql/binlog.cc中的ha_commit_trans()。當(dāng)mysql_bin_log是tc_log時(shí)，prepare和commit的代碼在sql/binlog.cc中：
MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；
-協(xié)調(diào)者日志Xid_log_event
作為協(xié)調(diào)者，Binlog需要將事務(wù)的XID記入日志，供恢復(fù)時(shí)使用。Xid_log_event有以下幾個(gè)特點(diǎn)：
- 僅記錄query_id
因?yàn)榍熬Y部分不變，server_id已經(jīng)記錄在Event Header中，Xid_log_event中只記錄query_id部分。
- 標(biāo)志事務(wù)的結(jié)束
在Binlog中相當(dāng)于一個(gè)事務(wù)的COMMIT語句。
一個(gè)事務(wù)在Binlog中看起來時(shí)這樣的：
Query_log_event("BEGIN");DML產(chǎn)生的events; Xid_log_event;
- DDL沒有BEGIN，也沒有Xid_log_event 。
- 僅InnoDB的DML會(huì)產(chǎn)生Xid_log_event
因?yàn)镸yISAM不支持2PC所以不能用Xid_log_event ，但會(huì)有COMMIT Event。
Query_log_event("BEGIN");DML產(chǎn)生的events;Query_log_event("COMMIT");
問題：Query_log_event("COMMIT")和Xid_log_event 有不同的影響嗎？
- Xid_log_event 中的Xid可以幫助master實(shí)現(xiàn)CrashSafe。
- Slave的CrashSafe不依賴Xid_log_event
事務(wù)在Slave上重做時(shí)，會(huì)重新產(chǎn)生XID。所以Slave服務(wù)器的CrashSafe并不依賴于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作為事務(wù)的結(jié)尾，告訴Slave Applier去提交這個(gè)事務(wù)。因此二者在Slave上的影響是一樣的。
3 - 恢復(fù)(Recovery)
這個(gè)機(jī)制是如何保證MySQL的CrashSafe的呢，我們來分析一下。這里我們假設(shè)用戶設(shè)置了以下參數(shù)來保證可靠性：
- 恢復(fù)前事務(wù)的狀態(tài)
在恢復(fù)開始前事務(wù)有以下幾種狀態(tài)：
- InnoDB中已經(jīng)提交
根據(jù)前面2PC的過程，可知Binlog中也一定記錄了該事務(wù)的的Events。所以這種事務(wù)是一致的不需要處理。
- InnoDB中是prepared狀態(tài)，Binlog中有該事務(wù)的Events。
需要通知InnoDB提交這些事務(wù)。
- InnoDB中是prepared狀態(tài)，Binlog中沒有該事務(wù)的Events。
因?yàn)锽inlog還沒記錄，需要通知InnoDB回滾這些事務(wù)。
- Before InnoDB Prepare
事務(wù)可能還沒執(zhí)行完，因此InnoDB中的狀態(tài)還沒有prepare。根據(jù)2PC的過程，Binlog中也沒有該事務(wù)的events。 需要通知InnoDB回滾這些事務(wù)。
- 恢復(fù)過程
從上面的事務(wù)狀態(tài)可以看出：恢復(fù)時(shí)事務(wù)要提交還是回滾，是由Binlog來決定的。
- 事務(wù)的Xid_log_event 存在，就要提交。
- 事務(wù)的Xid_log_event 不存在，就要回滾。
恢復(fù)的過程非常簡(jiǎn)單：
- 從Binlog中讀出所有的Xid_log_event
- 告訴InnoDB提交這些XID的事務(wù)
- InnoDB回滾其它的事務(wù)
重慶分公司
重慶分公司
