少年阿賓

select * from test into outfile '/home/user/test.txt'

在linux（centos）下 ，啟動了mysql 并給用戶文件讀寫的權利
grant file on *.* to root@localhost;

在linux系統上，目錄的權限全部是 rwxrwxrwx
chmod 777 ...
/home/user/test
drwxrwxrwx  4 root root  4096 Sep  3 18:42 home
drwxrwxrwx 10 mapuser mapuser 4096 Sep  4 03:41 user
drwxrwxrwx 5 mapuser mapuser 4096 Sep  3 17:57 test


在mysql下輸入
select * from test into outfile '/home/user/test.txt'
出現錯誤信息：
ERROR 1 (HY000): Can't create/write to file '/home/user/test.txt' (Errcode: 13)
當時如果是tmp目錄的話就不會有這個錯誤
select * from test into outfile '/tmp/test.txt'
Query OK, 0 rows test(0.00 sec)

難道只能是tmp目錄嗎？
有什么地方可以修改的嗎？
后來吧home的所有者改成了mysql
drwxrwxrwx  5 mysql mysql  4096 Sep  4 10:08 home
select * from test into outfile '/home/test.txt'

ERROR 1 (HY000): Can't create/write to file '/home/test.txt' (Errcode: 13)
也是同樣出錯。

這個有什么辦法可以寫入home目錄下面嗎？或者其他什么目錄，只要不是tmp目錄，有人說先寫入tmp目錄，再cp到想要的
目錄，這樣做是可以，不過比較麻煩，文件比較大，2-3G呢，

修改mysql的配置能實現嗎？還是修改文件的權限，這個是什么問題呢？


select * from test into outfile '/tmp/test.txt'
Query OK, 0 rows test(0.00 sec)

看一下產生的這個文件的owner 是誰。

select * from test into outfile '/home/test.txt'

ERROR 1 (HY000): Can't create/write to file '/home/test.txt' (Errcode: 13)
------------------------
從Errcode: 13來看是沒權限
你執行上面語句時，是用什么用戶執行的呢？檢查下這個用戶是否有權限吧

估計和權限沒關系，因為已經是777了。

看看是不是selinux打開了，如果沒什么特別需要的話，關了為好。

非root用戶，在mysql下執行的select * from test into outfile '/home/user/test.txt'


select * from test into outfile '/home/user/test.txt'該語句產生的文件是
-rw-rw-rw-    1 mysql    mysql          12  9月  4 21:12 test.txt
mysql組的mysql用戶的。

貌似和權限沒什么關系，我用root用戶登陸系統，執行mysql的語句，其結果還是一樣，寫入/home目錄時
select * from test into outfile '/home/test.txt'
ERROR 1 (HY000): Can't create/write to file '/home/test.txt' (Errcode: 13)
還是有這個問題。
selinux會阻止其他程序寫入操作？？
具體怎么改變一下selinx的配置呢

我理清是什么問題了。
在red hat系列的linux中selinux對哪些daemon可以進行怎么樣的操作是有限制的，mysql的select into outfile的命令是mysql的daemon來負責寫文件操作的。寫文件之前當然要具有寫文件的權限。而selinux對這個權限做了限制。如果 selinux是關閉的吧，這個命令執行是沒有問題的
mysql> select user from user into outfile '/home/test.txt';
Query OK, 2 rows affected (0.02 sec)
當時selinux開啟時
selinux對mysql的守護進程mysqld進行了限制。
mysql> select user from user into outfile '/home/test.txt';
ERROR 1 (HY000): Can't create/write to file '/home/test.txt' (Errcode: 13)
出現了沒有權限寫的error。
解決方法，可以關閉selinux。
可以在/etc/selinux中找到config
root用戶，
shell>vi /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#      enforcing - SELinux security policy is enforced.
#      permissive - SELinux prints warnings instead of enforcing.
#      disabled - SELinux is fully disabled.
SELINUX=enforcing

修改SELINUX=disabled關閉selinux就可以了，這個問題就可以解決了。
不過全部關閉SELINUX有帶來一些安全問題。
當然也可以，單獨給mysql的守護進程權限，
shell>getsebool -a可以查看當前的對系統一系列守護進程的權限情況。

