trx事務

1. mysql伺服器運行使用了只讀選項因此不能執行這條語錄怎麼辦

MySQL的事務支持不是綁定在MySQL伺服器本身，而是與存儲引擎相關1.MyISAM：不支持事務，用於只讀程序提高性能 2.InnoDB：支持ACID事務、行級鎖、並發 3.Berkeley DB：支持事務

一個事務是一個連續的一組資料庫操作，就好像它是一個單一的工作單元進行。換言之，永遠不會是完整的事務，除非該組內的每個單獨的操作是成功的。如果在事務的任何操作失敗，則整個事務將失敗。
實際上，會俱樂部許多SQL查詢到一個組中，將執行所有的人都一起作為事務的一部分。
事務的特性：
事務有以下四個標准屬性的縮寫ACID，通常被稱為：
原子性: 確保工作單元內的所有操作都成功完成，否則事務將被中止在故障點，和以前的操作將回滾到以前的狀態。
一致性: 確保資料庫正確地改變狀態後，成功提交的事務。
隔離性: 使事務操作彼此獨立的和透明的。
持久性: 確保提交的事務的結果或效果的系統出現故障的情況下仍然存在。
在MySQL中，事務開始使用COMMIT或ROLLBACK語句開始工作和結束。開始和結束語句的SQL命令之間形成了大量的事務。
COMMIT & ROLLBACK:
這兩個關鍵字提交和回滾主要用於MySQL的事務。
當一個成功的事務完成後，發出COMMIT命令應使所有參與表的更改才會生效。
如果發生故障時，應發出一個ROLLBACK命令返回的事務中引用的每一個表到以前的狀態。
可以控制的事務行為稱為AUTOCOMMIT設置會話變數。如果AUTOCOMMIT設置為1（默認值），然後每一個SQL語句（在事務與否）被認為是一個完整的事務，並承諾在默認情況下，當它完成。 AUTOCOMMIT設置為0時，發出SET AUTOCOMMIT =0命令，在隨後的一系列語句的作用就像一個事務，直到一個明確的COMMIT語句時，沒有活動的提交。
可以通過使用mysql_query()函數在PHP中執行這些SQL命令。
通用事務例子
這一系列事件是獨立於所使用的編程語言，可以建立在任何使用的語言來創建應用程序的邏輯路徑。
可以通過使用mysql_query()函數在PHP中執行這些SQL命令。

BEGIN WORK開始事務發出SQL命令
發出一個或多個SQL命令，如SELECT，INSERT，UPDATE或DELETE
檢查是否有任何錯誤，一切都依據的需要。
如果有任何錯誤，那麼問題ROLLBACK命令，否則發出COMMIT命令。
在MySQL中的事務安全表類型：
如果打算使用MySQL事務編程，那麼就需要一種特殊的方式創建表。有很多支持事務但最流行的是InnoDB表類型。
從源代碼編譯MySQL時，InnoDB表支持需要特定的編譯參數。如果MySQL版本沒有InnoDB支持，請互聯網服務提供商建立一個版本的MySQL支持InnoDB表類型，或者下載並安裝Windows或Linux/UNIX的MySQL-Max二進制分發和使用的表類型在開發環境中。
如果MySQL安裝支持InnoDB表，只需添加一個的TYPE=InnoDB 定義表創建語句。例如，下面的代碼創建InnoDB表tcount_tbl：

代碼如下 復制代碼
root@host# mysql -u root -p password;
Enter password:*******
mysql> use TUTORIALS;
Database changed
mysql> create table tcount_tbl
-> (
-> tutorial_author varchar(40) NOT NULL,
-> tutorial_count INT
-> ) TYPE=InnoDB;
Query OK, 0 rows affected (0.05 sec)
可以使用其他GEMINI或BDB表類型，但它取決於您的安裝，如果它支持這兩種類型。

