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