ALTER DATABASE db_name DEFAULT CHARACTER SET character_name [COLLATE ...];

把表默认的字符集和所有字符列（CHAR,VARCHAR,TEXT）改为新的字符集：

ALTER TABLE tbl_name CONVERT TO CHARACTER SET character_name [COLLATE ...]
如：ALTER TABLE logtest CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

只是修改表的默认字符集：

ALTER TABLE tbl_name DEFAULT CHARACTER SET character_name [COLLATE...];
如：ALTER TABLE logtest DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

修改字段的字符集：

ALTER TABLE tbl_name CHANGE c_name c_name CHARACTER SET character_name [COLLATE ...];
如：ALTER TABLE logtest CHANGE title title VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_general_ci;

查看数据库编码：

SHOW CREATE DATABASE db_name;

查看表编码：

SHOW CREATE TABLE tbl_name;

查看字段编码：

SHOW FULL COLUMNS FROM tbl_name;

来源：http://www.diannaowa.com/index.php/archives/233

脏读（dirty read） 

A事务读到B事务刚修改的值，但是B事务撤销了，也A事务读到的值就是假的了。

不可重复读（unrepeatable read） 

   不可重复读是指A事务读取了B事务已经提交的更改数据。假设A在取款事务的过程中，B往该账户转账100元，A两次读取账户的余额发生不一致：

幻象读（phantom read） 

幻象读与不可重复读的区分是，前者是新增时出现，后者是更改或删除出现。

    A事务读取B事务提交的新增数据，这时A事务将出现幻象读的问题。幻象读一般发生在计算统计数据的事务中，举一个例子，假设银行系统在同一个事务中，两次统计存款账户的总金额，在两次统计过程中，刚好新增了一个存款账户，并存入100元，这时，两次统计的总金额将不一致：  

    如果新增数据刚好满足事务的查询条件，这个新数据就进入了事务的视野，因而产生了两个统计不一致的情况。 

幻象读和不可重复读是两个容易混淆的概念，前者是指读到了其它已经提交事务的新增数据，而后者是指读到了已经提交事务的更改数据（更改或删除），为了避免这两种情况，采取的对策是不同的，防止读取到更改数据，只需要对操作的数据添加行级锁，阻止操作中的数据发生变化，而防止读取到新增数据，则往往需要添加表级锁——将整个表锁定，防止新增数据（Oracle使用多版本数据的方式实现）。 

第一类丢失更新 

    A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来： 

A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。 

 第二类丢失更新 

A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失：  

    上面的例子里由于支票转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。

第一类丢失更新和第二类丢失更新的差别：前者是由于撤销事务导致丢失更新，后者是因为更新被覆盖。

内容参考来源：http://tech.it168.com/db/t/2007-05-30/200705300938078_1.shtml

2.数据库ACID特征：

Atomic（原子性）：指整个数据库事务是不可分割的工作单元。

Consistency（一致性）：指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。

Isolation（隔离性）：指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。

Durability（持久性）：指的是只要事务成功结束，它对数据库所作的更新就必须永久保存下来。

3.数据库系统支持两种事务模式：

自动提交模式：每个SQL语句都是一个独立的事务，当数据库系统执行完一个SQL语句后，会自动提交事务。

手动提交模式：必须由数据库客户程序显示指定事务开始边界和结束边界。

4.MySQL中数据库表分为3种类型：

INNODB、BDB和MyISAM，其中MyISAM不支持数据库事务。MySQL中create table 语句默认为MyISAM类型。

5.并发问题

对于同时运行的多个事务，当这些事务访问数据库中相同的数据时，如果没有采取必要的隔离机制，就会导致各种并发问题，这些并发问题可归纳为以下几类：

A.第一类丢失更新：撤销一个事务时，把其他事务已提交的更新数据覆盖。

B.脏读：一个事务读到另一个事务为提交的更新数据。

C.幻读：一个事务读到另一个事务已提交的新插入的数据。

D.不可重复读：一个事务读到另一个事务已提交的更新数据。

E.第二类丢失更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新数据。

6.数据库系统四种事务隔离级别

A.Serializable（串行化）：一个事务在执行过程中完全看不到其他事务对数据库所做的更新。

B.Repeatable Read（可重复读）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，但是不能看到其他其他事务对已有记录的更新。

C.Read Commited（读已提交数据）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，而且能看到其他事务已经提交的对已有记录的更新。

D.Read Uncommitted（读未提交数据）：一个事务在执行过程中可以拷打其他事务没有提交的新插入的记录，而且能看到其他事务没有提交的对已有记录的更新。

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以有优先考虑把数据库系统的隔离级别设为Read Commited，它能够避免脏读，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

