从Mysql 5.x的某个版本之后，MySQL的自动关闭空闲连接的特性被修改了，假如一个连接空闲到超时时间(默认28000秒8小时)，再次发起的Reconnect重新连接请求不会被接受，需要重新建立新连接，这就导致了SER的重连机制不能正常工作：SER只会在需要操作数据库时去使用同一个连接接口，断开了则发起重新连接请求，而且这个问题短期内SER也不能够解决。

　　下文中将具体讲述处理的方法：

　　1.使用Mysql 4.0或4.1版本，如果没有用到Mysql 5的一些新特性比如存储过程触发器之类。

　　2.定时重启Mysql服务器或Ser(由于本问题可能同样会影响到其它一些需要Mysql支持的服务器程序，所以重启Mysql服务器为好，但需要检测Mysql服务器不被使用的一个时间重启比较难确定)

　　3.设置my.cnf，有mysqld字段内增加参数：

　　[mysqld]port = 3306socket = /tmp/mysql.sockwait_timeout= 500000interactive_timeout = 500000(500000秒约五六天的超时时间，可根据实际需要选择一个数据库可能空闲的最长时间稍大的时间值。)重启Mysqld应用即可，也可以在执行mysqld时加-o wait_timeout=500000参数同样效果。

　　在MySQL客户端show variable时应该可以看到最后一条从默认的wait_time=28000变成500000了。

　　(假如重启Mysqld不生效，可以重启机子)

1. 有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，考虑建立聚集索引；
2. 经常同时存取多列，且每列都含有重复值可考虑建立组合索引；在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。

                 比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，
                 反而会  严重降低更新速度。
    3     组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

总结2   避免使用不兼容的数据类型

           例如float和INt、char和varchar、bINary和varbINary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:
SELECT name FROM employee WHERE salary ＞ 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

总结3  IS NULL 与IS NOT NULL

        不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在WHERE子句中使用is null或is not null的语句优化器是不允许使用索引的。

总结4   IN和EXISTS

EXISTS要远比IN的效率高。里面关系到full table scan和range scan。几乎所有的IN操作符子查询都可以改写为使用EXISTS的子查询。

SELECT dname, deptno FROM dept
WHERE deptno NOT IN
(SELECT deptno FROM emp);

改为

SELECT dname, deptno FROM dept
WHERE NOT EXISTS
(SELECT deptno FROM emp
WHERE dept.deptno = emp.deptno);

因为1中对emp进行了full table scan,这是很浪费时间的操作。而且1中没有用到emp的INdex，
因为没有WHERE子句。而2中的语句对emp进行的是range scan。

总结5  IN、OR子句常会使用工作表，使索引失效

如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。

总结6  避免或简化排序

应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
       索引中不包括一个或几个待排序的列；
       group by或order by子句中列的次序与索引的次序不一样；
       排序的列来自不同的表。

为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。

总结7  消除对大型表行数据的顺序存取

在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询 10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄??）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的WHERE子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：

SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008

虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：

SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008

这样就能利用索引路径处理查询。

总结8  避免相关子查询

        一个列的标签同时在主查询和WHERE子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

总结9  避免困难的正规表达式

MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：

SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”

即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为

SELECT ＊ FROM customer WHERE zipcode >“98000”，

在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：

SELECT ＊ FROM customer WHERE zipcode[2，3] >“80”，

在WHERE子句中采用了非开始子串，因而这个语句也不会使用索引。

不充份的连接条件

例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况：

SELECT sum(a.amount) FROM account a,card b WHERE a.card_no = b.card_no

20S

SELECT sum(a.amount) FROM account a,card b WHERE a.card_no = b.card_no and a.account_no=b.account_no

<1S
分析：
在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为：
外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O
在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：
外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O

可见，只有充份的连接条件，真正的最佳方案才会被执行。
多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。
不可优化的WHERE子句
例1
下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢：

SELECT * FROM record WHERE substrINg(card_no,1,4)='5378'

(13秒)

SELECT * FROM record WHERE amount/30< 1000

（11秒）

SELECT * FROM record WHERE convert(char(10),date,112)='19991201'

