innodbtrx阿里雲
1. 阿里雲伺服器給了許可權，本地採集的數據遠程寫入伺服器中MySQL，一秒可以寫入多少速度由什麼來決定
你自己去下載一個mysql壓力測試軟體，測一下你的資料庫就知道了（或者就簡單把你的數據做成insert語句，復制個幾百行出來，然後用navicat for mysql之類的連上你的資料庫，執行這些語句看看要多久） ，初步估計多半還是你程序的問題。
2. 怎樣修復損壞了的innodb 表
- 恢復策略
前面說到未提交的事務和回滾了的事務也會記錄Redo Log，因此在進行恢復時,這些事務要進行特殊的的處理.有2中不同的恢復策略：
A. 進行恢復時，只重做已經提交了的事務。
B. 進行恢復時，重做所有事務包括未提交的事務和回滾了的事務。然後通過Undo Log回滾那些未提交的事務。
- InnoDB存儲引擎的恢復機制
MySQL資料庫InnoDB存儲引擎使用了B策略, InnoDB存儲引擎中的恢復機制有幾個特點：
A. 在重做Redo Log時，並不關心事務性。 恢復時，沒有BEGIN，也沒有COMMIT,ROLLBACK的行為。也不關心每個日誌是哪個事務的。盡管事務ID等事務相關的內容會記入Redo Log，這些內容只是被當作要操作的數據的一部分。
B. 使用B策略就必須要將Undo Log持久化，而且必須要在寫Redo Log之前將對應的Undo Log寫入磁碟。Undo和Redo Log的這種關聯，使得持久化變得復雜起來。為了降低復雜度，InnoDB將Undo Log看作數據，因此記錄Undo Log的操作也會記錄到redo log中。這樣undo log就可以象數據一樣緩存起來，而不用在redo log之前寫入磁碟了。
包含Undo Log操作的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert …>
記錄3: <trx2, Undo log insert <undo_update …>>
記錄4: <trx2, update …>
記錄5: <trx3, Undo log insert <undo_delete …>>
記錄6: <trx3, delete …>
C. 到這里，還有一個問題沒有弄清楚。既然Redo沒有事務性，那豈不是會重新執行被回滾了的事務？確實是這樣。同時Innodb也會將事務回滾時的操作也記錄到redo log中。回滾操作本質上也是對數據進行修改，因此回滾時對數據的操作也會記錄到Redo Log中。
一個回滾了的事務的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert A…>
記錄3: <trx1, Undo log insert <undo_update …>>
記錄4: <trx1, update B…>
記錄5: <trx1, Undo log insert <undo_delete …>>
記錄6: <trx1, delete C…>
記錄7: <trx1, insert C>
記錄8: <trx1, update B to old value>
記錄9: <trx1, delete A>
一個被回滾了的事務在恢復時的操作就是先redo再undo，因此不會破壞數據的一致性.
- InnoDB存儲引擎中相關的函數
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()
3. innodb存儲引擎的數據文件放在哪裡
MySQL資料庫InnoDB存儲引擎使用了B策略, InnoDB存儲引擎中的恢復機制有幾個特點：
A. 在重做Redo Log時，並不關心事務性。 恢復時，沒有BEGIN，也沒有COMMIT,ROLLBACK的行為。也不關心每個日誌是哪個事務的。盡管事務ID等事務相關的內容會記入Redo Log，這些內容只是被當作要操作的數據的一部分。
B. 使用B策略就必須要將Undo Log持久化，而且必須要在寫Redo Log之前將對應的Undo Log寫入磁碟。Undo和Redo Log的這種關聯，使得持久化變得復雜起來。為了降低復雜度，InnoDB將Undo Log看作數據，因此記錄Undo Log的操作也會記錄到redo log中。這樣undo log就可以象數據一樣緩存起來，而不用在redo log之前寫入磁碟了。
包含Undo Log操作的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert …>
記錄3: <trx2, Undo log insert <undo_update …>>
記錄4: <trx2, update …>
記錄5: <trx3, Undo log insert <undo_delete …>>
記錄6: <trx3, delete …>
C. 到這里，還有一個問題沒有弄清楚。既然Redo沒有事務性，那豈不是會重新執行被回滾了的事務？確實是這樣。同時Innodb也會將事務回滾時的操作也記錄到redo log中。回滾操作本質上也是對數據進行修改，因此回滾時對數據的操作也會記錄到Redo Log中。
一個回滾了的事務的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert A…>
記錄3: <trx1, Undo log insert <undo_update …>>
記錄4: <trx1, update B…>
記錄5: <trx1, Undo log insert <undo_delete …>>
記錄6: <trx1, delete C…>
記錄7: <trx1, insert C>
記錄8: <trx1, update B to old value>
記錄9: <trx1, delete A>
一個被回滾了的事務在恢復時的操作就是先redo再undo，因此不會破壞數據的一致性.
- InnoDB存儲引擎中相關的函數
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()
4. mysql innodb 怎麼配置
你上面這些語句是正確的，如果你的my.ini裡面沒有，可以自己添加進去。
注意，如果你的機器是Unix的話，c:\mysql這樣的路徑要修改為UNIX的格式，例如/yusr/local/mysql
5. 如何創建innodb資料庫
1. 建立InnoDB資料庫：
運行環境：RHEL4U5 + mysql5.0
默認情況下mysql自動安裝InnoDB數據引擎，InnoDB的資料庫文件和日誌文件在默認的資料庫資料庫目錄（/var/lib/mysql 或者/usr/local/mysql/var），現在由於我們要重新建立InnoDB資料庫，所以將原來的InnoDB資料庫備份好後，刪除即可，建立InnoDB資料庫的操作步驟：
默認的資料庫數據目錄：/var/lib/mysql
1） shell> service mysqld stop # 停止mysql進程
2） shell> mv /var/lib/mysql/ib* /var/lib/mysql/InnoDB-old # 備份好原來的InnoDB的資料庫文件
3) shell> mkdir /var/lib/mysql/InnoDB #建立存放新InnoDB資料庫文件的目錄，默認不自動創建目錄
4） shell> vi /etc/my.cnf #編輯InnoDB資料庫的相關的配置選項
[mysqld]
# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /var/lib/mysql/InnoDB/ #innodb資料庫數據文件目錄
innodb_data_file_path = ibdata2:100M:autoextend:max:2000M #數據文件名稱及大小
innodb_log_group_home_dir = /var/lib/mysql/InnoDB/
innodb_log_arch_dir = /var/lib/mysql/InnoDB/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 16M #緩沖池的大小，一般設置為主存的50%-80%
innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M #日誌文件的大小,一般設置為主存的25%
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1 #事務
innodb_lock_wait_timeout = 50
5) shell> chown mysql:mysql /var/lib/mysql/InnoDB/ #設置InnoDB資料庫目錄的許可權，否則無法啟動mysql
6) shell> service mysqld start # 啟動mysqld進程
這時在/var/lib/mysql/InnoDB 目錄中應該可以看到新生成的InnoDB文件，那麼InnoDB資料庫就生成了。
2. 使用InnoDB資料庫：
1）在配置文件中的[mysqld]欄位添加 default-storage-engine=INNODB ，將默認的資料庫引擎修改為InnoDB
2} 在創建表的時候，手動指定表的類型：
CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB
注意：修改mysql配置文件需要重啟啟動mysqld進程
6. mysql 中InnoDB和MyISAM的區別分析小結
InnoDB和MyISAM是在使用MySQL最常用的兩個表類型，各有優缺點，視具體應用而定。
下面是已知的兩者之間的差別，僅供參考。
innodb
InnoDB 給 MySQL 提供了具有事務(commit)、回滾(rollback)和崩潰修復能力
(crash recovery capabilities)的事務安全
(transaction-safe (ACID compliant))型表。InnoDB 提供了行鎖
(locking on row level)，提供與 Oracle 類型一致的不加鎖讀取(non-locking
read in SELECTs)。這些特性均提高了多用戶並發操作的性能表現。
在InnoDB表中不需要擴大鎖定(lock escalation)，因為 InnoDB 的列鎖定(row level
locks)適宜非常小的空間。InnoDB 是 MySQL 上第一個提供外鍵約束(FOREIGN KEY
constraints)的表引擎。
InnoDB 的設計目標是處理大容量資料庫系統，它的 CPU 利用率是其它基於磁碟的關系資料庫
引擎所不能比的。在技術上，InnoDB 是一套放在 MySQL 後台的完整資料庫系統，
InnoDB 在主內存中建立其專用的緩沖池用於高速緩沖數據和索引。 InnoDB 把數據和索引存
放在表空間里，可能包含多個文件，這與其它的不一樣，舉例來說，在 MyISAM 中，表被存放
在單獨的文件中。InnoDB 表的大小隻受限於操作系統的文件大小，一般為 2 GB。
InnoDB所有的表都保存在同一個數據文件 ibdata1 中（也可能是多個文件，或者是獨立的
表空間文件）,相對來說比較不好備份，免費的方案可以是拷貝數據文件、備份 binlog，
或者用 mysqlmp。
MyISAM
MyISAM 是MySQL預設存貯引擎 .
每張MyISAM 表被存放在三個文件 。frm 文件存放表格定義。 數據文件是MYD (MYData) 。
索引文件是MYI (MYIndex) 引伸。
因為MyISAM相對簡單所以在效率上要優於InnoDB..小型應用使用MyISAM是不錯的選擇.
MyISAM表是保存成文件的形式,在跨平台的數據轉移中使用MyISAM存儲會省去不少的麻煩
MyISAM是ISAM表的新版本，有如下擴展：
·二進制層次的可移植性。
·NULL列索引。
·對變長行比ISAM表有更少的碎片。
·支持大文件。
·更好的索引壓縮。
·更好的鍵嗎統計分布。
·更好和更快的auto_increment處理。
以下是一些細節和具體實現的差別：
◆1.InnoDB不支持FULLTEXT類型的索引。
◆2.InnoDB 中不保存表的具體行數，也就是說，執行select count(*) from table時，
InnoDB要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數即可。
注意的是，當count(*)語句包含 where條件時，兩種表的操作是一樣的。
◆3.對於AUTO_INCREMENT類型的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM
表中，可以和其他欄位一起建立聯合索引。
◆4.DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。
◆5.LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成
MyISAM表，導入數據後再改成InnoDB表，但是對於使用的額外的InnoDB特性（例如外鍵）的
表不適用。
◆MyISAM類型的二進制數據文件可以在不同操作系統中遷移。
另外，InnoDB表的行鎖也不是絕對的，假如在執行一個SQL語句時MySQL不能確定要掃描的
范圍，InnoDB表同樣會鎖全表，例如update table set num=1 where name like 「%aaa%」
再另外，使用兩種的選擇：如果你的數據執行大量的INSERT或UPDATE，出於性能方面的考慮，
應該使用InnoDB表。如果執行大量的SELECT，MyISAM是更好的選擇。若需要使用事務處理，
但是原來的數據表使用的是myisam，就需要改為bdb或者innodb，這樣基於myisam的程序，
將類型改為innodb後，其程序不用改動……
綜上所述，任何一種表都不是萬能的，只有恰當的針對業務類型來選擇合適的表類型，才能
最大的發揮MySQL的性能優勢。
MyISAM和InnoDB優化：
key_buffer_size - 這對MyISAM表來說非常重要。如果只是使用MyISAM表，可以把它設置
為可用內存的 30-40%。合理的值取決於索引大小、數據量以及負載 -- 記住，MyISAM表會
使用操作系統的緩存來緩存數據，因此需要留出部分內存給它們，很多情況下數據比索引大
多了。盡管如此，需要總是檢查是否所有的 key_buffer 都被利用了 -- .MYI 文件只有 1GB
，而 key_buffer 卻設置為 4GB 的情況是非常少的。這么做太浪費了。如果你很少使用
MyISAM表，那麼也保留低於 16-32MB 的 key_buffer_size 以適應給予磁碟的臨時表索引
所需。
innodb_buffer_pool_size - 這對Innodb表來說非常重要。Innodb相比MyISAM表對緩沖更
為敏感。MyISAM可以在默認的 key_buffer_size 設置下運行的可以，然而Innodb在默認的
innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於Innodb把數據和索引都緩存起來，
無需留給操作系統太多的內存，因此如果只需要用Innodb的話則可以設置它高達 70-80% 的
可用內存。一些應用於 key_buffer 的規則有 -- 如果你的數據量不大，並且不會暴增，那
么無需把
innodb_additional_pool_size - 這個選項對性能影響並不太多，至少在有差不多足夠內存
可分配的操作系統上是這樣。不過如果你仍然想設置為 20MB(或者更大)，因此就需要看一下
Innodb其他需要分配的內存有多少。
innodb_log_file_size 在高寫入負載尤其是大數據集的情況下很重要。這個值越大則性能相
對越高，但是要注意到可能會增加恢復時間。我經常設置為 64-512MB，跟據伺服器大小而異。
innodb_log_buffer_size 默認的設置在中等強度寫入負載以及較短事務的情況下，伺服器性
能還可以。如果存在更新操作峰值或者負載較大，就應該考慮加大它的值了。如果它的值設置
太高了，可能會浪費內存 -- 它每秒都會刷新一次，因此無需設置超過1秒所需的內存空間。
通常 8-16MB 就足夠了。越小的系統它的值越小。
innodb_flush_logs_at_trx_commit 是否為Innodb比MyISAM慢1000倍而頭大？看來也許你忘
了修改這個參數了。默認值是 1，這意味著每次提交的更新事務（或者每個事務之外的語句）
都會刷新到磁碟中，而這相當耗費資源，尤其是沒有電池備用緩存時。很多應用程序，尤其是
從 MyISAM轉變過來的那些，把它的值設置為 2 就可以了，也就是不把日誌刷新到磁碟上，
而只刷新到操作系統的緩存上。日誌仍然會每秒刷新到磁碟中去，因此通常不會丟失每秒1-
2次更新的消耗。如果設置為 0 就快很多了，不過也相對不安全了 -- MySQL伺服器崩潰時
就會丟失一些事務。設置為 2 指揮丟失刷新到操作系統緩存的那部分事務。
table_cache -- 打開一個表的開銷可能很大。例如MyISAM把MYI文件頭標志該表正在使用
中。你肯定不希望這種操作太頻繁，所以通常要加大緩存數量，使得足以最大限度地緩存打
開的表。它需要用到操作系統的資源以及內存，對當前的硬體配置來說當然不是什麼問題了。
如果你有200多個表的話，那麼設置為 1024 也許比較合適（每個線程都需要打開表），
如果連接數比較大那麼就加大它的值。我曾經見過設置為 100,000 的情況。
thread_cache -- 線程的創建和銷毀的開銷可能很大，因為每個線程的連接/斷開都需要。
我通常至少設置為 16。如果應用程序中有大量的跳躍並發連接並且 Threads_Created 的值
也比較大，那麼我就會加大它的值。它的目的是在通常的操作中無需創建新線程。
query_cache -- 如果你的應用程序有大量讀，而且沒有應用程序級別的緩存，那麼這很有
用。不要把它設置太大了，因為想要維護它也需要不少開銷，這會導致MySQL變慢。通常設置
為 32-512Mb。設置完之後最好是跟蹤一段時間，查看是否運行良好。在一定的負載壓力下，
如果緩存命中率太低了，就啟用它。
sort_buffer_size --如果你只有一些簡單的查詢，那麼就無需增加它的值了，盡管你有
64GB 的內存。搞不好也許會降低性能
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. MySQL資料庫恢復(InnoDB)
你會備份，不能恢復。真的服你了。
給你二個解決辦法：
第一個辦法：使用這個命令格式
shell>mysqladmin create 資料庫名 -uroot -p (資料庫已經存在就不用此步)
shell>mysql -uroot -p 資料庫名 < backup-file.sql
第二個辦法：更詳細的用法在mysql的在線手冊中，已經給你找到備份恢復的頁面了，打看學一下，你們問題就可以肯定搞定了。這是mysql官方中文手冊。
備份恢復的頁面鏈接：http://dev.mysql.com/doc/refman/5.1/zh/database-administration.html#disaster-prevention
9. 如何開啟mysql innodb存儲引擎
MySQL資料庫InnoDB存儲引擎使用了B策略, InnoDB存儲引擎中的恢復機制有幾個特點：
A. 在重做Redo Log時，並不關心事務性。 恢復時，沒有BEGIN，也沒有COMMIT,ROLLBACK的行為。也不關心每個日誌是哪個事務的。盡管事務ID等事務相關的內容會記入Redo Log，這些內容只是被當作要操作的數據的一部分。
B. 使用B策略就必須要將Undo Log持久化，而且必須要在寫Redo Log之前將對應的Undo Log寫入磁碟。Undo和Redo Log的這種關聯，使得持久化變得復雜起來。為了降低復雜度，InnoDB將Undo Log看作數據，因此記錄Undo Log的操作也會記錄到redo log中。這樣undo log就可以象數據一樣緩存起來，而不用在redo log之前寫入磁碟了。
包含Undo Log操作的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert …>
記錄3: <trx2, Undo log insert <undo_update …>>
記錄4: <trx2, update …>
記錄5: <trx3, Undo log insert <undo_delete …>>
記錄6: <trx3, delete …>
C. 到這里，還有一個問題沒有弄清楚。既然Redo沒有事務性，那豈不是會重新執行被回滾了的事務？確實是這樣。同時Innodb也會將事務回滾時的操作也記錄到redo log中。回滾操作本質上也是對數據進行修改，因此回滾時對數據的操作也會記錄到Redo Log中。
一個回滾了的事務的Redo Log，看起來是這樣的：
記錄1: <trx1, Undo log insert <undo_insert …>>
記錄2: <trx1, insert A…>
記錄3: <trx1, Undo log insert <undo_update …>>
記錄4: <trx1, update B…>
記錄5: <trx1, Undo log insert <undo_delete …>>
記錄6: <trx1, delete C…>
記錄7: <trx1, insert C>
記錄8: <trx1, update B to old value>
記錄9: <trx1, delete A>
一個被回滾了的事務在恢復時的操作就是先redo再undo，因此不會破壞數據的一致性.
- InnoDB存儲引擎中相關的函數
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()
10. 如何從innodb status中的連接線程id確認到其對應的操作系統線程
如果遇到死鎖了，怎麼解決呢?找到原始的鎖ID，然後KILL掉一直持有的那個線程就可以了， 但是眾多線程，可怎麼找到引起死鎖的線程ID呢? MySQL 發展到現在，已經非常強大了，這個問題很好解決。 直接從數據字典連查找。
我們來演示下。
線程A，我們用來鎖定某些記錄，假設這個線程一直沒提交，或者忘掉提交了。 那麼就一直存在，但是數據裡面顯示的只是SLEEP狀態。
mysql> set @@autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| demo_test |
| t3 |
+----------------+
2 rows in set (0.00 sec)
mysql> select * from t3;
+----+--------+--------+------------+----+----+----+
| id | fname | lname | birthday | c1 | c2 | c3 |
+----+--------+--------+------------+----+----+----+
| 19 | lily19 | lucy19 | 2013-04-18 | 19 | 0 | 0 |
| 20 | lily20 | lucy20 | 2013-03-13 | 20 | 0 | 0 |
+----+--------+--------+------------+----+----+----+
2 rows in set (0.00 sec)
mysql> update t3 set birthday = '2022-02-23' where id = 19;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
| 16 |
+-----------------+
1 row in set (0.00 sec)
mysql>
線程B， 我們用來進行普通的更新，但是遇到問題了，此時不知道是哪個線程把這行記錄給鎖定了?
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 1 |
+--------------+
1 row in set (0.00 sec)
mysql> update t3 set birthday='2018-01-03' where id = 19;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
| 17 |
+-----------------+
1 row in set (0.00 sec)
mysql> show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+------+---------+------+-------+------------------+
| 10 | root | localhost | NULL | Sleep | 1540 | | NULL |
| 11 | root | localhost | NULL | Sleep | 722 | | NULL |
| 16 | root | localhost | test | Sleep | 424 | | NULL |
| 17 | root | localhost | test | Query | 0 | init | show processlist |
| 18 | root | localhost | NULL | Sleep | 5 | | NULL |
+----+------+-----------+------+---------+------+-------+------------------+
5 rows in set (0.00 sec)
mysql> show engine innodb status\G
------------
TRANSACTIONS
------------
Trx id counter 189327
Purge done for trx's n:o < 189323 undo n:o < 0 state: running but idle
History list length 343
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 11, OS thread handle 0x7f70a0c98700, query id 994 localhost root init
show engine innodb status
---TRANSACTION 189326, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 17, OS thread handle 0x7f70a0bd5700, query id 993 localhost root updating
update t3 set birthday='2018-01-03' where id = 19
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 529 page no 3 n bits 72 index `PRIMARY` of table `test`.`t3` trx id 189326 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
0: len 2; hex 3139; asc 19;;
1: len 6; hex 00000002e38c; asc ;;
2: len 7; hex 7e00000d2827c9; asc ~ (' ;;
3: len 6; hex 6c696c793139; asc lily19;;
4: len 6; hex 6c7563793139; asc lucy19;;
5: len 3; hex 8fcc57; asc W;;
6: len 4; hex 80000013; asc ;;
7: len 4; hex 80000000; asc ;;
8: len 4; hex 80000000; asc ;;
------------------
---TRANSACTION 189324, ACTIVE 641 sec
2 lock struct(s), heap size 376, 3 row lock(s), undo log entries 1
MySQL thread id 16, OS thread handle 0x7f70a0b94700, query id 985 localhost root cleaning up
Trx read view will not see trx with id >= 189325, sees < 189325
上面的信息很繁多，也看不清楚到底哪裡是哪裡。
不過現在，我們只要從數據字典裡面拿出來這部分信息就OK了。
mysql> SELECT * FROM information_schema.INNODB_TRX\G
*************************** 1. row ***************************
trx_id: 189324
trx_state: RUNNING
trx_started: 2013-04-18 17:48:14
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 16
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 3
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.01 sec)
mysql>
原來是線程16忘掉COMMIT了。