mysql中时间字段设置成bigint类型

1、我们经常会给mysql中时间字段设置成bigint类型，java存入的时候就直接new Date().getTime()存入，这样我们直接查询sql语句的时候那个bigint类型的时间就无法查看。

   SELECT id,

   FROM_UNIXTIME(time/1000),--2015-09-06 16:51:09.3560

   FROM_UNIXTIME(time/1000, '%Y%m%d'),--20150906

   FROM_UNIXTIME(time/1000,  '%Y年%m月%d') --2015年09月06

   FROM aaa_test_table;

2、intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。

   spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3 mvc就容易实现restful url。

   struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。

   spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，

   而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。

3、使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

   一、设计模式的分类

   总体来说设计模式分为三大类：

   创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

   结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

   行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

   其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下：

4、Oracle SQL性能优化

   （1）选择最有效率的表名顺序(只在基于规则的优化器中有效)：

    ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.

   （2）WHERE子句中的连接顺序．：

    ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾.

   （3）SELECT子句中避免使用 ‘ * ‘：

    ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间

   （11）用Where子句替换HAVING子句：

    避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销. 

    (非oracle中)on、where、having这三个都可以加条件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，where也应该比having快点的，因为它过滤数据后才进行sum，在两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们的结果是一样的，只是where可以使用rushmore技术，而having就不能，在速度上后者要慢如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不确定的，根据上篇写的工作流程，where的作用时间是在计算之前就完成的，而having就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。在多表联接查询时，on比where更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由where进行过滤，然后再计算，计算完后再由having进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里

   （14） 使用表的别名(Alias)：

    当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column上.这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误.

   （15） 用EXISTS替代IN、用NOT EXISTS替代NOT IN：

    在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联接.在这种情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率. 在子查询中,NOT IN子句将执行一个内部的排序和合并. 无论在哪种情况下,NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用NOT IN ,我们可以把它改写成外连接(Outer Joins)或NOT EXISTS.

   （19） sql语句用大写的；因为oracle总是先解析sql语句，把小写的字母转换成大写的再执行

   （21） 避免在索引列上使用NOT 通常，　

    我们要避免在索引列上使用NOT, NOT会产生在和在索引列上使用函数相同的影响. 当ORACLE”遇到”NOT,他就会停止使用索引转而执行全表扫描.

   （22） 避免在索引列上使用计算．

    WHERE子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．

   （23） 用>=替代>

    高效:  SELECT * FROM  EMP  WHERE  DEPTNO >=4 

    低效:  SELECT * FROM EMP WHERE DEPTNO >3 

    两者的区别在于, 前者DBMS将直接跳到第一个DEPT等于4的记录而后者将首先定位到DEPTNO=3的记录并且向前扫描到第一个DEPT大于3的记录.

   （24）用UNION替换OR (适用于索引列)

    通常情况下, 用UNION替换WHERE子句中的OR将会起到较好的效果. 对索引列使用OR将造成全表扫描. 注意, 以上规则只针对多个索引列有效. 如果有column没有被索引, 查询效率可能会因为你没有选择OR而降低. 在下面的例子中, LOC_ID 和REGION上都建有索引. 

   （26）避免在索引列上使用IS NULL和IS NOT NULL

   （27）总是使用索引的第一个列：

    如果索引是建立在多个列上, 只有在它的第一个列(leading column)被where子句引用时,优化器才会选择使用该索引. 这也是一条简单而重要的规则，当仅引用索引的第二个列时,优化器使用了全表扫描而忽略了索引

   （28）用UNION-ALL 替换UNION ( 如果有可能的话)：

   （29）用WHERE替代ORDER BY：

    ORDER BY 子句只在两种严格的条件下使用索引. 

    ORDER BY中所有的列必须包含在相同的索引中并保持在索引中的排列顺序. 

    ORDER BY中所有的列必须定义为非空. 

   （30）避免改变索引列的类型.:

    当比较不同数据类型的数据时, ORACLE自动对列进行简单的类型转换. 

    假设 EMPNO是一个数值类型的索引列. 

    SELECT …  FROM EMP  WHERE  EMPNO = ‘123' 

    实际上,经过ORACLE类型转换, 语句转化为: 

    SELECT …  FROM EMP  WHERE  EMPNO = TO_NUMBER(‘123') 

    幸运的是,类型转换没有发生在索引列上,索引的用途没有被改变. 

    现在,假设EMP_TYPE是一个字符类型的索引列. 

    SELECT …  FROM EMP  WHERE EMP_TYPE = 123 

    这个语句被ORACLE转换为: 

    SELECT …  FROM EMP  WHERETO_NUMBER(EMP_TYPE)=123 

    因为内部发生的类型转换, 这个索引将不会被用到! 为了避免ORACLE对你的SQL进行隐式的类型转换, 最好把类型转换用显式表现出来.

   （31）需要当心的WHERE子句:

    某些SELECT 语句中的WHERE子句不使用索引. 这里有一些例子. 在下面的例子里, 

    (1)‘!=' 将不使用索引. 记住, 索引只能告诉你什么存在于表中, 而不能告诉你什么不存在于表中. 

    (2) ‘||'是字符连接函数. 就象其他函数那样, 停用了索引. 

    (3) ‘+'是数学函数. 就象其他数学函数那样, 停用了索引. 

    (4)相同的索引列不能互相比较,这将会启用全表扫描.

   （32）a. 如果检索数据量超过30%的表中记录数.使用索引将没有显著的效率提高. 

    b. 在特定情况下, 使用索引也许会比全表扫描慢, 但这是同一个数量级上的区别. 而通常情况下,使用索引比全表扫描要块几倍乃至几千倍!

   （33）避免使用耗费资源的操作:

    带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 

    执行耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序. 通常, 带有UNION, MINUS , INTERSECT的SQL语句都可以用其他方式重写. 如果你的数据库的SORT_AREA_SIZE调配得好, 使用UNION , MINUS, INTERSECT也是可以考虑的, 毕竟它们的可读性很强

   （34）优化GROUP BY:

    提高GROUP BY 语句的效率, 可以通过将不需要的记录在GROUP BY 之前过滤掉.下面两个查询返回相同结果但第二个明显就快了许多.

    低效:  SELECT JOB , AVG(SAL)  FROM EMP  GROUP JOB  HAVING JOB = ‘PRESIDENT'  OR JOB = ‘MANAGER' 

    高效:  SELECT JOB , AVG(SAL)  FROM EMP  WHERE JOB = ‘PRESIDENT'  OR JOB = ‘MANAGER'  GROUP JOB

5、ORACLE百万记录SQL语句优化技巧

   1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

   2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

   select id from t where num is null

   可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

   select id from t where num=0

   3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

   4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

   5.in 和 not in 也要慎用，否则会导致全表扫描，如：

   select id from t where num in(1,2,3)

   对于连续的数值，能用 between 就不要用 in 了：

   select id from t where num between 1 and 3

   6.下面的查询也将导致全表扫描：

   select id from t where name like '%abc%'

   若要提高效率，可以考虑全文检索。

   like 'xxx%'这样写要用索引，而这样写like '%xxx'或'%xxx%'写不用索引。

   7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

   select id from t where num=@num

   可以改为强制查询使用索引：

   select id from t with(index(索引名)) where num=@num

   8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

   select id from t where num/2=100 应改为: select id from t where num=100*2

   9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

   select id from t where substring(name,1,3)='abc' // oracle总有的是substr函数。

   select id from t where datediff(day,createdate,'2005-11-30')=0 //查过了确实没有datediff函数。

   应改为:

   select id from t where name like 'abc%'

   select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' // 

   oracle 中时间应该把char 转换成 date 如： createdate >= to_date('2005-11-30','yyyy-mm-dd')

   10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

   11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

   12.不要写一些没有意义的查询，如需要生成一个空表结构：

   select col1,col2 into #t from t where 1=0

   这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：

   create table #t(...)

   13.很多时候用 exists 代替 in 是一个好的选择：

   select num from a where num in(select num from b)

   用下面的语句替换：

   select num from a where exists(select 1 from b where num=a.num)

   14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。

   15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

   16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。

      聚簇索引(Clustered Index)和非聚簇索引 (Non- Clustered Index)

   17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

   

   18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

      Unicode字符集就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。

      varchar(n)

      长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节。

      nvarchar(n)

      包含 n 个字符的可变长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍。

      两字段分别有字段值：我和coffee

      那么varchar字段占2×2+6=10个字节的存储空间，而nvarchar字段占8×2=16个字节的存储空间。 如字段值只是英文可选择varchar，而字段值存在较多的双字节（中文、韩文等）字符时用nvarchar

      1、CHAR。CHAR存储定长数据很方便，CHAR字段上的索引效率级高，比如定义char(10)，那么不论你存储的数据是否达到了10个字节，都要占去10个字节的空间,不足的自动用空格填充，所以在读取的时候可能要多次用到trim（）。

      2、VARCHAR。存储变长数据，但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个字符，把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢？这一个字节用于保存实际使用了多大的长度。从空间上考虑，用varchar合适；从效率上考虑，用char合适，关键是根据实际情况找到权衡点。

   19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

   20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

   21.避免频繁创建和删除临时表，以减少系统表资源的消耗。

   22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

   23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

   24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。

   25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。

   26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。

   27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。

   28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

   29.尽量避免大事务操作，提高系统并发能力。

   30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。