【实习记录】第10周 2023.08.28-2023.09.01-CSDN博客

本文链接：https://blog.csdn.net/weixin_45580041/article/details/132756328

实习记录：

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标签不一致

Invalid bound statement (not found)出现原因和解决方法_n: invalid bound statement (not found): com.dzqc.m_200.OK的博客-CSDN博客

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. 准备开题