SQL语句：
是对数据库(数据)进行操作的惟一途径；
消耗了70%~90%的数据库资源；独立于程序设计逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低；
可以有不同的写法；易学，难精通。

SQL优化：
固定的SQL书写习惯，相同的查询尽量保持相同，存储过程的效率较高。
应该编写与其格式一致的语句，包括字母的大小写、标点符号、换行的位置等都要一致

ORACLE优化器：
在任何可能的时候都会对表达式进行评估，并且把特定的语法结构转换成等价的结构，这么做的原因是
要么结果表达式能够比源表达式具有更快的速度
要么源表达式只是结果表达式的一个等价语义结构
不同的SQL结构有时具有同样的操作（例如：= ANY (subquery) and IN (subquery)），ORACLE会把他们映射到一个单一的语义结构。

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

2 操作符优化：
优化器把使用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

如何编写高效的SQL:
当然要考虑sql常量的优化和操作符的优化啦，另外，还需要：

1 合理的索引设计：
例：表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中形成了索引覆盖，因而性能达到了最优。

总结1
缺省情况下建立的索引是非聚集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，考虑建立聚集索引；
经 常同时存取多列，且每列都含有重复值可考虑建立组合索引；在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员 表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

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的子查询。
例子：
语句1
SELECT dname, deptno FROM dept
WHERE deptno NOT IN
(SELECT deptno FROM emp);
语句2
SELECT dname, deptno FROM dept
WHERE NOT EXISTS
(SELECT deptno FROM emp
WHERE dept.deptno = emp.deptno);
明显的，2要比1的执行性能好很多
因为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子句中采用了非开始子串，因而这个语句也不会使用索引。

10 不充份的连接条件：
例：表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
（20秒）
将SQL改为：
SELECT sum(a.amount) FROM account a,card b WHERE a.card_no = b.card_no and a.account_no=b.account_no
（< 1秒）
分析：
在第一个连接条件下，最佳查询方案是将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秒）

11 存储过程中，采用临时表优化查询：
例
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。

好了，搞定。
其实sql的优化，各种数据库之间都是互通的

影响SQL server性能的关键三个方面(转贴)

关键词：Sql Server

转贴自:http://202.200.129.193/
1 逻辑数据库和表的设计
数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。一个好的逻辑数据库设计可以为

优化数据库和应用程序打下良好的基础。

标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。下面是一些使用标准化

表的一些好处。

A:由于表窄，因此可以使排序和建立索引更为迅速

B:由于多表，所以多镞的索引成为可能

C:更窄更紧凑的索引

D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引

多的情况下会对系统性能产生很大的影响

E:更少的空值和更少的多余值，增加了数据库的紧凑性

由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。
定义具有相关关系的主键和外来键时应该注意的事项主要是：用于连接多表的主键和参考的键要有相同的数据类型。

2 索引的设计
A:尽量避免表扫描
检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。
下面的两个条件可以提高索引的优化查询性能！
第一：在表中的column1列上有一个单索引
第二：在表中有多索引，但是column1是第一个索引的列
避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能
例如：下面的例子用了pubs数据库。
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
按下面几个列上建立的索引将会是对优化器有用的索引
?au_lname
?au_lname, au_fname
而在下面几个列上建立的索引将不会对优化器起到好的作用
?au_address
?au_fname, au_lname
考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上
将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。
对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的
histogram（柱状图）统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。
有用的索引会提高select语句的性能，包括insert,uodate,delete。
但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。
在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。
select count(distinct cloumn_name) from table_name
假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。
Unique values Index

5000 Nonclustered index
20 Clustered index
3 No index

镞索引和非镞索引的选择

<1:>镞索引是行的物理顺序和索引的顺序是一致的。页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读操作，因此镞索引常常能加速这样的操作。在至少有一个索引的表中，你应该有一个镞索引。
在下面的几个情况下，你可以考虑用镞索引：
例如： 某列包括的不同值的个数是有限的（但是不是极少的）
顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。
例如： 对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,<,<=等等来对列进行操作的列上。
select * from sales where ord_date between '5/1/93' and '6/1/93'
例如： 对查询时返回大量结果的列可以使用镞索引。
SELECT * FROM phonebook WHERE last_name = 'Smith'