由於項目設計裡面，牽扯到了金錢的轉移，於是就要用到MYSQL的事務處理，來保證一組處理結果的正確性。用了事務，就不可避免的要犧牲一部分速度，來保證數據的正確性。
只有InnoDB支持事務
事務 ACID Atomicity（原子性）、Consistency（穩定性）、Isolation（隔離性）、Durability（可靠性）
1、事務的原子性
一組事務，要麼成功；要麼撤回。
2、穩定性
有非法數據（外鍵約束之類），事務撤回。
3、隔離性
事務獨立運行。
一個事務處理後的結果，影響了其他事務，那麼其他事務會撤回。
事務的100%隔離，需要犧牲速度。
4、可靠性
軟、硬體崩潰後，InnoDB數據表驅動會利用日誌文件重構修改。
可靠性和高速度不可兼得， innodb_flush_log_at_trx_commit選項 決定什麼時候吧事務保存到日誌里。
開啟事務
START TRANSACTION 或 BEGIN
提交事務（關閉事務）
COMMIT
放棄事務（關閉事務）
ROLLBACK
折返點
SAVEPOINT adqoo_1
ROLLBACK TO SAVEPOINT adqoo_1
發生在折返點 adqoo_1 之前的事務被提交，之後的被忽略
事務的終止
設置「自動提交」模式
SET AUTOCOMMIT = 0
每條SQL都是同一個事務的不同命令，之間由 COMMIT 或 ROLLBACK隔開
掉線後，沒有 COMMIT 的事務都被放棄
事務鎖定模式
系統默認： 不需要等待某事務結束，可直接查詢到結果，但不能再進行修改、刪除。
缺點：查詢到的結果，可能是已經過期的。
優點：不需要等待某事務結束，可直接查詢到結果。
需要用以下模式來設定鎖定模式
1、SELECT …… LOCK IN SHARE MODE（共享鎖）
查詢到的數據，就是資料庫在這一時刻的數據（其他已commit事務的結果，已經反應到這里了）
SELECT 必須等待，某個事務結束後才能執行
2、SELECT …… FOR UPDATE（排它鎖）
例如 SELECT * FROM tablename WHERE id<200
那麼id<200的數據，被查詢到的數據，都將不能再進行修改、刪除、SELECT …… LOCK IN SHARE MODE操作
一直到此事務結束
共享鎖 和 排它鎖 的區別：在於是否阻斷其他客戶發出的 SELECT …… LOCK IN SHARE MODE命令
3、INSERT / UPDATE / DELETE
所有關聯數據都會被鎖定，加上排它鎖
4、防插入鎖
例如 SELECT * FROM tablename WHERE id>200
那麼id>200的記錄無法被插入
5、死鎖
自動識別死鎖
先進來的進程被執行，後來的進程收到出錯消息，並按ROLLBACK方式回滾
innodb_lock_wait_timeout = n 來設置最長等待時間，默認是50秒
事務隔離模式
SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL
READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE
1、不帶SESSION、GLOBAL的SET命令
只對下一個事務有效
2、SET SESSION
為當前會話設置隔離模式
3、SET GLOBAL
為以後新建的所有MYSQL連接設置隔離模式（當前連接不包括在內）
隔離模式
READ UNCOMMITTED
不隔離SELECT
其他事務未完成的修改（未COMMIT），其結果也考慮在內
READ COMMITTED
把其他事務的 COMMIT 修改考慮在內
同一個事務中，同一 SELECT 可能返回不同結果
REPEATABLE READ（默認）
不把其他事務的修改考慮在內，無論其他事務是否用COMMIT命令提交過
同一個事務中，同一 SELECT 返回同一結果（前提是本事務，不修改）
SERIALIZABLE
和REPEATABLE READ類似，給所有的SELECT都加上了 共享鎖
出錯處理
根據出錯信息，執行相應的處理

2. 分頁查詢如何避免幻讀

1. 多版本並發控制(MVCC)(快照讀/一致性讀)

多數資料庫都實現了多版本並發控制，並且都是靠保存數據快照來實現的。以 InnoDB 為例，每一行中都冗餘了兩個字斷。

一個是行的創建版本，一個是行的刪除(過期)版本。具體的版本號(trx_id)存在 information_schema.INNODB_TRX 表中。版本號(trx_id)隨著每次事務的開啟自增。

事務每次取數據的時候都會取創建版本小於當前事務版本的數據，以及過期版本大於當前版本的數據。普通的 select 就是快照讀。select * from T wherenumber=1;原理：將歷史數據存一份快照，所以其他事務增加與刪除數據，對於當前事務來說是不可見的。

2. next-key 鎖 (當前讀)

next-key 鎖包含兩部分：記錄鎖(行鎖) 間隙鎖

記錄鎖是加在索引上的鎖，間隙鎖是加在索引之間的。(思考：如果列上沒有索引會發生什麼？)

select * from T wherenumber=1for update;select * from T where number=1lock in share mode;insert update delete

原理：將當前數據行與上一條數據和下一條數據之間的間隙鎖定，保證此范圍內讀取的數據是一致的。

其他：MySQL InnoDB 引擎 RR 隔離級別是否解決了幻讀。