（10秒）
分析：
WHERE子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成下面这样：

SELECT * FROM record WHERE card_no like '5378%'

（< 1秒）

SELECT * FROM record WHERE amount< 1000*30

（< 1秒）

SELECT * FROM record WHERE date= '1999/12/01'

（< 1秒）

存储过程中，采用临时表优化查询

例
1．从parven表中按vendor_num的次序读数据：

SELECT part_num，vendor_num，price FROM parven ORDER BY vendor_num
INTO temp pv_by_vn

这个语句顺序读parven（50页），写一个临时表（50页），并排序。假定排序的开销为200页，总共是300页。

2．把临时表和vendor表连接，把结果输出到一个临时表，并按part_num排序：

SELECT pv_by_vn，＊ vendor.vendor_num FROM pv_by_vn，vendor
WHERE pv_by_vn.vendor_num=vendor.vendor_num
ORDER BY pv_by_vn.part_num
INTO TMP pvvn_by_pn
DROP TABLE pv_by_vn

这个查询读取pv_by_vn(50页)，它通过索引存取vendor表1.5万次，但由于按vendor_num次序排列，实际上只是通过索引顺序地读 vendor表（40＋2=42页），输出的表每页约95行，共160页。写并存取这些页引发5＊160=800次的读写，索引共读写892页。
3．把输出和part连接得到最后的结果：

SELECT pvvn_by_pn.＊，part.part_desc FROM pvvn_by_pn，part
WHERE pvvn_by_pn.part_num=part.part_num
DROP TABLE pvvn_by_pn

这样，查询顺序地读pvvn_by_pn(160页)，通过索引读part表1.5万次，由于建有索引，所以实际上进行1772次磁盘读写，优化比例为30∶1。

好了，搞定。

常量优化：

常量的计算是在语句被优化时一次性完成，而不是在每次执行时。下面是检索月薪大于2000的的表达式：
sal > 24000/12
sal > 2000
sal*12 > 24000
如果SQL语句包括第一种情况，优化器会简单地把它转变成第二种。
优化器不会简化跨越比较符的表达式，例如第三条语句，鉴于此，应尽量写用常量跟字段比较检索的表达式，而不要将字段置于表达式当中。否则没有办法优化，比如如果sal上有索引，第一和第二就可以使用，第三就难以使用。

操作符优化

优化器把使用LIKE操作符和一个没有通配符的表达式组成的检索表达式转换为一个“=”操作符表达式。
例如：优化器会把表达式ename LIKE 'SMITH'转换为ename = 'SMITH'
优化器只能转换涉及到可变长数据类型的表达式，前一个例子中，如果ENAME字段的类型是CHAR(10)， 那么优化器将不做任何转换。
一般来讲LIKE比较难以优化。

其中：
~~ IN 操作符优化：
    优化器把使用IN比较符的检索表达式替换为等价的使用“=”和“OR”操作符的检索表达式。
    例如，优化器会把表达式ename IN ('SMITH','KING','JONES')替换为
ename = 'SMITH' OR ename = 'KING' OR ename = 'JONES‘

~~ ANY和SOME 操作符优化:
    优化器将跟随值列表的ANY和SOME检索条件用等价的同等操作符和“OR”组成的表达式替换。
    例如，优化器将如下所示的第一条语句用第二条语句替换：
    sal > ANY (:first_sal, :second_sal)
    sal > :first_sal OR sal > :second_sal
    优化器将跟随子查询的ANY和SOME检索条件转换成由“EXISTS”和一个相应的子查询组成的检索表达式。
    例如，优化器将如下所示的第一条语句用第二条语句替换：
    x > ANY (SELECT sal FROM emp WHERE job = 'ANALYST')
    EXISTS (SELECT sal FROM emp WHERE job = 'ANALYST' AND x > sal)