当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。如果你建立了镞的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。
当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。
一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。

<2:>一个非镞的索引就是行的物理次序与索引的次序是不同的。一个非镞索引的叶级包含了指向行数据页的指针。
在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。
在有很多不同值的列上可以考虑使用非镞索引
例如：一个part_id列在一个part表中
select * from employee where emp_id = 'pcm9809f'
查询语句中用order by 子句的列上可以考虑使用镞索引

3 查询语句的设计

SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。
在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。
例如下面的例子，
select qty from sales where stor_id=7131
是很有效的比下面这个无限制的查询
select qty from sales
避免给客户的最后数据选择返回大量的结果集。允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。
这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。因为优化器关注的焦点就是where子句的查询，以利用有用的索引。在表中的每一个索引都可能成为包括在where子句中的侯选索引。为了最好的性能可以遵照下面的用于一个给定列column1的索引。
第一：在表中的column1列上有一个单索引
第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。
这时多索引是没有用的。
For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in
the pubs database,
下面这个query语句利用了au_lname上的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
AND au_fname = 'Johnson'
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_fname = 'Johnson'

[概述]

Taglib是JSP比较高级的技术。做为JSP开发人员来讲，不了解taglib是可以接受的。因为JSP的风格或者JAVA的风格就是一种简洁的美。如果技术太过复杂或者繁琐，就会在技术的汪洋中失去自我。

但是，当我们的项目变得越来越大，或者团队有了一些技术积累之后，很自然就会有将我们的开发工作提高一个层次的需要。当我们面对一些非常类似的界面或者程序单元的时候，我们会想到把这样的工作成果直接用于下一个项目。这样的问题可以由taglib来解决。

到此还没有真正说明一下taglib是什么。只要你从事过JSP的开发工作，你就已经使用过taglib了。只不过是在不知不觉中使用的。你一定不会忘记 <jsp:include />标记。实际上这就是一个taglib。Taglib直译做标记库，是JSP定义给开发人员可以使用自行定义的标记体系。也就是说，开发人员可以在JSP中使用自己定义的特殊标记。而该标记可以用作特定的用途。比如显示一个每个页都需要的公司版权信息。就可以不用复制粘贴相同的代码到每个页去了。

但是taglib可以完成的工作远远不止这些。由于每个自定义标记一定是一个完全的JAVA类，我们可以定义非常丰富的一组行为，并且可以通过自定义的attribute来控制它。

[实例]

我习惯用实例来说明问题。大家也许都对用户会话状态的检查不陌生。当用户登录到系统后，我们希望自动保持用户的登录状态。而这个过程在每个需要认证用户才能访问的程序单元都需要实现。通常我们需要访问预定义的session服务器变量，当这个变量不满足某值时即判定改用户为非法访问或者会话状态丢失。

我们来看一下使用taglib如何实现。我们需要编写一个仅处理该逻辑的标记。实现的最简单的逻辑：检查用户状态session值，不满足某值时即将用户转向一个预先设置的报错页。

以下是源码(CheckSessionTag.java)：
(省略了细节)

public class CheckSessionTag extends TagSupport
{
    public  int  doEndTag()
    {
         try
        {
            String member_id  =  (String) pageContext.getSession().getAttribute( " member_id " );
             if (member_id  ==   null   ||  member_id.equals( "" ))
            {
                pageContext.forward( " /home/check_session_fail.jsp " );
            }
        }
         catch (Exception e)
        {
             //  报告异常过程省略.
        }
         return  EVAL_PAGE;
    }
}

[分析]

在以上源码中，我们在使tag自动检查用户session变量中的"member_id"值，如果该值为空，则立即判定用户没有访问权限，则立即将流程导向一个预先设定的报错页：/home/check_session_fail.jsp.