7.当数据库系统采用read Commited隔离级别时

会导致不可重复读喝第二类丢失更新的并发问题，可以在应用程序中采用悲观锁或乐观锁来避免这类问题。从应用程序的角度，锁可以分为以下几类：

A.悲观锁：指在应用程序中显示的为数据资源加锁。尽管能防止丢失更新和不可重复读这类并发问题，但是它会影响并发性能，因此应该谨慎地使用。

B.乐观锁：乐观锁假定当前事务操作数据资源时，不回有其他事务同时访问该数据资源，因此完全依靠数据库的隔离级别来自动管理锁的工作。应用程序采用版本控制手段来避免可能出现的并发问题。

8.悲观锁有两种实现方式：

A.在应用程序中显示指定采用数据库系统的独占所来锁定数据资源。SQL语句：select … for update，在Hibernate中使用get，load时如session.get(Account.class,new Long(1),LockMode,UPGRADE)

B.在数据库表中增加一个表明记录状态的LOCK字段，当它取值为“Y”时，表示该记录已经被某个事务锁定，如果为“N”，表明该记录处于空闲状态，事务可以访问它。增加锁标记字段就可以实现。

9.利用Hibernate的版本控制来实现乐观锁

乐观锁是由程序提供的一种机制，这种机制既能保证多个事务并发访问数据，又能防止第二类丢失更新问题。

在应用程序中可以利用Hibernate提供的版本控制功能来视线乐观锁，OR映射文件中的<version>元素和<timestamp>都具有版本控制的功能，一般推荐采用<version>

本文来源：http://blog.csdn.net/yueguangyuan/archive/2006/09/20/1253229.aspx

自然连接时的语句是 SELECT * FROM T1 JOIN T2，把表1,2的值全显示出来

等值连接（内连接），按照某个条件，只返回符合条件的值

左连接（LEFT JOIN）与左外连接一样，返回的结果包括左边的全部行，右边没有的用null填充

右连接（RIGHT JOIN）与右外连接一样，返回的结果包括右边的全部行，左边没有的用null填充

全连接(FULL JOIN) 相当于左右连接的并集，包含左右表为空的数据

（1） 存储过程允许标准组件式编程
存储过程在被创建以后可以在程序中被多次调用，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可随时对存储过程进行修改，但对应用程序源代码毫无影响（因为应用程序源代码只包含存储过程的调用语句），从而极大地提高了程序的可移植性。
（2） 存储过程能够实现较快的执行速度
如果某一操作包含大量的Transaction-SQL 代码或分别被多次执行，那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译的，在首次运行一个存储过程时，查询优化器对其进行分析、优化，并给出最终被存在系统表中的执行计划。而批处理的Transaction-SQL 语句在每次运行时都要进行编译和优化，因此速度相对要慢一些。

（3） 存储过程能够减少网络流量
对于同一个针对数据数据库对象的操作（如查询、修改），如果这一操作所涉及到的Transaction-SQL 语句被组织成一存储过程，那么当在客户计算机上调用该存储过程时，网络中传送的只是该调用语句，否则将是多条SQL 语句，从而大大增加了网络流量，降低网络负载。

（4） 存储过程可被作为一种安全机制来充分利用
系统管理员通过对执行某一存储过程的权限进行限制，从而能够实现对相应的数据访问权限的限制，避免非授权用户对数据的访问，保证数据的安全

缺点:

1,依赖于数据库厂商,难以移植(当一个小系统发展到大系统时,对数据库的要求也会发生改变)
2,业务逻辑大的时候,封装性不够,难调试难以维护
3,复杂的应用用存储过程来实现，就把业务处理的负担压在数据库服务器上了。没有办法通过中间层来灵活分担负载和压力.均衡负载等

参考：

http://www.javaeye.com/topic/734702

http://blog.csdn.net/fsclc/archive/2007/01/16/1484264.aspx

SELECT * FROM A UNION SELECT * FROM B

如果能确定没有重复行，建议使用UNION ALL，不用排序。

1. order by子句必须写在最后一个结果集里，并且其排序规则将改变操作后的排序结果。对于Union、Union All、Intersect、Minus都有效。
2. Union可以对字段名不同但数据类型相同的结果集进行合并；
3. 如果字段名不同的结果集进行Union，那么对此字段的Order by子句将失效。
4. Union，对两个结果集进行并集操作，不包括重复行，同时进行默认规则的排序；
5. Union All，对两个结果集进行并集操作，包括重复行，不进行排序；
6. Intersect，对两个结果集进行交集操作，不包括重复行，同时进行默认规则的排序；
7. Minus，对两个结果集进行差操作，不包括重复行，同时进行默认规则的排序。
8. 可以在最后一个结果集中指定Order by子句改变排序方式。