~~ ALL操作符优化:
    优化器将跟随值列表的ALL操作符用等价的“=”和“AND”组成的表达式替换。例如：
    sal > ALL (:first_sal, :second_sal)表达式会被替换为：
    sal > :first_sal AND sal > :second_sal
    对于跟随子查询的ALL表达式，优化器用ANY和另外一个合适的比较符组成的表达式替换。例如
    x > ALL (SELECT sal FROM emp WHERE deptno = 10) 替换为：
    NOT (x <= ANY (SELECT sal FROM emp WHERE deptno = 10))
    接下来优化器会把第二个表达式适用ANY表达式的转换规则转换为下面的表达式：
    NOT EXISTS (SELECT sal FROM emp WHERE deptno = 10 AND x <= sal)

~~ BETWEEN 操作符优化:
    优化器总是用“>=”和“<=”比较符来等价的代替BETWEEN操作符。
    例如：优化器会把表达式sal BETWEEN 2000 AND 3000用sal >= 2000 AND sal <= 3000来代替。

~~ NOT 操作符优化:
    优化器总是试图简化检索条件以消除“NOT”逻辑操作符的影响，这将涉及到“NOT”操作符的消除以及代以相应的比较运算符。
    例如，优化器将下面的第一条语句用第二条语句代替：
    NOT deptno = (SELECT deptno FROM emp WHERE ename = 'TAYLOR')
    deptno <> (SELECT deptno FROM emp WHERE ename = 'TAYLOR')
    通常情况下一个含有NOT操作符的语句有很多不同的写法，优化器的转换原则是使“NOT”操作符后边的子句尽可能的简单，即使可能会使结果表达式包含了更多的“NOT”操作符。
    例如，优化器将如下所示的第一条语句用第二条语句代替：
    NOT (sal < 1000 OR comm IS NULL)
    NOT sal < 1000 AND comm IS NOT NULL sal >= 1000 AND comm IS NOT NULL

合理的索引设计

例：表record有620000行，试看在不同的索引下，下面几个SQL的运行情况：
语句A

SELECT count(*) FROM record
WHERE date >'19991201' and date < '19991214‘ and amount >2000

语句B

SELECT count(*) FROM record
WHERE date >'19990901' and place IN ('BJ','SH')

语句C

SELECT date,sum(amount) FROM record
group by date

1 在date上建有一个非聚集索引
A：(25秒)
B：(27秒)
C：(55秒)
分析：
date上有大量的重复值，在非聚集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。
2 在date上的一个聚集索引
A：（14秒）
B：（14秒）
C：（28秒）
分析：
在聚集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。
3 在place，date，amount上的组合索引
A：（26秒）
C：（27秒）
B：（< 1秒）
分析：
这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。
4 在date，place，amount上的组合索引
A： (< 1秒)
B：（< 1秒）
C：（11秒）
分析：
这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。

create table document( 
id int identity(1,1) not null, 
createuser_id int, 
document_title varchar(255), 
document_context text); 

在我现在开发的所有的系统中，我都采用了上述的方式，这样做属于未雨绸缪，一旦系统部署后再修改，可能就来不及了。

补充：近日公司的另一套CMS系统，已经出现 了上述问题。clob字段直接置于业务表中，现业务表记录已达20余万，查询的速度非常缓慢，被迫采用各种方式来解决。如果当初设计时就考虑到这方面就不会有这样的问题了。
PS：解决方案之一是，可以在Pojo中加入构造函数，参数中包含除clob字段外的所有其它字段，通过select new Pojo(field1,field2,.....) from Pojo的方式来处理。但要注意，fieldx不能为集合类型，只能为基本数据类型或Po类型。如public Pojo(Long id,String name,User usr,Date createDate){}

oracle.part1.rar、oracle.part2.rar、oracle.part3.rar

2.安装软件

分别安装“Oracle客户端”和“PLSQL Developer”软件。

3.配置

Oracle客户端的配制文件，默认会安装在“C:\Oracle\ora90\network\ADMIN”目录下，名为“tnsnames.ora”参考格式如下：

ORCL_192.168.1.246 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.246)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = orcl)
      (SERVER = DEDICATED)
    )
  )

zt, for MYISAM tables of older Mysql versions.

    近日，一位Discuz!老用户的论坛在发表回复时出现“The table is full”的提示，字面意义上是数据表已满的意思。因为很少有开发者遭遇单一表超过4G的情况，因此朋友间的讨论只能提供一些外围的信息。为解决此问题，我翻阅了很多资料，本文将以我此次问题的解决过程，介绍问题发生的原因及对策。