类CheckSessionTag派生自：TagSupport(javax.servlet.jsp.tagext.TagSupport). 是一个从JAVA 1.3就开始支持的类库，位于servlet.jar包。java文档给出的描述是：

A base class for defining new tag handlers implementing Tag. The TagSupport class is a utility class intended to be used as the base class for new tag handlers. The TagSupport class implements the Tag and IterationTag interfaces and adds additional convenience methods including getter methods for the properties in Tag. TagSupport has one static method that is included to facilitate coordination among cooperating tags. Many tag handlers will extend TagSupport and only redefine a few methods.
(该类为所有taglib的基类。该类定义了实现标记的一系列接口。)

在实例CheckSessionTag类中，我们仅仅重写了doEndTag方法。没有向其容器：jsp页输出任何东西。但是该类在实际应用中是切实可行的。

以下是在一个成品项目中的某jsp中截取的片断：
<logic:checkSession />

当我们直接使用输入url的方式访问本页时，我们被立即带到了报告：用户会话状态丢失或者未经登录的页。
这就省却了我们习以为常的一项工作：以前我们必须复制相同的scriplet到每个jsp页。（实际上，也可以使用类似intercept filter的模式来处理此需求）。这使我们的开发工作变得reusable, flexiable, 和extendable。可以想象，如果我们想改变检查session的逻辑，则可以仅仅通过改变CheckSessionTag内部的逻辑就可以通盘改变。并且我们可以通过给logic:checkSession标记加上类似target=admin的attribute来限定只有管理员才可以访问的区域。这就是形成组件化开发的基本过程。

如何实施呢?


[实施过程]

我们需要做一系列工作来将taglib引入我们的工程。

web.xml
为了使jsp解析器可以识别我们的taglib必须将其配置在web.xml内。web.xml位于/WEB-INF目录内。
使用特定语法来配置我们的taglib:
web.xml(片断)

< web-app >

     < taglib >
         < taglib-uri > /WEB-INF/logic.tld </ taglib-uri >
         < taglib-location > /WEB-INF/logic.tld </ taglib-location >
     </ taglib >

< web-app >

该语法告诉容器到什么地方去寻找所有logic:开头的tag.

tld是taglib defination的缩写。即taglib定义。该文件定义了我们使用的标记，Java类如何加载，并且该标记如何工作。让我们来看一段实际的tld:
logic.tld(片断)

<? xml version="1.0" encoding="ISO-8859-1" ?>
<! DOCTYPE taglib
     PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2/EN"
     "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd" >

< taglib >
     < tlib-version > 1.0 </ tlib-version >
     < jsp-version > 1.2 </ jsp-version >
     < short-name > logic </ short-name >
     < uri > /taglibs/logic </ uri >

     < tag >
        < name > checkSession </ name >
        < tag-class > mbajob.common.tags.logic.CheckSessionTag </ tag-class >
        < body-content > empty </ body-content >
     </ tag >

我们注意到taglib标记内.
1． short-name: 标记的prefix名。
2． uri: 识别该taglib的名称。

tag标记：
1． name: 标记名（prefix:之后）
2． tag-class：类名（包含包名）
3． body-content: 标记内容模式，如果该标记没有内容则为empty.

将logic.tld放置在/WEB-INF下，此时确保编译好的CheckSessionTag类可以被容器访问到。即可完成配置。必须注意的是，不同的jsp容器的配置可能有差别。本文的配置是基于Resin 2.1.11

[应用]

建立一个jsp页。在源码的开头加入如下的预编译指令：(page)
<%@ taglib prefix="logic" uri="/WEB-INF/logic.tld" %>

此指令告诉编译器到哪里去寻找所有以logic:开头的标记的定义。

接下来在任意位置加入标记：<logic:checkSession />即可以工作了。当标记被实例化后，即自动执行doEndTag过程，检查session服务器变量值，之后将页过程跳转。


[深入一些：attribute]

