工作总结.txt

1.删除语句尽量添加limit字段，一般都是放在定时任务的清理语句中，有时候可能会保留一周的数据，需要从大批量的数据中删除大量的数据
 一旦某次执行失败，比如执行时间过长，那么后续所有的执行都必然是失败的

优化的方式：对于删除条件，先查询出主键，再分批次利用主键来删除

2.长事务的处理
  热点的事务流程非常长，尤其是更新一些字段时，事务长时间占据链接，会导致其他查询无法获取到SQL链接（getConnectionTimeout），导致大量报错
	高并发下容易出现（消费dmq）
 
优化的方式：尽量优化处理逻辑，减少耗时；减小事务长度，比如一般处理的前大部分都是查询操作，这些操作就没必要放到事务里，仅在最后更新多张表的时候聚集在一个事物里

3.内存溢出 outOfMemory
	就是代码里存在大量对象创建

优化方式：优化代码，不要频繁的创建大对象

4.热搜榜数据过多
 展控是一个不断循环的流程，非常耗时。

优化：以前是全表处理，实际上热搜大家基本只会关注前面的，所以后面的可以忽略（只查前1000，可配）
 		后面的本身没人关注，但是还需要处理，浪费时间，平白占用。而且这个流程一般都是一些更新流程的一部分，更加剧了耗时

5.图片方法的问题 jdk自带的问题

6.项目对慢查询的监控
 mybatis自带的切面工具类，实现它，并定义超过10s的就是慢查询，记录到db.log中，后续不断分析（起止时间？）

7.慢SQL优化的妥协 举例：
  比如热点表，数据量较大（一万条热点，但是还关联了文章表），查询条件很多，涉及大量的模糊查询，还有很多需要调用下游的模糊查询字段，SQL将近400行，很长
	1.对于需要作为查询条件的下游字段，虽然他们也支持查询，但是查询耗时有可能被下游微服务拖累，考虑到这些字段很多都不会任意变动，且后台有对应的更新逻辑去及时修改这些字段，
  所以直接将这些要用的字段存在自己的表中
	2.一些更新操作完成以后不再更新列表页面，而是由运营手动去点击（很多时候修改一个热点并不需要去影响运营对其他热点的操作）。后台做强校验确保数据一致
	3.添加多个索引

单例 原型 观察者 责任链 代理 工厂 创建者