　　根据经验，The table is full提示往往出现在以下两种情况：

　　1. 表中设置了MAX_ROWS值，简单的说，若MAX_ROWS设置为100，而程序试图写入第101条记录，会出现此错误。

　　2. 表满。这种情况是本文讨论的重点。

　　我们认为MySQL在存取表的时候，存在一种定位分配规律。这个规律在默认的情况下，可以寻址4G以内的数据。超过这个大小，数据库将不能对数据定位，因而也无法进行读写。经过实验，这个限制是完全可以被突破的。

　　本例中，用户的系统环境为双Athlon处理器、SCSI硬盘72G、2G内存，用户的帖子表数据尺寸为4294963640，接近4G(4G的实际字节数为4294967296)。

　　首先SSH登录后，查看用户的系统信息：

　　# uname -a

　　Linux zichen.com 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686 athlon i386 GNU/Linux

　　证明是Linux系统，根据内核版本2.4.20-8smp，加上国内使用的常见系统，估计应该是redhat 9发行包。

　　# cat /etc/*release*

　　Red Hat Linux release 9 (Shrike)

　　这也证明了我们对系统版本的猜想。

　　然后看一下用的是什么文件系统。因为该用户并非高手，估计在装系统的时候就是一路回车下来，redhat 9默认的应该是EXT3，不过我们还是看一下：

　　# parted

　　GNU Parted 1.6.3

　　Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.

This program is free software, covered by the GNU General Public License.

　　This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of

　　MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

　　Using /dev/sda

　　Information: The operating system thinks the geometry on /dev/sda is 8942/255/63. Therefore, cylinder 1024 ends at 8032.499M.

　　(parted) print

　　Disk geometry for /dev/sda: 0.000-70149.507 megabytes

　　Disk label type: msdos

　　Minor Start End Type Filesystem Flags

　　1 0.031 101.975 primary ext3 boot

　　2 101.975 10103.378 primary linux-swap

　　证明确实是这样子。随后我们翻阅了EXT3文件系统的相关技术参数，EXT3是在EXT2基础上演变而来。EXT2所支持最大单一文件长度是2G，这个是很蹩脚的一个限制。EXT3做的很大一个改善就是将这个限制放大到了2TB，由此稍松一口气，起码不是操作系统上的限制。

　　经过朋友的开导，了解到单一文件大小有如下几个因素：

　　1. 文件系统的限制(如刚存所说EXT3的2TB限制)

　　2. 某一程序进程所能存取的第一文件最大尺寸(例如apache在Linux EXT3下能存取的最大尺寸为2G，诸如日志)

　　初步判断瓶颈就在上述其中第二项。随后找到myisamchk来显示一下表信息，证明了瓶颈就在MySQL本身的存取上。

　　# myisamchk -dv cdb_posts

　　结果就不贴了，其中有一项Max datafile length的值恰好就是4G。由此产生了瓶颈。

　　后来翻阅了N多资料，进行了N多尝试，也走了不少弯路，最终觉得还是官方文档比较可靠。比较老的文档里写道这是由于tmp_table_size的值造成的，也有提到用BIG-TABLES这个参数。事实证明这些都是歧途。大晚上的确实很累，这里只给出最终的解决方案吧，中间的就不罗嗦了。

　进到mysql客户端。

　　# mysql -uroot -p

　　Enter password: ******

　　Welcome to the MySQL monitor. Commands end with ; or g.

　　Your MySQL connection id is 59411 to server version: 4.0.18-standard

　　Type 'help;' or 'h' for help. Type 'c' to clear the buffer.

　　mysql> use ******

　　Database changed

　　mysql> ALTER TABLE cdb_posts MAX_ROWS=1000000000 AVG_ROW_LENGTH=15000;

　　因为这个表非常大，执行时间在双Athlon的专业服务器上竟然花了30分钟！

　　之后再通过myisamchk查看该表的信息：

　　# myisamchk -dv cdb_posts

　　MyISAM file: cdb_posts

　　Record format: Packed

　　Character set: latin1 (8)