lpd_disable_trans --> off
mail_read_content --> off
mailman_mail_disable_trans --> off
mdadm_disable_trans --> off
mozilla_read_content --> off
mysqld_disable_trans --> off
nagios_disable_trans --> off
named_disable_trans --> off
named_write_master_zones --> off
nfs_export_all_ro --> on
nfs_export_all_rw --> on
nfsd_disable_trans --> off
nmbd_disable_trans --> off
nrpe_disable_trans --> off

shell>setsebool -P mysqld_disable_trans=1
開啟對mysql守護進程的權限，這樣
mysql> select user from user into outfile '/home/test.txt';
寫入到自定義的目錄就沒有問題了。
-P表示 是永久性設置，否則重啟之后又恢復預設值。
getsebool setsebool命令在root用戶下有權限。

除了對selinux的權限，當然首先要保證該目錄擁有讀寫權限。


在ubuntu下 ，可以對AppArmor(/etc/apparmor.d/usr.sbin.mysqld) 修改，類似selinux。
添加/etc/squid/lists/eighties.txt w,類似。

并發問題可歸納為以下幾類:

A.丟失更新：撤銷一個事務時，把其他事務已提交的更新數據覆蓋（A和B事務并發執行，A事務執行更新后，提交；B事務在A事務更新后，B事務結束前也做了對該行數據的更新操作，然后回滾，則兩次更新操作都丟失了）。

B.臟讀：一個事務讀到另一個事務未提交的更新數據（A和B事務并發執行，B事務執行更新后，A事務查詢B事務沒有提交的數據，B事務回滾，則A事務得到的數據不是數據庫中的真實數據。也就是臟數據，即和數據庫中不一致的數據）。

C.不可重復讀：一個事務讀到另一個事務已提交的更新數據（A和B事務并發執行，A事務查詢數據，然后B事務更新該數據，A再次查詢該數據時，發現該數據變化了）。

D. 覆蓋更新：這是不可重復讀中的特例，一個事務覆蓋另一個事務已提交的更新數據（即A事務更新數據，然后B事務更新該數據，A事務查詢發現自己更新的數據變了）。

E.虛讀（幻讀）：一個事務讀到另一個事務已提交的新插入的數據（A和B事務并發執行，A事務查詢數據，B事務插入或者刪除數據，A事務再次查詢發現結果集中有以前沒有的數據或者以前有的數據消失了）。

數據庫系統提供了四種事務隔離級別供用戶選擇：

A.Serializable（串行化）：一個事務在執行過程中完全看不到其他事務對數據庫所做的更新（事務執行的時候不允許別的事務并發執行。事務串行化執行，事務只能一個接著一個地執行，而不能并發執行。）。

B.Repeatable Read（可重復讀）：一個事務在執行過程中可以看到其他事務已經提交的新插入的記錄，但是不能看到其他其他事務對已有記錄的更新。

C.Read Commited（讀已提交數據）：一個事務在執行過程中可以看到其他事務已經提交的新插入的記錄，而且能看到其他事務已經提交的對已有記錄的更新。

D.Read Uncommitted（讀未提交數據）：一個事務在執行過程中可以看到其他事務沒有提交的新插入的記錄，而且能看到其他事務沒有提交的對已有記錄的更新。

隔離級別

數據庫系統有四個隔離級別（大多數數據庫默認級別為read commited）。對數據庫使用何種隔離級別要審慎分析，因為

1. 維護一個最高的隔離級別雖然會防止數據的出錯，但是卻導致了并行度的損失，以及導致死鎖出現的可能性增加。

2. 然而，降低隔離級別，卻會引起一些難以發現的bug。

SERIALIZABLE（序列化）

添加范圍鎖（比如表鎖，頁鎖等，關于range lock，我也沒有很深入的研究），直到transaction A結束。以此阻止其它transaction B對此范圍內的insert，update等操作。

幻讀，臟讀，不可重復讀等問題都不會發生。

REPEATABLE READ（可重復讀）

對于讀出的記錄，添加共享鎖直到transaction A結束。其它transaction B對這個記錄的試圖修改會一直等待直到transaction A結束。

可能發生的問題：當執行一個范圍查詢時，可能會發生幻讀。

