mysql時間轉換函式例項詳解

轉自:http://blog.csdn.net/twosecond/article/details/4438849
NOW() 
　 
SYSDATE() 
　 
CURRENT_TIMESTAMP 
以'YYYY-MM-DD HH:MM:SS'或YYYYMMDDHHMMSS格式返回當前的日期和時間，取決於函式是在一個字串還是在數字的上下文被使用。 
mysql> select NOW(); 
-> '1997-12-15 23:50:26' 
mysql> select NOW() + 0; 
-> 19971215235026 

UNIX_TIMESTAMP() 
　 
UNIX_TIMESTAMP(date) 
如果沒有引數呼叫，返回一個Unix時間戳記(從'1970-01-01 00:00:00'GMT開始的秒數)。如果UNIX_TIMESTAMP()用一個date引數被呼叫，它返回從'1970-01-01 00:00:00' GMT開始的秒數值。date可以是一個DATE字串、一個DATETIME字串、一個TIMESTAMP或以YYMMDD或YYYYMMDD格式的本地時間的一個數字。 
mysql> select UNIX_TIMESTAMP(); 
-> 882226357 
mysql> select UNIX_TIMESTAMP('1997-10-04 22:23:00'); 
-> 875996580 
當UNIX_TIMESTAMP被用於一個TIMESTAMP列，函式將直接接受值，沒有隱含的“string-to-unix-timestamp”變換。 

FROM_UNIXTIME(unix_timestamp) 
以'YYYY-MM-DD HH:MM:SS'或YYYYMMDDHHMMSS格式返回unix_timestamp引數所表示的值，取決於函式是在一個字串還是或數字上下文中被使用。 
mysql> select FROM_UNIXTIME(875996580); 
-> '1997-10-04 22:23:00' 
mysql> select FROM_UNIXTIME(875996580) + 0; 
-> 19971004222300 

FROM_UNIXTIME(unix_timestamp,format) 
返回表示 Unix 時間標記的一個字串，根據format字串格式化。format可以包含與DATE_FORMAT()函式列出的條目同樣的修飾符。 
mysql> select FROM_UNIXTIME(UNIX_TIMESTAMP(), 
'%Y %D %M %h:%i:%s %x'); 
-> '1997 23rd December 03:43:30 x' 

SEC_TO_TIME(seconds) 
返回seconds引數，變換成小時、分鐘和秒，值以'HH:MM:SS'或HHMMSS格式化，取決於函式是在一個字串還是在數字上下文中被使用。 
mysql> select SEC_TO_TIME(2378); 
-> '00:39:38' 
mysql> select SEC_TO_TIME(2378) + 0; 
-> 3938 

TIME_TO_SEC(time) 
返回time引數，轉換成秒。 
mysql> select TIME_TO_SEC('22:23:00'); 
-> 80580 
mysql> select TIME_TO_SEC('00:39:38'); 
-> 2378

mysql時間格式化

轉自:http://blog.csdn.net/sahusoft/article/details/4462804
DATE_FORMA T(date, format) 根據格式串format 格式化日期或日期和時間值date，返回結果串。

  可用DATE_FORMAT( ) 來格式化DATE 或DATETIME 值，以便得到所希望的格式。根據format字串格式化date值:

  %S, %s 兩位數字形式的秒（ 00,01, . . ., 59）

  %i 兩位數字形式的分（ 00,01, . . ., 59）

  %H 兩位數字形式的小時，24 小時（00,01, . . ., 23）

  %h, %I 兩位數字形式的小時，12 小時（01,02, . . ., 12）

  %k 數字形式的小時，24 小時（0,1, . . ., 23）

  %l 數字形式的小時，12 小時（1, 2, . . ., 12）

  %T 24 小時的時間形式（h h : m m : s s）

  %r 12 小時的時間形式（hh:mm:ss AM 或hh:mm:ss PM）

  %p AM 或P M

  %W 一週中每一天的名稱（ S u n d a y, Monday, . . ., Saturday）

  %a 一週中每一天名稱的縮寫（ Sun, Mon, . . ., Sat）

  %d 兩位數字表示月中的天數（ 00, 01, . . ., 31）

  %e 數字形式表示月中的天數（ 1, 2， . . ., 31）