　　File-version: 1

　　Creation time: 2004-08-30 22:19:48

　　Recover time: 2004-08-30 22:42:47

　　Status: open,changed

　　Auto increment key: 1 Last value: 1063143

　　Data records: 619904 Deleted blocks: 5

　　Datafile parts: 619909 Deleted data: 323872

　　Datafile pointer (bytes): 6 Keyfile pointer (bytes): 4

　　Datafile length: 4295287332 Keyfile length: 40421376

　　Max datafile length: 281474976710654 Max keyfile length: 4398046510079

　　Recordlength: 149

　　table description:

　　Key Start Len Index Type Rec/key Root Blocksize

　　1 1 4 unique unsigned long 1 4535296 1024

　　2 5 2 multip. unsigned short 13776 12540928 1024

　　3 111 4 multip. unsigned long 1 18854912 1024

　　4 28 3 multip. uint24 18 24546304 1024

　　5 7 3 multip. uint24 7 32827392 1024

　　111 4 unsigned long 1

　　6 7 3 multip. uint24 7 40418304 1024

　　28 3 uint24

　　令人振奋的事情发生了，该表的 Max datafile length: 281474976710654 Max keyfile length: 4398046510079，即最大数据尺寸(MYD文件)达到了2TB，最大索引尺寸(MYI)仍然为4G。

　　由此默认的4G限制被突破了。关于其中的原理，其实很简单：假设你有一个日记本，上面有10页纸可以写东西，编排目录只需要1个字节(因为0～9就够了)。如果你把这本子又塞进两张纸，变成12页，1个字节的目录空间就无法寻址到后面的两页中，进而产生了错误。上面那个ALTER语句中的数值都是我为保证成功，取的比较大的值(因为ALTER一次实在是太慢了，没时间在那乱试验)，相当于告诉数据库，这个本子有1000000000页，每页平均有 15000个字节。这样数据库便知道这是很大的一个本子，因此不遗余力的拿出了100页(假设说)做目录编排，这样这个新的目录就可以寻址到日记本的所有内容了。错误消失。

　　惟一的缺点就是，目录占用的空间多了一些，但已经微乎其微了，做了这种改变其实4G的文件尺寸大小只增大了1M多，非常令人振奋。

所谓悲观锁
先从悲观锁开始说。在SqlServer等其余很多数据库中，数据的锁定通常采用页级锁的方式，也就是说对一张表内的数据是一种串行化的更新插入机制，在任何时间同一张表只会插1条数据，别的想插入的数据要等到这一条数据插完以后才能依次插入。带来的后果就是性能的降低，在多用户并发访问的时候，当对一张表进行频繁操作时，会发现响应效率很低，数据库经常处于一种假死状态。而Oracle用的是行级锁，只是对想锁定的数据才进行锁定，其余的数据不相干，所以在对Oracle表中并发插数据的时候，基本上不会有任何影响。

注：对于悲观锁是针对并发的可能性比较大，而一般在我们的应用中用乐观锁足以。

Oracle的悲观锁需要利用一条现有的连接，分成两种方式，从SQL语句的区别来看，就是一种是for update，一种是for update nowait的形式。比如我们看一个例子。首先建立测试用的数据库表。

CREATE TABLE TEST(ID,NAME,LOCATION,VALUE,CONSTRAINT test_pk PRIMARY KEY(ID))AS SELECT deptno, dname, loc, 1 FROM scott.dept 

这里我们利用了Oracle的Sample的scott用户的表，把数据copy到我们的test表中。首先我们看一下for update锁定方式。首先我们执行如下的select for update语句。

select * from test where id = 10 for update 

通过这条检索语句锁定以后，再开另外一个sql*plus窗口进行操作，再把上面这条sql语句执行一便，你会发现sqlplus好像死在那里了，好像检索不到数据的样子，但是也不返回任何结果，就属于卡在那里的感觉。这个时候是什么原因呢，就是一开始的第一个Session中的select for update语句把数据锁定住了。由于这里锁定的机制是wait的状态(只要不表示nowait那就是wait)，所以第二个Session(也就是卡住的那个sql*plus)中当前这个检索就处于等待状态。当第一个session最后commit或者rollback之后，第二个session中的检索结果就是自动跳出来，并且也把数据锁定住。不过如果你第二个session中你的检索语句如下所示。

