少年阿宾

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