READ COMMITTED（提交讀）

在transaction A中讀取數據時對記錄添加共享鎖，但讀取結束立即釋放。其它transaction B對這個記錄的試圖修改會一直等待直到A中的讀取過程結束，而不需要整個transaction A的結束。所以，在transaction A的不同階段對同一記錄的讀取結果可能是不同的。

可能發生的問題：不可重復讀。

READ UNCOMMITTED(未提交讀)

不添加共享鎖。所以其它transaction B可以在transaction A對記錄的讀取過程中修改同一記錄，可能會導致A讀取的數據是一個被破壞的或者說不完整不正確的數據。

另外，在transaction A中可以讀取到transaction B（未提交）中修改的數據。比如transaction B對R記錄修改了，但未提交。此時，在transaction A中讀取R記錄，讀出的是被B修改過的數據。

可能發生的問題：臟讀。

問題

我們看到，當執行不同的隔離級別時，可能會發生各種各樣不同的問題。下面對它們進行總結并舉例說明。

幻讀

幻讀發生在當兩個完全相同的查詢執行時，第二次查詢所返回的結果集跟第一個查詢不相同。

發生的情況：沒有范圍鎖。

例子：

SELECT  * FROM users WHERE age BETWEEN 10 AND 30 

INSERT INTO users VALUES ( 3 , 'Bob' , 27 ); 
COMMIT;

SELECT * FROM users WHERE age BETWEEN 10 AND 30;

如何避免：實行序列化隔離模式，在任何一個低級別的隔離中都可能會發生。

不可重復讀

在基于鎖的并行控制方法中，如果在執行select時不添加讀鎖，就會發生不可重復讀問題。

在多版本并行控制機制中，當一個遇到提交沖突的事務需要回退但卻被釋放時，會發生不可重復讀問題。

SELECT * FROM users WHERE id = 1; 

UPDATE users SET age = 21 WHERE id = 1 ; COMMIT; /* in multiversion concurrency*/    control, or lock-based READ COMMITTED * 

SELECT * FROM users WHERE id = 1; 

COMMIT; /* lock-based REPEATABLE READ */ 

在上面這個例子中，事務2提交成功，它所做的修改已經可見。然而，事務1已經讀取了一個其它的值。在序列化和可重復讀的隔離級別中，數據庫管理系統會返回舊值，即在被事務2修改之前的值。在提交讀和未提交讀隔離級別下，可能會返回被更新的值，這就是“不可重復讀”。

有兩個策略可以防止這個問題的發生：

1. 推遲事務2的執行，直至事務1提交或者回退。這種策略在使用鎖時應用。(悲觀鎖機制，比如用select for update為數據行加上一個排他鎖)

2. 而在多版本并行控制中，事務2可以被先提交。而事務1，繼續執行在舊版本的數據上。當事務1終于嘗試提交時，數據庫會檢驗它的結果是否和事務1、事務2順序執行時一樣。如果是，則事務1提交成功。如果不是，事務1會被回退。（樂觀鎖機制）

臟讀

臟讀發生在一個事務A讀取了被另一個事務B修改，但是還未提交的數據。假如B回退，則事務A讀取的是無效的數據。這跟不可重復讀類似，但是第二個事務不需要執行提交。 

SELECT * FROM users WHERE id = 1；

UPDATE users SET age = 21 WHERE id = 1 

SELECT FROM users WHERE id = 1；

COMMIT; /* lock-based DIRTY READ */ 

ANSI/ISO  SQL的四個isolation level

SERIALIZABLE

這是最高層次isolation level，這個層次的isolation實現了串行化的效果，即：幾個Transcation在執行時，其執行效果和某個串行序執行這幾個Transaction的效果是一樣的。使用Serializable層次的事務，其中的查詢語句在每次都必須在同樣的數據上執行，從而防止了phantom read，其實現機制是range lock。與下一個層次的不同之處在于range lock。

在基于鎖的DBMS中，Serializable直到事務結束才釋放select數據集上的讀、寫鎖。而且select查詢語句必須首先獲得range-locks才能執行。在非鎖并行的DBMS中，系統每當檢測到write collision時，一次只有一個write能被寫入。