有如下的Feed表

id	userid	type		msg	who	time
1	2	add_twitter		hahah	1	2010-04-27 19:12:38
2	2	add_twitter		怎么啦	2	2010-04-27 19:12:44
3	4	add_twitter		asddas	3	2010-04-27 19:20:26
4	2	reply_twitter		放大法	4	2010-04-27 19:24:09
5	5	reply_twitter		噶	5	2010-04-27 19:24:13
6	3	add_twitter		saf	6	2010-04-27 19:35:48
7	2	add_twitter		先谢谢谢谢谢谢	7	2010-04-27 19:54:44

现在想要，按时间先后，把用户的id查询出来，每个id只出现一次。

当然，第一时间就想到用group by语句来分组嘛

SELECT * FROM feed GROUP BY userid ORDER BY TIME

可是，得到的结果并不是自己想要的，group by比order by先解析了，结果就是得到最旧的那一条。

正确的方法

使用子查询

SELECT * FROM
(SELECT * FROM feed ORDER BY TIME) AS T 
GROUP BY T.userid ORDER BY T.TIME

上面这句在mysql可以正常取值，但是在hibernate不能使用from 后面的子查询，杯具。。
换个折中的方法，以下方法只是为了取得userid而已

SELECT * FROM feed GROUP BY userid ORDER BY MAX(TIME)

举个例子：这是一个订车票的

城市表

CityID	CityName
1	广州
2	湛江
3	江门
4	肇庆
5	惠州
6	汕头

车次表

CarID	CarName	StartCityID	EndCityID
1	G001	1	2
2	G002	1	3

这里的StartCityID和EndCityID分别是城市表的外键

解决方法

现在要把对应的始发城市和终点城市的名称取到，mssql语句可以这样
方法一：

SELECT 始发站=c1.CityName,终点站=c2.CityName
FROM car,City c1,City c2
WHERE StartCityID = c1.CityID AND EndCityID = c2.CityID

方法二：

SELECT 始发站=c1.CityName,终点站=c2.CityName
FROM car
JOIN City c1 ON StartCityID = c1.CityID
JOIN City c2 ON EndCityID = c2.CityID

CREATE TABLE ritem(
	id INT IDENTITY(1,1)
);

触发器的基本写法

CREATE TRIGGER 触发器名 ON 数据表名 FOR (INSERT|update|delete)
AS 
BEGIN
	在这里写代码
END

定义变量，并赋值

CREATE TRIGGER t_insert_ritem ON ritem FOR INSERT
AS 
BEGIN
	DECLARE @id INT
	SELECT @id=id FROM inserted
	-- 从插入的数据获得ID的值，还有一个deleted
	-- inserted表示新的数据，deleted表示旧的数据（自己理解的，不知道对不对？）
 
	SET @id = @id - 1
	-- 另一种赋值
 
	PRINT @id
	-- 可以把值打印出来，在查询分析器结果可以看到
	raiserror('抛出错误 id的值为：%d',16,1,@id) 
	-- 也可以这样输出
 
	IF (@id<0) BEGIN
		ROLLBACK TRANSACTION
		-- 回滚事务
	END
 
	IF EXISTS(SELECT * FROM ritem WHERE id=@id) BEGIN
		-- 还可以用exists来判断是否为空
	END
END
 
CREATE TRIGGER TRIGGER_Update ON ritem
FOR UPDATE
AS
    IF UPDATE(UserName)
    BEGIN
	-- 判断UserName有没有更新
    END

　　1.插入操作(Insert)
　　Inserted表有数据，Deleted表无数据
　　2.删除操作(Delete)
　　Inserted表无数据，Deleted表有数据
　　3.更新操作(Update)
　　Inserted表有数据(新数据)，Deleted表有数据(旧数据)

当你更新一个数据想要把相关联的所有数据都更新的时候就要用游标(CURSOR)鸟~~MSSQL的遍历

1
2
3
4
5
6
7
8
9
10
11
12
13

	DECLARE @id INT, @rid INT
	DECLARE cur_tmp CURSOR FOR SELECT id,rid FROM ritem
	OPEN cur_tmp
	FETCH NEXT FROM cur_tmp INTO @id,@rid -- 这里是取到select的值
	WHILE @@FETCH_STATUS = 0
	BEGIN
 
	-- 在这中间加入循环
 
	FETCH NEXT FROM cur_tmp INTO @id,@rid
	END
	CLOSE cur_tmp
	DEALLOCATE cur_tmp -- 释放游标