select * from test where id = 10 

也就是没有for update这种锁定数据的语句的话，就不会造成阻塞了。另外一种情况，就是当数据库数据被锁定的时候，也就是执行刚才for update那条sql以后，我们在另外一个session中执行for update nowait后又是什么样呢。比如如下的sql语句。 由于这条语句中是制定采用nowait方式来进行检索，所以当发现数据被别的session锁定中的时候，就会迅速返回ORA-00054错误，内容是资源正忙, 但指定以 NOWAIT 方式获取资源。所以在程序中我们可以采用nowait方式迅速判断当前数据是否被锁定中，如果锁定中的话，就要采取相应的业务措施进行处理。

select * from test where id = 10 for update nowait 

那这里另外一个问题，就是当我们锁定住数据的时候，我们对数据进行更新和删除的话会是什么样呢。比如同样，我们让第一个Session锁定住id=10的那条数据，我们在第二个session中执行如下语句。

update test set value=2 where id = 10 

这个时候我们发现update语句就好像select for update语句一样也停住卡在这里，当你第一个session放开锁定以后update才能正常运行。当你update运行后，数据又被你update语句锁定住了，这个时候只要你update后还没有commit，别的session照样不能对数据进行锁定更新等等。


总之，Oracle中的悲观锁就是利用Oracle的Connection对数据进行锁定。在Oracle中，用这种行级锁带来的性能损失是很小的，只是要注意程序逻辑，不要给你一不小心搞成死锁了就好。而且由于数据的及时锁定，在数据提交时候就不呼出现冲突，可以省去很多恼人的数据冲突处理。缺点就是你必须要始终有一条数据库连接，就是说在整个锁定到最后放开锁的过程中，你的数据库联接要始终保持住。与悲观锁相对的，我们有了乐观锁。乐观锁一开始也说了，就是一开始假设不会造成数据冲突，在最后提交的时候再进行数据冲突检测。

所谓乐观锁
在乐观锁中，我们有2种

第一种乐观锁的做法就是采用版本戳，这个在Hibernate中得到了使用。采用版本戳的话，首先需要在你有乐观锁的数据库table上建立一个新的column，比如为number型，当你数据每更新一次的时候，版本数就会往上增加1。比如同样有2个session同样对某条数据进行操作。两者都取到当前的数据的版本号为1，当第一个session进行数据更新后，在提交的时候查看到当前数据的版本还为1，和自己一开始取到的版本相同。就正式提交，然后把版本号增加1，这个时候当前数据的版本为2。当第二个session也更新了数据提交的时候，发现数据库中版本为2，和一开始这个session取到的版本号不一致，就知道别人更新过此条数据，这个

时候再进行业务处理，比如整个Transaction都Rollback等等操作。在用版本戳的时候，可以在应用程序侧使用版本戳的验证，也可以在数据库侧采用Trigger(触发器)来进行验证。不过数据库的Trigger的性能开销还是比较的大，所以能在应用侧进行验证的话还是推荐不用Trigger。

第二种做法和第二种做法有点类似，就是也新增一个Table的Column，不过这次这个column是采用timestamp型，存储数据最后更新的时间。在Oracle9i以后可以采用新的数据类型，也就是timestamp with time zone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是最高的，精确到微秒(还没与到纳秒的级别)，一般来说，加上数据库处理时间和人的思考动作时间，微秒级别是非常非常够了，其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。如果不想把代码写在程序中或者由于别的原因无法把代码写在现有的程序中，也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中。

是基于应用的版本机制来实现的。一般会在表里面设计一个版本字段v（我一般会把这个字段设为timestamp）。一般的update场景是这样：
1 select a, v from tb where id=1;   
假设得到数据是：['xxx', 11111]

2 update tb set a='yyyy', v=systimestamp where v=11111; //注意, v一般不会在业务操作的时候修改

这要求每一次update操作都变更版本字段。否则还是要进程间的数据还是会被相互覆盖。