3. LASERTRX注冊過商標嗎還有哪些分類可以注冊

LASERTRX商標總申請量1件
其中已成功注冊0件，有1件正在申請中，無效注冊0件，0件在售中。
經八戒知識產權統計，LASERTRX還可以注冊以下商標分類：
第1類（化學制劑、肥料）
第2類（顏料油漆、染料、防腐製品）
第3類（日化用品、洗護、香料）
第4類（能源、燃料、油脂）
第5類（葯品、衛生用品、營養品）
第6類（金屬製品、金屬建材、金屬材料）
第7類（機械設備、馬達、傳動）
第8類（手動器具（小型）、餐具、冷兵器）
第9類（科學儀器、電子產品、安防設備）
第11類（照明潔具、冷熱設備、消毒凈化）
第12類（運輸工具、運載工具零部件）
第13類（軍火、煙火、個人防護噴霧）
第14類（珠寶、貴金屬、鍾表）
第15類（樂器、樂器輔助用品及配件）
第16類（紙品、辦公用品、文具教具）
第17類（橡膠製品、絕緣隔熱隔音材料）
第18類（箱包、皮革皮具、傘具）
第19類（非金屬建築材料）
第20類（傢具、傢具部件、軟墊）
第21類（廚房器具、家用器皿、洗護用具）
第22類（繩纜、遮蓬、袋子）
第23類（紗、線、絲）
第24類（紡織品、床上用品、毛巾）
第25類（服裝、鞋帽、襪子手套）
第26類（飾品、假發、紐扣拉鏈）
第27類（地毯、席墊、牆紙）
第28類（玩具、體育健身器材、釣具）
第29類（熟食、肉蛋奶、食用油）
第30類（面點、調味品、飲品）
第31類（生鮮、動植物、飼料種子）
第32類（啤酒、不含酒精的飲料）
第33類（酒、含酒精飲料）
第34類（煙草、煙具）
第35類（廣告、商業管理、市場營銷）
第36類（金融事務、不動產管理、典當擔保）
第37類（建築、室內裝修、維修維護）
第38類（電信、通訊服務）
第39類（運輸倉儲、能源分配、旅行服務）
第40類（材料加工、印刷、污物處理）
第41類（教育培訓、文體活動、娛樂服務）
第42類（研發質控、IT服務、建築咨詢）
第43類（餐飲住宿、養老托兒、動物食宿）
第44類（醫療、美容、園藝）
第45類（安保法律、婚禮家政、社會服務）

4. 怎麼看mysql有沒阻塞

通過下面的查詢，來查詢當前資料庫，有哪些事務，都鎖定哪些資源。

SELECT
	trx_idAS`事務ID`,
	trx_stateAS`事務狀態`,
	trx_requested_lock_idAS`事務需要等待的資源`,
	trx_wait_started	AS`事務開始等待時間`,
	trx_tables_in_useAS`事務使用表`,
	trx_tables_lockedAS`事務擁有鎖`,
	trx_rows_lockedAS`事務鎖定行`,
	trx_rows_modifiedAS`事務更改行`
FROM
	information_schema.innodb_trx;

SELECT
	lock_id			AS	`鎖ID`,
	lock_trx_id	AS	`擁有鎖的事務ID`,
	lock_mode		AS	`鎖模式	`,
	lock_type		AS	`鎖類型`,
	lock_table		AS	`被鎖的表`,
	lock_index		AS	`被鎖的索引`,
	lock_space		AS	`被鎖的表空間號`,
	lock_page		AS	`被鎖的頁號`,
	lock_rec		AS	`被鎖的記錄號`,
	lock_data		AS	`被鎖的數據`
FROM
	information_schema.innodb_locks;

SELECT
requesting_trx_idAS`請求鎖的事務ID`,
requested_lock_idAS`請求鎖的鎖ID`,
blocking_trx_idAS`當前擁有鎖的事務ID`,
blocking_lock_idAS`當前擁有鎖的鎖ID`
FROM
innodb_lock_waits;

5. java lock wait timeout exceeded;try restarting transaction怎麼解決

trx_id:InnoDB存儲引擎內部唯一的事物ID
trx_status:當前事務的狀態
trx_status:事務的開始時間
trx_requested_lock_id：等待事務的鎖ID
trx_wait_started：事務等待的開始時間
trx_weight：事務的權重，反應一個事務修改和鎖定的行數，當發現死鎖需要回滾時，權重越小的值被回滾
trx_mysql_thread_id：MySQL中的進程ID，與show processlist中的ID值相對應