%D 英文字尾表示月中的天數（ 1st, 2nd, 3rd, . . .）

  %w 以數字形式表示週中的天數（ 0 = S u n d a y, 1=Monday, . . ., 6=Saturday）

  %j 以三位數字表示年中的天數（ 001, 002, . . ., 366）

  % U 周（0, 1, 52），其中Sunday 為週中的第一天

  %u 周（0, 1, 52），其中Monday 為週中的第一天

  %M 月名（J a n u a r y, February, . . ., December）

  %b 縮寫的月名（ J a n u a r y, February, . . ., December）

  %m 兩位數字表示的月份（ 01, 02, . . ., 12）

  %c 數字表示的月份（ 1, 2, . . ., 12）

  %Y 四位數字表示的年份

  %y 兩位數字表示的年份

  %% 直接值“%”

  select date_format(日期欄位,’%Y-%m-%d’) as ‘日期’ from test

Mysql sql查詢時 if 的用法

SELECT qanswers.id,qanswers.question_id,qanswers.answer,users.nickname AS replier, 
 
users.groupname,IF(users.groupname='teacher',TRUE,FALSE) AS isTeacher 
 
FROM fa_user_question_answer AS qanswers  
 
LEFT JOIN fa_users AS users ON users.id=qanswers.user_id  
 
WHERE qanswers.question_id=11

Mysql子查詢例項

一，子選擇基本用法
1，子選擇的定義
子迭擇允許把一個查詢巢狀在另一個查詢當中。比如說：一個考試記分專案把考試事件分為考試（T）和測驗（Q）兩種情形。下面這個查詢就能只找出學生們的考試成績
select * from score where event_id in (select event_id from event where type='T');
2，子選擇的用法（3種）
? 用子選擇來生成一個參考值
在這種情況下，用內層的查詢語句來檢索出一個數據值，然後把這個資料值用在外層查詢語句的比較操作中。比如說，如果要查詢表中學生們在某一天的測驗成績，就應該使用一個內層查詢先找到這一天的測驗的事件號，然後在外層查詢語句中用這個事件號在成績表裡面找到學生們的分數記錄。具體語句為：
select * from score where
id=(select event_id from event where date='2002-03-21' and type='Q');
需要注意的是：在應用這種內層查詢的結果主要是用來進行比較操作的分法時，內層查詢應該只有一個輸出結果才對。看例子，如果想知道哪個美國總統的生日最小，構造下列查詢
select * from president where birth=min(birth)
這個查詢是錯的！因為MySQL不允許在子句裡面使用統計函式！min()函式應該有一個確定的引數才能工作!所以我們改用子選擇:
select * from president where birht=(select min(birth) from presidnet);
? exists 和 not exists 子選擇
上一種用法是把查間結果由內層傳向外層、本類用法則相反，把外層查詢的結果傳遞給內層。看外部查詢的結果是否滿足內部查間的匹配徑件。這種“由外到內”的子迭擇用法非常適合用來檢索某個資料表在另外一個數據表裡面有設有匹配的記錄

資料表t1
I1 C1 
1
2
3 A

資料表t2
I2 C2
C 2
3
4 C

A
先找兩個表內都存在的資料
select i1 from t1 where exists(select * from t2 where t1.i1=t2.i2);
再找t1表記憶體在,t2表內不存在的資料
select i1 form t1 where not exists(select * from t2 where t1.i1=t2.i2);