乐观锁无法锁定其他应用对数据的操作。

Windows集成身份登陆>>>
C:\>osql -E
1>
登陆后执行系统存储过程
1> sp_password NULL,"newpass","sa"
2> go
密码已更改。
1> exit

再来看看sa混合模式登陆>>>
C:\>osql -SLocalhost -Usa -Pnewpass
1>
出现1>提示符表示登陆成功!

再来看看osql命令行下查询C:\>osql -SLocalhost -Usa -Pnewpass
1> use qz
2> Select count(*) from crjsj where kh=0
3> go

 -----------
           0

（1 行受到影响）
1>
查询系统表
1> select name from sysobjects where xtype='U'
2> go
 name

    如果，你在控制面板/管理工具/服务中双击打开OracleOraHome92TNSListener的服务看到其“可执行文件的路径”一栏为空时的处理方法：

    首先运行regedit.exe启动注册表编辑器，在HKEY_LOCAL_MACHINE/SYSTEM/ControlSet002/下的Services和CurrentControlSet/Services下找到OracleOraHome92TNSListener项，在右边窗口按右键，新建/字符串，取名ImagePath。

    双击新见的建，在“数值数据”项输入D:\oracle\ora92\bin\TNSLSNR.EXE（根据你自己的实际情况进行修改），确定完成。    

    再次在服务中双击打开OracleOraHome92TNSListener的服务看到其“可执行文件的路径”一栏已经显示了其正确的值。这时你可以启动监听了。

    同样也可以对OracleServiceKKDB进行操作，不过将ImagePath的值改为D:\oracle\ora92\bin\oracle.exe KKDB即可。

 select
 round(sysdate,'month') RM,
 round(sysdate,'year') RY,
 trunc(sysdate,'month') TM,
 trunc(sysdate,'year') TY
 from dual;

RM         RY         TM         TY
---------- ---------- ---------- ----------
01-8月 -06 01-1月 -07 01-7月 -06 01-1月 -06

4>转换函数

隐式转换:系统自动转换,如：
varchar2 or char to number
varchar2 or char to date
number to varchar2
date to varchar2

显式转换：人为以函数加以转换
日期，字符，数据三者之间可以相互转换:日期<-->字符<-->数据
日期格式:YYYY

日期-->字符
select to_char(sysdate,'yyyy-mm-dd') ch from dual

CH
----------
2006-07-28

数字-->字符
to_char(number,'format_model'),oramat_model有如下：
9---用对应数字表示
0---强制用０表示
$---加一$符号
L---前加本地货币单位表示
.---十进制点
,---千进制点

select to_char(0917,'l9999.99') local from dual
LOCAL
------------------
         RMB917.00

字符-->日期
tselect to_date('19830917','yyyy-mm-dd') bir from dual
BIR
----------
17-9月 -83

字符-->数字
select to_number('19821217','999999999') mybr from dual
      MYBR
----------
  19821217

注：所有函数均可以嵌套使用

5>通用函数

nvl(expr1,expr2)---expr1为空则显示expr2,否则显示expr1
nvl2(expr1,expr2,expr3)---expr1为空则显示expr2,否则显示expr3
nullif(expr1,expr2)---二个相等则显示空符,否则显示expr1
coalesce(expr1,expr2,...,exprn)---从expr1开始依次找到不为空的expr，找到就显示，直到最后，否则显

示exprn
case表达式，如下图:

 

6>多表查询
对普通的多表查询，也就是不加where条件的时候实际上查询结果是各表的笛卡尔集
外连接：oracle实现外连接时在=号的二边加+号就OK，当+在左边时称为右连接，反之为左连接,它常常用来当要求未受限制对象的表数据也要求显示时，如下：
select * from student

ID NAME                 ADDRESS
-------------------- --------------
1 zhangshan            zhejiang
3 lishi                hangzhou
7 lily                 guangzhou

select * from person

ID NAME                 ADDRESS
- -------------------- -----------
1 zhangshan            zhejiang
3 lishi                hangzhou
7 lily                 guangzhou

select p.id,p.sex,s.id,s.name,s.address from person p ,student s where p.id(+) = s.id

