小程序流量主骗局网络优化工程师有前途吗

一个项目通常在初期阶段很难发现效率问题，往往使用一段时间数据渐大后就回暴露很多这钟问题，通常大型应用项目的效率瓶颈一般都是在数据库

总结几点数据库效率优化方面应该注意的问题

1、 避免使用Hibernate框架
      用Hibernate一次性进行5万条左右数据的插入，若ID使用sequence方式生成，Hibernate将分5万次从数据库取得5万个 sequence，构造成相应对象后，再分五万次将数据保存到数据库。花了我十分钟时间。主要的时间不是花在插入上，而是花在5万次从数据库取 sequence上，弄得我相当郁闷。虽然后来把ID生成方式改成increase解决了问题，但还是对那十分钟的等待心有余悸。 

2、查询时不要使用类似select * from x_table的语句，要尽量使用select id,name from x_table，以避免查询出不需要的数据浪费资源。对于海量数据而言，一个字段所占用的资源和查询时间是相当可观的。

3、当我们在做查询时，常常是前台提交一个查询表单到后台，后台解析这个表单，而后进行查询操作。在我们解析表单时，为了方便起见，常常喜欢将一些不需要查询的条件用永真的条件来代替（如：select count(id) from x_table where name like ‘%’），其实这样的SQL对资源的浪费是相当可怕的。我试过对于同样的近一千万条记录的查询来说，使用select count(id) from x_table 进行表查询需要11秒，而使用select count(id) from x_table where name like ‘%’却花了33秒。
 
4、在做海量数据查询时，应尽量避免表连接（特别是左、右连接），万不得已要进行表连接时，被连接的另一张表数据量一定不能太大，若连接的另一张表也是数万条的话，那估计可以考虑重新设计库表了，因为那需要等待的时间决不是正常用户所能忍受的。可以使用视图、存储过程处理。
 

5、怎样造Java对象。有句话说得好：尽可能的少造对象。别说千万级，就是上万级都不要考虑造对象了。因为几个请求一并发，喀嚓，系统肯定完蛋。

6、合理摆正系统设计的位置。大量数据操作，和少量数据操作一定是分开的。大量的数据操作，肯定不是ORM框架搞定的。绝对不能ORM，因为1，要少造对象；2，数据库资源合理利用。id分配就是一个好例子。

7、合理利用数据库的分区、索引技术，有的时候可以考虑临时表之类的，尤其是大数据量。

8、控制好内存，让数据流起来，不是全部读到内存再处理，而是边读取边处理；合理利用内存，有的数据要缓存；