6. 如何驗證兩個SELECT查詢語句處在同一個事務裡面

方法一、藉助information_schema.inno_trx
首先想到的是每個事務在執行時，有沒有TRANSACTION_ID這樣的東西，實際在Innodb內部是存在的。在information_schema.inno_trx中我們可以看到當前未完成的事務，其中TRX_ID就是事務的一個內在表示（注意： MySQL 5.6 中針對只讀的，無鎖的事務，不會生成TRX_ID，詳見Optimizations for Read-Only Transactions，這里不存在這個問題）。
SELECT * FROM table1;
select trx_id from information_schema.INNODB_TRX where trx_mysql_thread_id = connection_id();
…
SELECT * FROM table1;
select trx_id from information_schema.INNODB_TRX where trx_mysql_thread_id = connection_id();
…
只要判斷前後兩次獲取到的trx_id是否一致即可，結論當然是一致的。
方法二：添加更新語句，藉助binlog判斷
考慮利用binlog，在select前後添加兩條insert到無關緊要的表，然後在binlog中查看兩個insert是否在同一事務中即可。
查看當前二進制日誌位置，獲取當前文件ch18_1db-bin.000034，位置2154
show binary logs;

7. 關於MYSQL配置文件中innodb_flush_log_at_trx_commit的疑問

這是關繫到事務日誌的一個參數,0或者2,只是定時的刷新到log buffer,

事務日誌..不知道你明白不..就是你說的也影響到更新數據的操作.但對正常的數據讀寫不會有影響...簡單來說..就是你事務提交了..,你就可以查到commit後的數據. 但這時並不一定寫入到磁碟了..可能在緩存..
這個參數也就是在commit的時候會有差異,如果為1,就每個事務提交就會要刷新到磁碟後才算提交完成....這種情況是保證了事務的acid,但性能會有很大的影響...
如果為0或者2,只要commit了就算完成了...0和2的區別在於
0：當mysql掛了之後，可能會損失前一秒的事務信息
2：當mysql掛了之後，如果系統文件系統沒掛，不會有事務丟失

8. 如何查sqlservertransactions per second

Transactions per Second（每秒通過事務數/TPS) 反映的是在一段時間內伺服器能夠支持的
交易結果更新事務數量。
可以從information_schema.INNODB_TRX 表裡得到當前系統所有在執行的事務的情況，包括是事務是否在等待鎖，事務開始時間，當前的SQL語句.
表的列名如下：

其中 trx_state 的值為這4種狀態其中之一. RUNNING, LOCK WAIT, ROLLING BACK or COMMITTING.

我覺的可以統計4個狀態的事物數，可以大體上知道當前事物執行情況，如果有很多LOCK WAIT,那系統並發上可能存在問題。然後根據對應 SQL 語句（trx_query )進行分析。

9. 安裝MySQL事務資料庫都需要哪些步驟

按常規的方法進行安裝
安裝MySQL完成後，啟動MySQL(和PHP搭配之最佳組合)binWinMySQL(和PHP搭配之最佳組合)admin
再退出
運行
MySQL(和PHP搭配之最佳組合)binmydqld-nt--remove
MySQL(和PHP搭配之最佳組合)binMySQL(和PHP搭配之最佳組合)d-max-nt--install
以上二行是去掉不支持事務處理的MySQL(和PHP搭配之最佳組合)服務，改成支持MySQL(和PHP搭配之最佳組合)事務處理的服務
然後在c:下建一個ibdata目錄及iblogs目錄，當然名字可以不一樣，記住這二個名字及盤符，以後要用到，你也可以不建在C盤，然後，打開c:winnt或c:windows目錄下的my.ini,在最後添加：以下內容為程序代碼:
1.innodb_data_file_path=ibdata1:2000M;ibdata2:2000M
2.innodb_data_home_dir=c:ibdata
3.set-variable=innodb_mirrored_log_groups=1
4.innodb_log_group_home_dir=c:iblogs
5.set-variable=innodb_log_files_in_group=3
6.set-variable=innodb_log_file_size=30M
7.set-variable=innodb_log_buffer_size=8M
8.innodb_flush_log_at_trx_commit=1
9.innodb_log_arch_dir=c:iblogs
10.innodb_log_archive=0
11.set-variable=innodb_buffer_pool_size=80M
12.set-variable=innodb_additional_mem_pool_size=10M
13.set-variable=innodb_file_io_threads=4
14.set-variable=innodb_lock_wait_timeout=50
其中
1.innodb_data_file_path=ibdata1:2000M;ibdata2:2000M 這一行中的2000M可以自己改成200m，看你盤的容量大小，MySQL(和PHP搭配之最佳組合)推薦10G及以上的硬碟空間最好用這樣的設置;
以下這一行
1.innodb_data_home_dir=c:ibdata 也可以改成你自己起的目錄，主要是看你自己在剛才建的目錄在哪裡啦
按照以上的方法，你已經安裝MySQL好了MySQL(和PHP搭配之最佳組合)的事務資料庫，不過你要是按照MySQL(和PHP搭配之最佳組合)手冊上的方法安裝，把上面的一段配製放到my.cnf是去的話，可是會出錯哦
好了，現在讓我們試試看是不是安裝完成了，啟動apache(Unix平台最流行的WEB伺服器平台),或iis,在服務里啟動MySQL(和PHP搭配之最佳組合)的服務，打開phpmyadmin，輸入:SHOWvariableslikehave_%
你要是看到下面的結果，那說明你安裝MySQL成功了
以下內容為程序代碼
1.Variable_nameValue
2.have_bdbYES
3.have_innodbYES
4.have_isamYES
5.have_raidNO
6.have_symlinkYES
7.have_opensslNO
8.have_query_cacheYES
9. 註：MySQL(和PHP搭配之最佳組合)的事務處理方法的使用同其它資料庫語法相似，在這里我就不多說了，另外，MySQL(和PHP搭配之最佳組合)將在4.3中實現外鍵及子查詢，簡單的外鍵已經在4.0中都已經實現了，只是不怎麼方便，相信以後會做得更好些。