ID SEX          ID NAME                 ADDRESS
-- ---- ---------- -------------------- ------------
 1 boy           1 zhangshan            zhejiang
 3 girl          3 lishi                hangzhou
                 7 lily                 guangzhou

select p.id,p.sex,s.id,s.name,s.address from person p ,student s where p.id = s.id(+)

ID SEX          ID NAME                 ADDRESS
-- ---- ---------- -------------------- --------------
 1 boy           1 zhangshan            zhejiang
 2 girl
 3 girl          3 lishi                hangzhou
 4 boy
 5 girl

self-join，就是同一张表连接，用自连接的时候要注意排除重复的记录（自身，循环重复等），比如说找出student表中所有住在同一个地方的人。
select * from student

 ID NAME                 ADDRESS
--- -------------------- ---------
  1 zhangshan            zhejiang
  3 lishi                hangzhou
  7 lily                 guangzhou
  2 name2                guangzhou
  4 name4                guangzhou
  5 name5                hangzhou
  6 name6                shanghai
  8 name8                shanghai

没有排除重复记录时的结果：
 select t1.name,t2.name
 from student t1, student t2
 where t1.address = t2.address

NAME                 NAME
-------------------- --------------
lily                 lily
name2                lily
name4                lily
lily                 name2
name2                name2
name4                name2
lily                 name4
name2                name4
name4                name4
lishi                lishi
name5                lishi

NAME                 NAME
-------------------- --------------
lishi                name5
name5                name5
name6                name6
name8                name6
name6                name8
name8                name8
zhangshan            zhangshan

已选择18行

排除重复与循环记录之后：
select t1.name,t2.name,t1.address
 from student t1, student t2
 where t1.address = t2.address
and t1.id > t2.id

NAME                 NAME                 ADDRESS
-------------------- -------------------- -------------------
lily                 name2                guangzhou
name4                name2                guangzhou
lily                 name4                guangzhou
name5                lishi                hangzhou
name8                name6                shanghai

cross join,无条件连接，实际上跟不带where时一样得到的是笛卡尔集

natural join（也可以直接记作join），根据表中同名栏位来连接记录,若表中可能出现多个同名栏位，则用using(col_name)来指定所栏位。colname不能指定表的别名！限制条件用on来指定
select id,p.sex,id,s.name from person p join student s using(id);

  ID SEX          ID NAME
---- ---- ---------- --------------------
   1 boy           1 zhangshan
   2 girl          2 name2
   3 girl          3 lishi
   4 boy           4 name4
   5 girl          5 name5

在sql标准语法中,左(右)连接用left(right) out join,限制条件用on就可以了。

full out join完全外连接,顾名思义就是左外连接与右外连接都有
select id,p.sex,id,s.name from person p full join student s using(id);

  ID SEX          ID NAME
---- ---- ---------- ------------------
   1 boy           1 zhangshan
   3 girl          3 lishi
   2 girl          2 name2
   4 boy           4 name4
   5 girl          5 name5
   8               8 name8
   6               6 name6
   7               7 lily

    翻译自：http://mfm088.itpub.net/post/22599/250400
    在Oracle/PLSQL中，lpad函数将左边的字符串填充一些特定的字符，其语法格式如下：   

     lpad( string1, padded_length, [ pad_string ] )
     其中string1是需要粘贴字符的字符串
     padded_length是返回的字符串的数量，如果这个数量比原字符串的长度要短，lpad函数将会把字符串截取成padded_length;

     pad_string是个可选参数，这个字符串是要粘贴到string1的左边，如果这个参数未写，lpad函数将会在string1的左边粘贴空格。
    例如：
          

lpad('tech', 7);

将返回' tech'

lpad('tech', 2);	将返回'te'
lpad('tech', 8, '0');	将返回'0000tech'
lpad('tech on the net', 15, 'z');	将返回 'tech on the net'
lpad('tech on the net', 16, 'z');	将返回 'ztech on the net'

-----------------------

select a.*, Level from (select * from dlsys.tcUnit order by DisplayOrder) a
     start with a.SeniorUnitID is null
     connect by a.SeniorUnitID = prior a.UnitID