我个人面试时遇到的一些面试题，哭晕在厕所，前车之鉴，后事之师。现在分享出来，希望能给大家面试提供帮助！
1、写出增、删 、改、查的sql语句？
查询
select id,name from person;
删除
delete from person where id=1;
修改
update person set name ="菲菲" where id=2;
新增
insert into person values (4,"美美")；
2、orcal sql语句分页
Oracle：
考虑mySql中的实现分页，select * from 表名 limit 开始记录数,显示多少条;就可以实现我们的分页效果。
但是在oracle中没有limit关键字，但是有 rownum字段
rownum是一个伪列，是oracle系统自动为查询返回结果的每行分配的编号，第一行为1，第二行为2，以此类推。。。。
第一种：
SELECT * FROM
(
SELECT A.*, ROWNUM RN
FROM (SELECT * FROM TABLE_NAME) A
WHERE ROWNUM <= 40
)
WHERE RN >= 21
其中最内层的查询SELECT * FROM TABLE_NAME表示不进行翻页的原始查询语句。ROWNUM <= 40和RN >= 21控制分页查询的每页的范围。
上面给出的这个分页查询语句，在大多数情况拥有较高的效率。分页的目的就是控制输出结果集大小，将结果尽快的返回。在上面的分页查询语句中，这种考虑主要体现在WHERE ROWNUM <= 40这句上。
选择第21到40条记录存在两种方法，一种是上面例子中展示的在查询的第二层通过ROWNUM <= 40来控制最大值，在查询的最外层控制最小值。而另一种方式是去掉查询第二层的WHERE ROWNUM <= 40语句，在查询的最外层控制分页的最小值和最大值。
第二种：
select * from (select e.*,rownum r from (select * from emp order by sal desc) e ) e1 where e1.r>21 and e1.r<=40;
3、mysql sql 语句分页
MySQL数据库实现分页比较简单，提供了 LIMIT函数。一般只需要直接写到sql语句后面就行了。
LIMIT子 句可以用来限制由SELECT语句返回过来的数据数量，它有一个或两个参数，如果给出两个参数， 第一个参数指定返回的第一行在所有数据中的位置，从0开始（注意不是1），第二个参数指定最多返回行数。例如：
select * from table WHERE … LIMIT 10; #返回前10行
select * from table WHERE … LIMIT 0,10; #返回前10行
select * from table WHERE … LIMIT 10,20; #返回第10-20行数据
4、sqlserver sql语句分页
分页方案一：(利用Not In和SELECT TOP分页)
SELECT TOP 10 *
FROM TestTable
WHERE (ID NOT IN
(SELECT TOP 20 id
FROM TestTable
ORDER BY id))
ORDER BY ID
SELECT TOP 页大小 *
FROM TestTable
WHERE (ID NOT IN
(SELECT TOP 页大小*页数 id
FROM 表
ORDER BY id))
ORDER BY ID
5、struct2 执行过程
1 客户端发送请求；
2 这个请求经过一系列的过滤器（Filter）（这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器，这个过滤器对于Struts2和其他框架的集成很有帮助，例如：SiteMesh Plugin）
3 接着FilterDispatcher被调用，FilterDispatcher询问ActionMapper来决定这个请是否需要调用某个Action。FilterDispatcher的功能如下：
(1)执行Actions
(2)清除ActionContext
(3)维护静态内容
(4)清除request生命周期内的XWork的interceptors
4 如果ActionMapper决定需要调用某个Action，FilterDispatcher把请求的处理交给ActionProxy
5 ActionProxy通过Configuration Manager询问框架的配置文件，找到需要调用的Action类
6 ActionProxy创建一个ActionInvocation的实例。
7 ActionInvocation实例使用命名模式来调用，在调用Action的过程前后，涉及到相关拦截器（Intercepter）的调用。
8 一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是（但不总是，也可 能是另外的一个Action链）一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper
6、hibernate 优缺点
. Hibernate优点
(1) 对象/关系数据库映射(ORM)
它使用时只需要操纵对象，使开发更对象化，抛弃了数据库中心的思想，完全的面向对象思想
(2) 透明持久化(persistent)
带有持久化状态的、具有业务功能的单线程对象，此对象生存期很短。这些对象可能是普通的JavaBeans/POJO，这个对象没有实现第三方框架或者接口，唯一特殊的是他们正与（仅仅一个）Session相关联。一旦这个Session被关闭，这些对象就会脱离持久化状态，这样就可被应用程序的任何层自由使用。（例如，用作跟表示层打交道的数据传输对象。）
(3) 事务Transaction(org.hibernate.Transaction)
应用程序用来指定原子操作单元范围的对象，它是单线程的，生命周期很短。它通过抽象将应用从底层具体的JDBC、JTA以及CORBA事务隔离开。某些情况下，一个Session之内可能包含多个Transaction对象。尽管是否使用该对象是可选的，但无论是使用底层的API还是使用Transaction对象，事务边界的开启与关闭是必不可少的。
(4) 它没有侵入性，即所谓的轻量级框架
(5) 移植性会很好
(6) 缓存机制，提供一级缓存和二级缓存
(7) 简洁的HQL编程
2. Hibernate缺点
(1) Hibernate在批量数据处理时有弱势
(2) 针对单一对象简单的增删查改，适合于Hibernate,而对于批量的修改，删除，不适合用Hibernate,这也是OR框架的弱点；要使用数据库的特定优化机制的时候，不适合用Hibernate
7.spring3和spring4有什么区别？撸主没有回答出来！哭晕在厕所。。。
8.注解和xml对比？
我的理解：
注解：是一种分散式的元数据，与源代码紧绑定。
xml：是一种集中式的元数据，与源代码无绑定。
因此注解和XML的选择上可以从两个角度来看：分散还是集中，源代码绑定/无绑定。
注解的缺点：
1、很多朋友比如在使用spring注解时，会发现注解分散到很多类中，不好管理和维护；这个其实要借助工具，我目前使用的是IDEA，它在这方面表现的非常好；当然现在还有Spring的STS，也是不错的； 所以借助工具，能解决这个问题；
2、注解的开启/关闭必须修改源代码，因为注解是源代码绑定的，如果要修改，需要改源码，这个有这个问题，所以如果是这种情况，还是使用XML配置方式；比如数据源；
3、注解还一个缺点就是灵活性，比如在之前翻译的Spring Framework 4.0 M1: WebSocket 支持；在实现复杂的逻辑上，没有XML来的更加强大；注解就是要么用，要么不用，比如之前的jpa bean validation，要么全，要么没；遇到这种情况很痛苦；
4、还一种就是约定大于配置，但是在处理一些复杂的情况下，注解还是需要的（如Spring的数据验证/数据绑定注解很强大）；
5、通用配置还是走XML吧，比如事务配置，比如数据库连接池等等，即通用的配置集中化，而不是分散化，如很多人使用@Transactional来配置事务，在很多情况下这是一种太分散化的配置；
6、XML方式比注解的可扩展性和复杂性维护上好的多，比如需要哪些组件，不需要哪些；在面对这种情况，注解扫描机制比较逊色，因为规则很难去写或根本不可能写出来；
注解的好处：
1、XML配置起来有时候冗长，此时注解可能是更好的选择，如jpa的实体映射；注解在处理一些不变的元数据时有时候比XML方便的多，比如springmvc的数据绑定，如果用xml写的代码会多的多；
2、注解最大的好处就是简化了XML配置；其实大部分注解一定确定后很少会改变，所以在一些中小项目中使用注解反而提供了开发效率，所以没必要一头走到黑；
3、注解相对于XML的另一个好处是类型安全的，XML只能在运行期才能发现问题。
注解也好，XML也好，我们还是需要一些开关/替换机制来控制特殊需求，以改变那种要么全部 要么没有的方案。。
还一种呼声就是约定大于配置，这种方案可能在某些场景下是最优的，但是遇到一些复杂的情况可能并不能解决问题，所以此时注解也是一个不错的方案。尤其在使用springmvc时，好处是能体会的出的。
不管使用注解还是XML，做的事情还是那些事情，但注解和XML都不是万能的，满足自己的需求且已一种更简单的方式解决掉问题即可。
就像探讨一下技术问题，很多人都带有很强的个人喜好来评判一个东西的好坏，这种探讨没有任何意义，我们最终的目的是解决方案，所以我们应该探讨的是能不能解决问题，能不能以更容易理解的方式解决问题，能不能更简单的解决问题。
不管是约定大于配置、注解还是XML配置也好，没有哪个是最优的，在合适的场景选择合适的解决方案这才是重要的。就像设计模式一样：是对特定环境中重复出现的特定问题的一个经过前人验证了的解决方案。
8.你觉得你以前参与开发的项目 业务处理最复杂的地方是哪里？
9.你觉得你以前参与开发的项目 技能现实最难的地方是哪里？
10.你对自己未来的规划是怎样的？ |
|
收藏
淘帖
踩
没人看啊