10. 強同步復制模式半同步復制模式哪個好

從mysql5.5開始，支持半同步模式復制(semisynchronous replication)，比之前的非同步模式復制增強了安全性。
半同步復制模式可以確保至少有一個備節點伺服器在接受完主伺服器發送的binlog日誌文件並寫入到中繼日誌後，返回給主節點一個ack信號，告訴主節點已經接收完日誌，這時主節點線程才返回給當前session提交信息。
當主節點因為超時未接收到任一個備節點的ack信號時會切換會非同步復制模式，從而防止堵塞應用。
當至少有一個備節點返回給主節點ack信號時，主節點切換回半同步復制模式。
主備節點必須全部配置成半同步復制模式，否則不支持該模式。
mysql 的半同步復制是通過安裝插件來實現的，主備節點安裝相應的插件，否則無法實現半同步復制。
已安裝二進制包的默認插件目錄在/usr/lib/mysql/plugin中。開啟半同步復制模式如下：

1.在主節點中運行
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
2.在每個備節點中運行
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
3.在主節點中運行
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
mysql> SET GLOBAL rpl_semi_sync_master_timeout = 10000;
4.在備節點中運行
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;
mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
5.在主節點中配置文件/etc/my.cnf添加
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout =10000 (默認為10000毫秒，可不更改)
6.在備節點中配置文件/etc/my.cnf添加
rpl_semi_sync_slave_enabled=1
7.查看主節點狀態確認半同步復制模式打開

Rpl_semi_sync_master_clients 大於0表示有備機以半同步模式連接到主節點。

備注(單位微秒)：
Rpl_semi_sync_master_clients
半同步連接的slave數目
Rpl_semi_sync_master_net_avg_wait_time
主節點等待備節點同步的平均時間
Rpl_semi_sync_master_net_wait_time
主節點等待備節點同步的總時間
Rpl_semi_sync_master_net_waits
主節點等待次數
Rpl_semi_sync_master_no_times
主節點關閉半同步的次數
Rpl_semi_sync_master_no_tx
主節點未收到ack返回信號的次數
Rpl_semi_sync_master_status
半同步主節點狀態(當為主節點的時候為ON)
Rpl_semi_sync_master_timefunc_failures
半同步由於調用時間函數錯誤的次數
Rpl_semi_sync_master_tx_avg_wait_time
半同步主節點等待一個事務的平均等待時間
Rpl_semi_sync_master_tx_wait_time
主節點等待事務完成的總等待時間
Rpl_semi_sync_master_tx_waits
主節點等待事務完成的總次數
Rpl_semi_sync_master_wait_pos_backtraverse
等待備節點事務應用的順序同主節點日誌寫入順序不一致
Rpl_semi_sync_master_wait_sessions
主節點等待的回話次數
Rpl_semi_sync_master_yes_tx
成功完成半同步的事務總次數
Rpl_semi_sync_slave_status
半同步備節點狀態(當為備節點的時候為ON)