有时候我们希望可以对标记进行一些定制。依旧拿checkSession做例：现在我们要限制两类用户访问系统：某
些部分仅允许具有管理员权限的用户访问。这样我们设想可以在<logic:checkSession target=admin />进行进一步定义。这需要在CheckSessionTag类中增加一些额外的逻辑。检查的过程很简单，取决于你的安全系统的分析，但是，我们写了target attribute如何是类可以得到该数据，这是一个关键的问题。

为了实现对tag增加可用的attribute, 需要做如下工作：
1． 为类增加相应的成员及相应读写器：
CheckSessionTag.java(片断): 

public class CheckSessionTag extends TagSupport
{
     private String target;

     public  void  setTarget(String t)
     {
         this .target  =  t;
     }

     public String getTarget()
     {
         return   this .target;
     }

    public  int  doEndTag()
    {
        
    }

2． 更改logic.tld:

.

     < tag >
        < name > checkSession </ name >
        < tag-class > mbajob.common.tags.logic.CheckSessionTag </ tag-class >
        < body-content > empty </ body-content >
        < attribute >
           < name > title </ name >
           < required > true </ required >
        </ attribute >
     </ tag >

为tag标记增加arrtibute节点，语法如下：

name: attribute名
required: 是否为必须的attribute

幸运的是，jsp内置地将attribute解释为java类的成员，我们无需显式地获取该值，即可直接使用。也就是说，我们只要在tag内指定了target=admin, 那么，CheckSessionTag在活着的时候就自动获取该值，可以在逻辑中直接使用。

这样，我们就可以给tag增加任意的attribute.


[入门以后]

到此为止，我么就可以写一些类似的简单的tag了。根据不同的需求，完成不同的逻辑。当我们开发一个新的tag的时候，我们在logic.tld里增加一个tag子标记。设置好相应的类型。如果需要，我们可以把我们已经写好的tag们完全的移植到第二个项目中使用，仅仅做很少的更改。而更改也仅仅限于对java源代码。

在我和我的团队的实际经验中，taglib最多的应用还是在设计一系列特殊的UI. 例如类似于选择省市多级行政区域的选择器。为了放置在HTML中嵌入过多scriplet和脚本，我们的做法通常是将其写在组装好的tag里；为了形成整个应用一致的外观，我们设计了一套用于组装页构图的框架；为了向jsp输出集合数据，我们设计了可以绑定数据的呈现器。经过很长一个时期的工作，我们发现我们的项目中jsp页内仅有很少的html, 而完全是有taglib组成的。最终，我们的taglib按照layout, logic, element, form分类，已经形成了比较大的规模。我们甚至完成了apache的struts框架完成的一部分工作。甚至做得更灵活。所有这些工作中积累的思想甚至影响到我在.NET平台下的技术思路。

为了不使篇幅太长，我不准备在本文再做深入的探索。仅仅介绍taglib入门级的一些东西。有时间的话，可能会再次写一些高级一些的taglib的设计方法。


[与ASP.NET Web Custom Control]

不能说taglib与ASP.NET Web Custom Control有什么可比性。但是我习惯将二者放到一起看。因为因为在某些实际项目中，我确实从二者之间找到一些共性。甚至有时候创作一些组件的时候实现是完全相同的。
1． 二者都定义了当标记输出开始标记和结束标记时的过程。
2． 二者都可以跨应用使用。
3． 可以使用相同的HTML和脚本。

但比较起来，ASP.NET Web Custom Control更高级一些。可以在容器中直接以对象的形式访问。并且可以定义方法，事件。意即可以完全控制一个控件。

而taglib同样有优点，例如可以嵌套使用，开发成本低等。最关键的是，taglib具有做为java产品的精细，小巧和活泼。他们分别是有着不同风格的优秀技术。

参考文档
taglib最佳实践(IBM developerWorks中文站)
http://www-900.ibm.com/developerWorks/cn/java/j-jsp07233/

○用二分钟配置：

将下载的oscache-2.1.1-full.zip解压，你会看到oscache-2.1.1.jar 及一些目录 docs、etc、lib、src。
现在将 etc目录下oscache.properties 、oscache.tld 及 oscache-2.1.1.jar 文件复制到你的应用服务器目录下

使用tomcat，jdk1.4 配置例：
         D:\Tomcat 5.0\webapps\ROOT\WEB-INF\lib\oscache-2.1.1.jar
         D:\Tomcat 5.0\webapps\ROOT\WEB-INF\classes\oscache.properties
         D:\Tomcat 5.0\webapps\ROOT\WEB-INF\classes\oscache.tld

oscache.properties 文件配置参数说明：
cache.memory
值为true 或 false ，默认为在内存中作缓存，
如设置为false，那cache只能缓存到数据库或硬盘中，那cache还有什么意义：）
cache.capacity
缓存元素个数
cache.persistence.class
持久化缓存类，如此类打开，则必须设置cache.path信息
cache.cluster 相关
为集群设置信息。如
cache.cluster.multicast.ip为广播IP地址
cache.cluster.properties为集群属性

再将 D:\Tomcat 5.0\webapps\ROOT\WEB-INF\web.xml 文件中添加如下代码
<taglib>
<taglib-uri>oscache</taglib-uri>
<taglib-location>/WEB-INF/classes/oscache.tld</taglib-location>
</taglib>

就是这么简单，OSCache就配置好了。

○再用二分钟测试一下：

编写jsp文件
======================cache1.jsp 内容如下=================
<%@ page contentType="text/html;charset=GBK"%>
<%@ page import="java.util.*" %>
<%@ taglib uri="oscache" prefix="cache" %>
<html>
<body>
没有缓存的日期: <%= new Date() %><p>
<!--自动刷新-->
<cache:cache time="30">
每30秒刷新缓存一次的日期: <%= new Date() %> <p>
</cache:cache>

<!--手动刷新-->
<cache:cache key="testcache">
手动刷新缓存的日期: <%= new Date() %> <p>
</cache:cache>
<a href="http://dev.csdn.net/article/"cache2.jsp">手动刷新</a></body>
</html>
=========================================================

====================cache2.jsp 执行手动刷新页面如下===========
<%@ page contentType="text/html;charset=GBK"%>
<%@ taglib uri="oscache" prefix="cache" %>
<html>
<body>缓存已刷新...<p>

<cache:flush key="testcache" scope="application"/>

<a href="http://dev.csdn.net/article/"cache1.jsp">返回</a></body>
</html>
==========================================================       

其他： 缓存过滤器 CacheFilter
可以让你所有.jsp页面自动缓存。

你可以在web.xml中定义缓存过滤器，定义特定资源的缓存。
<filter>
<filter-name>CacheFilter</filter-name>
<filter-class>com.opensymphony.oscache.web.filter.CacheFilter</filter-class>
<init-param>
<param-name>time</param-name>
<param-value>60</param-value>
</init-param>
<init-param>
<param-name>scope</param-name>
<param-value>session</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CacheFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
上面定义将缓存所有.jsp页面，缓存刷新时间为60秒，缓存作用域为Session

注意，CacheFilter只捕获Http头为200的页面请求，即只对无错误请求作缓存，
而不对其他请求（如500,404,400）作缓存处理

此文完。。谢谢观看。

1、POJO 缓存
这种方式的缓存直接调用OSCache的API进行，主要用于处理页面内容会根据参数动态改变，可以将参数设置为key值来保存数据：
首先，声明成员变量：
 // OSCache Adminitrator instance
 private static GeneralCacheAdministrator cacheAdmin = null;
其次，进行初始化：
 public RingArtistAction() {
  cacheAdmin = new GeneralCacheAdministrator();
 }
将POJO进行缓存：
  // Cache data key and refresh period
  String key = sex + ":" + place;
  int refreshPeriod = Constants.getIntegerValue(Constants.OSCACHE_REFRESH_PERIOD).intValue();
  try {
      // Get from the cache
   artists = (Map) cacheAdmin.getFromCache(key, refreshPeriod);
  } catch (NeedsRefreshException nre) {
      try {
          // Get the value (probably from the database)
    int count = getArtistCount(sex, place, errors);
    artists = getArtistData(sex, place, count, errors);
          // Store in the cache
    cacheAdmin.putInCache(key, artists);
      } catch (Exception ex) {
          // We have the current content if we want fail-over.
    artists = (Map) nre.getCacheContent();
          // It is essential that cancelUpdate is called if the
          // cached content is not rebuilt
    cacheAdmin.cancelUpdate(key);
    ex.printStackTrace();
      }
  }
 
2、HTTP Response 缓存
这种方式的缓存用来处理整个页面的内容固定，不会根据参数动态改变：
首先在web.xml中配置CacheFilter：
 <filter>
  <filter-name>CacheFilter</filter-name>
  <filter-class>com.opensymphony.oscache.web.filter.CacheFilter</filter-class>
  <init-param>
   <param-name>time</param-name>
   <param-value>86400</param-value>
  </init-param>
  <init-param>
   <param-name>scope</param-name>
   <param-value>application</param-value>
  </init-param>
 </filter>
将所有需要缓存的页面加入filter-mapping：
 <filter-mapping>
  <filter-name>Set Character Encoding</filter-name>
  <url-pattern>/*</url-pattern>
 </filter-mapping>
注意，只有返回状态为200（HttpServletResponse.SC_OK）的内容才会被缓存

3、JSP Tag 缓存
JSP Tag缓存主要用于缓存JSP页面的局部内容：
  <cache:cache key="especialcategory" cron="* 5 * * *">
  <jsp:include page="/ringcategory.do" flush="true" >
    <jsp:param name="ringType" value="1"/>
  </jsp:include>
  </cache:cache>

4、O/R Data Access 缓存
请阅读参考资料的内容获取详情。

参考资料：
Taking the load off: OSCache helps databases cope：http://www.theserverside.com/articles/article.tss?l=OSCacheHelpsDatabases

子选择器:
相对来说，简化html文件的代码更加重要，因此在css中使用子选择器非常有益，同时也使css代码更加容易理解。比如下面的代码：
<div id="sub_nav">
<ul>
<li> <a href="#">Item 1</a></li>>
<li> <a href="#">Item 2</a></li>
<li> <a href="#">Item 3</a></li>
</ul>
</div>
如果div li a都有各自的式样,采用子选择器,可以省略代码中li 和a 的class属性，从而简化代码：
#sub_nav { /* Some styling */ }
#sub_nav li { /* Some styling */ }
#sub_nav a { /* Some styling */ }
组选择器：
当一些元素类型、class或者id都有共同的一些属性，你就可以使用组选择器来避免多次的重复定义。这可以节省不少字节。
例如：定义所有标题的字体、颜色和margin，你可以这样写：
h1,h2,h3,h4,h5,h6 {
font-family:"Lucida Grande",Lucida,Arial,Helvetica,sans-serif;
color:#333;
margin:1em 0;
}
如果在使用时，有个别元素需要定义独立样式，你可以再加上新的定义，可以覆盖老的定义，例如：
h1 { font-size:2em; }
h2 { font-size:1.6em; }
重用、子选择器和组选择器的灵活使用可以非常有效的减少代码，同时非常有利的增加代码的可读性，具体的应用需要在具体编写过程中体会。

为h2改进代码如下：

				h2 {
				font-size: 1.5em;
				
						background-color: #ccc;
				
				
						margin: 1em;
				
				
						padding: 3em;
				
				}
		

你可以看到二级标题外围有一个字符的宽度，还很臃肿，因为在二级标题内部有3个字符宽度的补白。

元素的四边可以设置不同的值。margin-top、 margin-right、margin-bottom、 margin-left、padding-top、padding-right、padding-bottom和padding-left是无需解释的属性（看看英文字面意思啦）。

盒状模型

边界、补白和边框（见下一页）是人尽皆知的盒状模型的组成所有部分。盒状模型是这样工作的：中间是元素盒子（在脑海中想像一下情形），从里到外依次包围着补白盒子、边框盒子和边界盒子。很显然地，如下所示：