range lock

Range lock記錄Serializable Transaction所讀取的key值范圍，阻止其他在這個key值范圍內的記錄被插入到表中。Range lock位于Index上，記錄一個起始Index和一個終止Index。在Range lock鎖定的Index范圍內，任何Update、Insert和Delete操作都是被禁止的，從而保證了Serializable中的操作每次都在同樣的數據集上進行。

REPEATABLE READS

在基于鎖的DBMS中，Repeatable Reads直到事務結束才釋放select數據集上的讀、寫鎖。但不會使用range lock，因此會產生Phantom Read。

READ COMMITTED

在基于鎖的DBMS中，Read Committed直到事務結束才釋放select數據集上的寫鎖，但讀鎖會在一個select完成后才被釋放。和Repeatable Read一樣，Read Committed不使用range lock，會產生Phantom read和Unrepeatable read。（注：這段主要參考wikipedia，我也搜索過Read Committed，基本都采用了這種說法。但我有一個疑問，既然write鎖直到事務提交才釋放，那么在這個階段是不會發生update操作的，在一個事務中的多個讀應該也不會產生不同的結果才對。望知之者指點一二，小弟不勝感激。）

READ UNCOMMITTED

這是Isolation Level的最底層，不僅會產生Phantom Read、Unrepeatable Read，還會有Dirty Read的風險。

Read phenomena

SQL 92標準將事務T1讀寫T2的操作分為三種，Phantom Read、Unrepeatable Read和Dirty Read         Users

id	name	age
1	Joe	20
2	Jill	25

Dirty reads (Uncommitted Dependency)

事務T1在讀取事務T2已經修改、但T2還未提交的數據時會發生Dirty Read。這個Isolation Level唯一能保證的是Update操作按順序執行，即事務中前面的update一定比后面的update先執行。

下面的這個例子是一個典型的Dirty Read

Transaction 1	Transaction 2
/* Query 1 */ SELECT age FROM users WHERE id = 1; /* will read 20 */
	/* Query 2 */ UPDATE users SET age = 21 WHERE id = 1; /* No commit here */
/* Query 1 */ SELECT age FROM users WHERE id = 1; /* will read 21 */
	ROLLBACK; /* lock-based DIRTY READ */

Non-repeatable reads

在一個事務T1中，如果對同一條記錄讀取兩次而值不一樣，那么就發生了Non-repeatable read。

在基于鎖的DBMS中，Non-repeatable read可能在未獲得read lock時進行select操作，或在select操作剛結束就釋放read lock時發生。在多版本并行控制的DBMS中，non-repeatable read可能在違背“受commit conflict影響的事務必須回滾“的原則時發生。

Transaction 1	Transaction 2
/* Query 1 */ SELECT * FROM users WHERE id = 1;
	/* Query 2 */ UPDATE users SET age = 21 WHERE id = 1; COMMIT; /* in multiversion concurrency control, or lock-based READ COMMITTED */
/* Query 1 */ SELECT * FROM users WHERE id = 1; COMMIT; /* lock-based REPEATABLE READ */

有兩種方式來防止non-repeatable read。第一種方式用鎖使T1和T2串行。另外一種方式是在多版本并行控制的DBMS中使用的。在這里，T2可以提交，而先于T2啟動的T1則在自己的Snapshot（快照）里繼續執行，在T1提交時，系統會檢查其結果是否與T1、T2序執行的結果一樣，如果一樣，則T1提交，否則T1必須回滾并生成一個serialization failure。

Phantom reads

Phantom read是指在一個事務中，執行兩個或多個同樣的查詢返回的結果集卻不相同的現象。這種現象發生在沒獲得range lock即進行select... where....操作時，解決方法是使用range lock。

Transaction 1	Transaction 2
/* Query 1 */ SELECT * FROM users WHERE age BETWEEN 10 AND 30;
	/* Query 2 */ INSERT INTO users VALUES ( 3, 'Bob', 27 ); COMMIT;
/* Query 1 */ SELECT * FROM users WHERE age BETWEEN 10 AND 30;

參考：

http://msdn.microsoft.com/en-us/library/ms191272.aspx
http://en.wikipedia.org/wiki/Isolation_%28database_systems%29