innodbtrx
『壹』 如何查看mysql innodb
mysql被設計成了一個單進程多線程架構的資料庫
開始：
1、默認的InnoDB存儲引擎的後台線程有7個，4個IO thread ，1個master thread 1個鎖監控 thread 1個錯誤監控thread，IO thread 的數量由配置文件的innodb_file_io_threads參數控制，默認是4,linux下面不可以調整，但是window下面可以
show engine innodb status \G;(root用戶，或者你的用戶有查看許可權)
show variables like 'innodb_version' \G;
show variables like 'innodb_%io_threads' \G;
注釋：我十分建議大家安裝獨立的mysql，不要用集成環境，因為出現問題會後悔死的
2、innodb存儲引擎內存有以下部分：
buffer pool 緩沖池
redo log buffer 重做日誌緩沖池
additional memory pool 額外內存池
配置文件的innodb:
# Comment the following if you are using InnoDB tables
#skip-innodb
innodb_data_home_dir = "D:/xampp/mysql/data"
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = "D:/xampp/mysql/data"
#innodb_log_arch_dir = "D:/xampp/mysql/data"
## 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
innodb_additional_mem_pool_size = 2M
## Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
這是my.ini的配置，更多的InnoDB的配置，可以看my_innodb_heavy_4G.ini
注釋：配置文件的值可能會根據不同的環境更改，上面的配置文件是在我安裝之後默認的
3、緩沖池是用來存放各種數據的緩存，InnoDB存儲引擎的工作方式是將資料庫文件按頁（每頁16K）讀取到緩沖池，然後按照最近最少使用（LRU）的演算法保留在緩沖池中的緩存數據
輸入：show engine innodb status\G;
『貳』 關於MYSQL配置文件中innodb_flush_log_at_trx_commit的疑問
這是關繫到事務日誌的一個參數,0或者2,只是定時的刷新到log buffer,
事務日誌..不知道你明白不..就是你說的也影響到更新數據的操作.但對正常的數據讀寫不會有影響...簡單來說..就是你事務提交了..,你就可以查到commit後的數據. 但這時並不一定寫入到磁碟了..可能在緩存..
這個參數也就是在commit的時候會有差異,如果為1,就每個事務提交就會要刷新到磁碟後才算提交完成....這種情況是保證了事務的acid,但性能會有很大的影響...
如果為0或者2,只要commit了就算完成了...0和2的區別在於
0：當mysql掛了之後，可能會損失前一秒的事務信息
2：當mysql掛了之後，如果系統文件系統沒掛，不會有事務丟失
『叄』 MYSQL 5.6 X86 如何修改 innodb_flush_log_at_trx_commit
這個是系統變數....
臨時改:set global innodb_flush_log_at_trx_commit=2;重啟資料庫後失效
永久改:win下面找到my.ini 在[mysqld] 中加入 innodb_flush_log_at_trx_commit=2 .需要重啟....
『肆』 mysql資料庫innodb的源文件怎麼導入到資料庫
binlog日誌也刪除了嗎？？？？可以試下這個恢復方法。
- 恢復策略
前面說到未提交的事務和回滾了的事務也會記錄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()
『伍』 如何從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了。
『陸』 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()
『柒』 MySQL的log-bin被關閉了innodb_flush_log_at_trx_commit和sync_binlog還有用嗎
1.准備工作
下載mysql的最新免安裝版本mysql-noinstall-5.1.53-win32.zip，解壓縮到相關目錄，如：d:\\ mysql-noinstall-5.1.53-win32。這個就是mysql的根目錄了。
2.配置
在根目錄下有幾個文件如下：
my-small.ini （這是針對一個小內存（〈= 64MB）的系統，MySQL 只會被時不時地用一下，很重要的是 mysqld 守護進程不會使用很多資源。）
my-medium.ini （這是針對一個小內存（32M- 64M）系統的，MySQL 扮演了一個比較重要的部分，或者當系統達到 128M 後 MySQL 被用來與其它程序（如一個 Web 伺服器）一起使用。）
my-large.ini （這是針對一個內存 = 512M 的大系統，系統主要運行 MySQL）
my-huge.ini （這是針對一個內存為 1G – 2G 的大系統，系統主要運行 MySQL）
my-innodb-heavy-4G.ini （這是一個針對 4G 內存系統（主要運行只有 InnoDB 表的 MySQL 並使用幾個連接數執行復雜的查詢）的 MySQL 配置文件例子）
對應自己的配置，自己選擇下，其他的就刪除吧。然後重命名成my.ini。編輯my.ini，在[mysqld]節點下增加如下幾句：
basedir= D:/mysql-noinstall-5.1.53-win32 #根目錄
datadir= D:/mysql-noinstall-5.1.53-win32/data #數據文件存放目錄
3.安裝服務
cmd：進入mysql的根目錄\bin：
mysqld --install MySQL
這樣用默認的 MySQL 為名稱添加了一個windows服務。要移除mysql服務：
mysqld –remove MySQL
設置服務為自動啟動：
sc config MySQL start= auto
4.啟動與關閉
復制代碼 代碼如下:
cmd：
net start MySQL --啟動
『捌』 mysql innodb 怎麼配置
你上面這些語句是正確的，如果你的my.ini裡面沒有，可以自己添加進去。
注意，如果你的機器是Unix的話，c:\mysql這樣的路徑要修改為UNIX的格式，例如/yusr/local/mysql