实习记录:
1. 后端服务发版:
1)lib包maven-clean、install
2)app-chain-runner包clean、install
3)sftp把生成的jar包传输到服务器上(连接服务器用22端口)(改名为app.jar,保留之前的),倘若Apollo中配置有更改,则重新替换服务器中的application-chain.properties
4)xshell连接 22端口 cd /home /docker_mount /app-chain-svc
docker ps查看各个部署的服务信息,docker restart app-chain-svc重新发版
docker logs -f --tail 200 app-chain-svc 查看chain服务的日志
2. Invalid bound statement (not found)出现原因和解决方法
1)mapper.xml文件中的namespace和实际的mapper文件不一致
2)mapper接口中的方法名和mapper.xml中的id标签不一致
3. 运行报错 找不到实体类 的原因(仅限于本项目中遇到的bug):
app-chain-svc引用了lib下mapper.marketing包中的xml(以及namespace指定的Mapper和返回结果实体类),因为app-chain-svc的pom中引用了lib包下的内容,数据源配置时@MapperScan和mybatisPath也扫到了lib的包(为了能使用lib中的bean),所以在lib中的Mapper和实体类可以被app-chain-svc检测到,不会编译报错。而Mapper或者实体类放到app-marketing-svc服务下时,app-chain-svc扫描不到marketing服务下的文件,所以会编译报错。
4. 索引的缺点
索引是保证 MySQL 良好性能的关键措施,但是索引不是万能的。我们要清楚索引事实上就是一张表(一种特殊类型的表,但也是表)。因此,虽然增加索引后大大提高了查询速度,但是每次对表中数据如对表进行INSERT、UPDATE和DELETE 操作时,表中所有索引必须修改。所以,索引越多,服务器就需要做越多的工作来保持所有数据最新,显而易见,这将会拖慢服务器处理任务的速度。
尤其是当表中的数据量越来越大时,索引对性能的影响愈发重要。在数据量较小且负载较低时,不恰当的索引对性能的影响可能还不明显,但当数据量逐渐增大时,性能则会急剧下降。如果对多列进行索引(组合索引),列的顺序非常重要,MySQL仅能对索引最左边的前缀进行有效的查找。
而且索引也是占有磁盘空间的。因此仅当出现清晰需求的时候才需要添加索引。
5. sql查询优化:
硬件层:cpu,memory,io等等
系统层:linux层 :io,磁盘分区,swap交换空间等等
应用层:doris配置参数优化:并发,广播,大小表关联,线程相关,每个sql申请资源
Doris语句优化:过滤不要数据,distinct groupby代替,where过滤
避免数据倾斜,join字段过于集中,rank值
日报:
2023.08.28:
1. 产业链标签和优质企业接口速度很慢(sql查询慢,表里数据过多,10亿+、6000万+,300万+),优化方案是什么?优化不了该如何解决(优化sql和建新表存储计算结果(这一步应该是用大数据处理推到mysql表中))
2. 总结找不到xml对应的实体类这个bug的原因
3. 与前端进行接口对接
4. 发版:
1)lib包maven-clean、install
2)app-chain-runner包clean、install
3)sftp把生成的jar包传输到服务器上(连接服务器用22端口)(改名为app.jar,保留之前的)
4)xshell连接 22端口 cd /home /docker_mount /app-chain-svc
docker ps查看各个部署的服务信息,docker restart app-chain-svc重新发版
docker logs -f --tail 200 app-chain-svc 查看chain服务的日志
2023.08.29:
1. 开早会,生态图谱项目延期至9月15日
2. 询问组长产业链标签和优质企业两个接口查询慢的问题
3. 整理面试八股总结
2023.08.30:
1. 两个接口sql优化:建索引;有了新表(company_high_quality),但还是很慢;主要是从s_chain_relation根据chain_id查company_id,及时在chain_id上建了索引也用处不大,因为chain_id就两个值(11259和11260)(而根据company_id查chain_id是很快的,因为company_id的值差别较大(区分度高),建索引效果优于chain_id)
2. 面试八股总结
3. 总结大表关联查询的优化方法(使用INNER JOIN, 合理使用索引, 数据分表 等);doris的SET enable_nereids_planner = true; jdbc连接加上allowMultiQueries=true属性,就可以在mybatis里写多条sql.
4. 优化 优质企业列表 接口
2023.08.31:
1. 整理面试八股总结
2. 索引失效的情景,尤其注意or的情况,网上查到的说法不一,自己经过尝试并完成了总结。
3. 大表关联查询优化问题
4. 分库分表,垂直分库分表,水平分库分表
5. 整理图谱项目遇到的难点:大表联查速度很慢(新建结果表并定时更新数据,优化sql语句,根据chain_id分表,使用doris最新的nereids优化器)
2023.09.01:
1. 调休
2. 准备开题
最近一直在看八股,感觉不整理的话会过几天就忘,而且回顾起来不方便,所以打算总计一份面试八股,待完善之后也会分享出来。