需要注意：在這兩種形式的子選擇裡，內層查詢中的星號代表的是外層查詢的輸出結果。內層查詢沒有必要列出有關資料列的名字，田為內層查詢關心的是外層查詢的結果有多少行。希望大家能夠理解這一點
? in 和not in 子選擇
在這種子選擇裡面，內層查詢語句應該僅僅返回一個數據列，這個資料列裡的值將由外層查詢語句中的比較操作來進行求值。還是以上題為例
先找兩個表內都存在的資料
select i1 from t1 where i1 in (select i2 from t2);
再找t1表記憶體在,t2表內不存在的資料
select i1 form t1 where i1 not in (select i2 from t2);
好象這種語句更容易讓人理解，再來個例子
比如你想找到所有居住在A和B的學生。
select * from student where state in(‘A','B')
二， 把子選擇查詢改寫為關聯查詢的方法。
1，匹配型子選擇查詢的改寫
下例從score資料表裡面把學生們在考試事件（T）中的成績（不包括測驗成績！）查詢出來。
Select * from score where event_id in (select event_id from event where type='T');
可見，內層查詢找出所有的考試事件，外層查詢再利用這些考試事件搞到學生們的成績。
這個子查詢可以被改寫為一個簡單的關聯查詢：
Select score.* from score, event where score.event_id=event.event_id and event.event_id='T';
下例可以用來找出所有女學生的成績。
Select * from score where student_id in (select student_id form student where sex = ‘f');
可以把它轉換成一個如下所示的關聯查詢：
Select * from score
Where student _id =student.student_id and student.sex ='f';
把匹配型子選擇查詢改寫為一個關聯查詢是有規律可循的。下面這種形式的子選擇查詢：
Select * from tablel
Where column1 in (select column2a from table2 where column2b = value);
可以轉換為一個如下所示的關聯查詢：
Select tablel. * from tablel,table2
Where table.column1 = table2.column2a and table2.column2b = value;
(2)非匹配(即缺失)型子選擇查詢的改寫
子選擇查詢的另一種常見用途是查詢在某個資料表裡有、但在另一個數據表裡卻沒有的東西。正如前面看到的那樣，這種“在某個資料表裡有、在另一個數據表裡沒有”的說法通常都暗示著可以用一個left join 來解決這個問題。請看下面這個子選擇查詢，它可以把沒有出現在absence資料表裡的學生(也就是那些從未缺過勤的學生)給查出來：
Select * from student
Where student_id not in (select student_id from absence);
這個子選擇查詢可以改寫如下所示的left join 查詢：
Select student. *
From student left join absence on student.student_id =absence.student_id
Where absence.student_id is null;
把非匹配型子選擇查詢改寫為關聯查詢是有規律可循的。下面這種形式的子選擇查詢：
Select * from tablel
Where column1 not in (select column2 from table2);
可以轉換為一個如下所示的關聯查詢：
Select tablel . *
From tablel left join table2 on tablel.column1=table2.column2
Where table2.column2 is null;
注意：這種改寫要求資料列table2.column2宣告為not null。

MYSQL事務中用行鎖

轉自:http://blog.csdn.net/webnoties/article/details/17219145
表鎖一般沒什麼用，因為在事務中解除表鎖的話會直接提交事務。
在事務中一般用到的是行鎖，即innodb引擎支援。

共享鎖例子：
#session1 會話1
start transaction;
SELECT * FROM feedback LIMIT 1,10;#無視
SELECT * FROM feedback LIMIT 1 FOR UPDATE;#只有加行鎖的這行是鎖定狀態(FOR

UPDATE)
COMMIT; #提交事務

#session2 會話2
start transaction;
  update feedback set title='會話1行鎖' where id=3;#該行無鎖，直接執行
  update feedback set title='會話1行鎖' where id=1;#有鎖，需要等待
COMMIT; #提交事務

排它鎖例子：
#session1 會話1
start transaction;
  UPDATE feedback set title='會話1排它鎖' where id=1 FOR SELECT;#排它鎖
COMMIT; #提交事務

#session2 會話2
start transaction;
  update feedback set title='會話1行鎖' where id=3;#該行無鎖，直接執行
  update feedback set title='會話1行鎖' where id=1;#有鎖，需要等待
COMMIT; #提交事務

因為之前用過oracle，知道利用select * for update 可以鎖表。所以很自然就想到在mysql中能

不能適應for update來鎖表呢。

學習參考如下

 由於InnoDB預設是Row-Level Lock，所以只有「明確」的指定主鍵，MySQL才會執行Row

lock (只鎖住被選取的資料例) ，否則MySQL將會執行Table Lock (將整個資料表單給鎖住)。
舉個例子:
假設有個表單products ，裡面有id跟name二個欄位，id是主鍵。
例1: (明確指定主鍵，並且有此筆資料，row lock)
SELECT * FROM products WHERE id='3' FOR UPDATE;
例2: (明確指定主鍵，若查無此筆資料，無lock)
SELECT * FROM products WHERE id='-1' FOR UPDATE;
例2: (無主鍵，table lock)
SELECT * FROM products WHERE name='Mouse' FOR UPDATE;
例3: (主鍵不明確，table lock)
SELECT * FROM products WHERE id<>&apos;3&apos; FOR UPDATE;
例4: (主鍵不明確，table lock)
SELECT * FROM products WHERE id LIKE &apos;3&apos; FOR UPDATE;
注1: FOR UPDATE僅適用於InnoDB，且必須在交易區塊(BEGIN/COMMIT)中才能生效。
注2: 要測試鎖定的狀況，可以利用MySQL的Command Mode ，開二個視窗來做測試。

由上面的InnoDB 已經交易區塊引出兩個問題。

1. what is InnoDB？

 MySQL是我們比較常用的一種資料庫軟體。它有著諸多的優點，如開源的，免費的等等。其

實它還有一個很好的特點，那就是有多種引擎可以供你選擇。如果賽車手能根據不同的路況，

地形隨手更換與之最適宜的引擎，那麼他們將創造奇蹟。然而目前他們還做不到那樣便捷的更

換引擎，但是我們卻可以！
     所謂知己知彼方可百戰不殆，要想將它們發揮到極致，首先我們應該來認識一下MySQL提

供給我們的這幾種引擎。
     一般來說，MySQL有以下幾種引擎：ISAM、MyISAM、HEAP、InnoDB和Berkley（BDB）

。注意：不同的版本支援的引擎是有差異的。

進一步：
如何檢視MySQL的當前儲存引擎？
一般情況下，mysql會預設提供多種儲存引擎,你可以通過下面的檢視:

看你的mysql現在已提供什麼儲存引擎:
mysql> show engines;

以上說明我的mysql預設使用的InnoDB引擎，並且支援MyISAM，memory，archive，

Mrg_myisam。
後面還跟著解釋， InnoDB 的解釋是：支援事務，行級別鎖定，外來鍵。

看你的mysql當前預設的儲存引擎:
mysql> show variables like &apos;%storage_engine%&apos;

你要看某個表用了什麼引擎(在顯示結果裡引數engine後面的就表示該表當前用的儲存引擎):
mysql> show create table 表名;

關於執行mysqldump出現拒絕訪問的解決

轉自:http://blog.csdn.net/lly20000/article/details/8511432
先嚐試

c:> mysql -uroot -p123456

如果可以正常進入
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 5.1.58-community MySQL Community Server (GPL)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
可以正常進入！

嘗試資料庫連線
mysqldump -uroot -p123456 test

如果這個也可以 大部分的問題 可能是你對你要輸出資料夾沒有寫的許可權

建立主鍵時報錯：ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it mus

轉自:http://blog.csdn.net/lichangzai/article/details/9788279

在建立有聯合主建的表時，出現下面的錯誤：

ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key

mysql> CREATE TABLE animals1 (

    ->     grp ENUM('fish','mammal','bird') NOT NULL,

    ->     id MEDIUMINT NOT NULL AUTO_INCREMENT,

    ->     name CHAR(30) NOT NULL,

    ->     PRIMARY KEY (grp,id)

    -> ) ENGINE=innodb;

ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key

--使用MyISAM儲存引擎時不會出現問題

mysql> CREATE TABLE animals1 (

    ->     grp ENUM('fish','mammal','bird') NOT NULL,

    ->     id MEDIUMINT NOT NULL AUTO_INCREMENT,

    ->     name CHAR(30) NOT NULL,

    ->     PRIMARY KEY (grp,id)

    -> ) ENGINE=MyISAM;

Query OK, 0 rows affected (0.00 sec)

--建立單欄位主鍵時不會出現問題

mysql> CREATE TABLE animals (

    ->      id MEDIUMINT NOT NULL AUTO_INCREMENT,

    ->      name CHAR(30) NOT NULL,

    ->      PRIMARY KEY (id)

    ->  );

Query OK, 0 rows affected (0.00 sec)
 

--檢視建立語句

mysql> show create table animals\G;

*************************** 1. row ***************************

       Table: animals

Create Table: CREATE TABLE `animals` (

  `id` mediumint(9) NOT NULL AUTO_INCREMENT,

  `name` char(30) NOT NULL,

  PRIMARY KEY (`id`)

)ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=latin1

1 row in set (0.00 sec)
 

ERROR:
No query specified
 

解決辦法：
把聯合主鍵中的自增列放在聯合主建的最左端，建立成功

mysql> drop table animals1;

mysql> CREATE TABLE animals1 (

    ->     grp ENUM('fish','mammal','bird') NOT NULL,

    ->     id MEDIUMINT NOT NULL AUTO_INCREMENT,

    ->     name CHAR(30) NOT NULL,

    ->     PRIMARY KEY (id,grp)

    -> );

Query OK, 0 rows affected (0.00 sec)

mysql> show create table animals1\G;

*************************** 1. row ***************************

       Table: animals1

Create Table: CREATE TABLE `animals1` (

  `grp` enum('fish','mammal','bird') NOT NULL,

  `id` mediumint(9) NOT NULL AUTO_INCREMENT,

  `name` char(30) NOT NULL,

  PRIMARY KEY (`id`,`grp`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

1 row in set (0.00 sec)

ERROR:
No query specified

mysql錯誤：鎖等待 Lock wait timeout exceeded; try restarting transaction

轉自:http://blog.csdn.net/mydriverc2/article/details/37693605
java.lang.Exception:
### Error updating database.  Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
### The error may involve defaultParameterMap
### The error occurred while setting parameters
### Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
; SQL []; Lock wait timeout exceeded; try restarting transaction; nested exception is java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction

select * from information_schema.innodb_trx 之後找到了一個一直沒有提交的只讀事務，

kill 到了對應的執行緒後ok 了。

根據這個事物的執行緒ID（trx_mysql_thread_id）。
執行命令：
kill 執行緒ID 
資料庫修復正常。
 
檢視正在鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 
 
檢視等待鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 

==============================================

轉載:http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html

MySQL 5.5 -- innodb_lock_wait 鎖 等待
記得以前，當出現：ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction，
要解決是一件麻煩的事情 ；
特別是當一個SQL執行完了，但未COMMIT，後面的SQL想要執行就是被鎖，超時結束；
DBA光從資料庫無法著手找出源頭是哪個SQL鎖住了；
有時候看看show engine innodb status , 並結合 show full processlist; 能暫時解決問題；但一直不能精確定位；

在5.5中，information_schema 庫中增加了三個關於鎖的表（MEMORY引擎）；
innodb_trx ## 當前執行的所有事務
innodb_locks ## 當前出現的鎖
innodb_lock_waits ## 鎖等待的對應關係

看到這個就非常激動 ； 這可是解決了一個大麻煩，先來看一下表結構

[email protected]  : information_schema 13:28:38> desc innodb_locks;
+-------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| lock_id | varchar(81) | NO | | | |#鎖ID
| lock_trx_id | varchar(18) | NO | | | |#擁有鎖的事務ID
| lock_mode | varchar(32) | NO | | | |#鎖模式
| lock_type | varchar(32) | NO | | | |#鎖型別
| lock_table | varchar(1024) | NO | | | |#被鎖的表
| lock_index | varchar(1024) | YES | | NULL | |#被鎖的索引
| lock_space | bigint(21) unsigned | YES | | NULL | |#被鎖的表空間號
| lock_page | bigint(21) unsigned | YES | | NULL | |#被鎖的頁號
| lock_rec | bigint(21) unsigned | YES | | NULL | |#被鎖的記錄號
| lock_data | varchar(8192) | YES | | NULL | |#被鎖的資料
+-------------+---------------------+------+-----+---------+-------+
10 rows in set (0.00 sec)

[email protected]  : information_schema 13:28:56> desc innodb_lock_waits;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| requesting_trx_id | varchar(18) | NO | | | |#請求鎖的事務ID
| requested_lock_id | varchar(81) | NO | | | |#請求鎖的鎖ID
| blocking_trx_id | varchar(18) | NO | | | |#當前擁有鎖的事務ID
| blocking_lock_id | varchar(81) | NO | | | |#當前擁有鎖的鎖ID
+-------------------+-------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

[email protected]  : information_schema 13:29:05> desc innodb_trx ;
+----------------------------+---------------------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+---------------------+------+-----+---------------------+-------+
| trx_id | varchar(18) | NO | | | |#事務ID
| trx_state | varchar(13) | NO | | | |#事務狀態：
| trx_started | datetime | NO | | 0000-00-00 00:00:00 | |#事務開始時間；
| trx_requested_lock_id | varchar(81) | YES | | NULL | |#innodb_locks.lock_id
| trx_wait_started | datetime | YES | | NULL | |#事務開始等待的時間
| trx_weight | bigint(21) unsigned | NO | | 0 | |#
| trx_mysql_thread_id | bigint(21) unsigned | NO | | 0 | |#事務執行緒ID
| trx_query | varchar(1024) | YES | | NULL | |#具體SQL語句
| trx_operation_state | varchar(64) | YES | | NULL | |#事務當前操作狀態
| trx_tables_in_use | bigint(21) unsigned | NO | | 0 | |#事務中有多少個表被使用
| trx_tables_locked | bigint(21) unsigned | NO | | 0 | |#事務擁有多少個鎖
| trx_lock_structs | bigint(21) unsigned | NO | | 0 | |#
| trx_lock_memory_bytes | bigint(21) unsigned | NO | | 0 | |#事務鎖住的記憶體大小（B）
| trx_rows_locked | bigint(21) unsigned | NO | | 0 | |#事務鎖住的行數
| trx_rows_modified | bigint(21) unsigned | NO | | 0 | |#事務更改的行數
| trx_concurrency_tickets | bigint(21) unsigned | NO | | 0 | |#事務併發票數
| trx_isolation_level | varchar(16) | NO | | | |#事務隔離級別
| trx_unique_checks | int(1) | NO | | 0 | |#是否唯一性檢查
| trx_foreign_key_checks | int(1) | NO | | 0 | |#是否外來鍵檢查
| trx_last_foreign_key_error | varchar(256) | YES | | NULL | |#最後的外來鍵錯誤
| trx_adaptive_hash_latched | int(1) | NO | | 0 | |#
| trx_adaptive_hash_timeout | bigint(21) unsigned | NO | | 0 | |#
+----------------------------+---------------------+------+-----+---------------------+-------+
22 rows in set (0.01 sec)

下面我們來動手看看資料吧：
##建立測試資料：
use test;
create table tx1
(id int primary key ,
c1 varchar(20),
c2 varchar(30))
engine=innodb default charset = utf8 ;

insert into tx1 values
(1,'aaaa','aaaaa2'),
(2,'bbbb','bbbbb2'),
(3,'cccc','ccccc2');

commit;

###產生事務；
### Session1
start transaction;
update tx1 set c1='heyf',c2='heyf' where id =3 ;

## 產生事務，在innodb_trx就有資料 ；
[email protected]  : information_schema 13:38:21> select * from innodb_trx G
*************************** 1. row ***************************
trx_id: 3669D82
trx_state: RUNNING
trx_started: 2010-12-24 13:38:06
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 2344
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: 1
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
1 row in set (0.00 sec)

### 由於沒有產生鎖等待，下面兩個表沒有資料 ；
[email protected]  : information_schema 13:38:31> select * from innodb_lock_waits G
Empty set (0.00 sec)

[email protected]  : information_schema 13:38:57> select * from innodb_locks G
Empty set (0.00 sec)

#### 產生鎖等待
#### session 2
start transaction;
update tx1 set c1='heyfffff',c2='heyffffff' where id =3 ;

[email protected]  : information_schema 13:39:01> select * from innodb_trx G
*************************** 1. row ***************************
trx_id: 3669D83 ##第2個事務
trx_state: LOCK WAIT ## 處於等待狀態
trx_started: 2010-12-24 13:40:07
trx_requested_lock_id: 3669D83:49:3:4 ##請求的鎖ID
trx_wait_started: 2010-12-24 13:40:07
trx_weight: 2
trx_mysql_thread_id: 2346 ##執行緒 ID
trx_query: update tx1 set c1='heyfffff',c2='heyffffff' where id =3
trx_operation_state: starting index read
trx_tables_in_use: 1 ##需要用到1個表
trx_tables_locked: 1 ##有1個表被鎖
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 0
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
*************************** 2. row ***************************
trx_id: 3669D82 ##第1個事務
trx_state: RUNNING
trx_started: 2010-12-24 13:38:06
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 2344
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: 1
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
2 rows in set (0.00 sec)

[email protected]  : information_schema 13:40:12> select * from innodb_locks G
*************************** 1. row ***************************
lock_id: 3669D83:49:3:4 ## 第2個事務需要的鎖
lock_trx_id: 3669D83
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 49
lock_page: 3
lock_rec: 4
lock_data: 3
*************************** 2. row ***************************
lock_id: 3669D82:49:3:4 ## 第1個事務需要的鎖
lock_trx_id: 3669D82
lock_mode: X
lock_type: RECORD
lock_table: `test`.`tx1`
lock_index: `PRIMARY`
lock_space: 49
lock_page: 3
lock_rec: 4
lock_data: 3
2 rows in set (0.00 sec)

[email protected]7.0.0.1  : information_schema 13:40:15> select * from innodb_lock_waits G
*************************** 1. row ***************************
requesting_trx_id: 3669D83 ## 請求鎖的事務
requested_lock_id: 3669D83:49:3:4 ## 請求鎖的鎖ID
blocking_trx_id: 3669D82 ## 擁有鎖的事務
blocking_lock_id: 3669D82:49:3:4 ## 擁有鎖的鎖ID
1 row in set (0.00 sec)