https://ygwa.github.io/tags/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/Recent content in 性能优化 on 蒋大培的博客HugoenFri, 13 Dec 2024 09:46:34 +0000https://ygwa.github.io/writings/performance-in-prepared-sql/Fri, 13 Dec 2024 09:46:34 +0000https://ygwa.github.io/writings/performance-in-prepared-sql/<p>众所周知，预编译技术对于 SQL 查询具有显著的性能提升作用。具体而言，在执行 SQL 操作时，利用预编译技术可以省略编译步骤，仅需传递特定参数即可借助已准备好的执行计划快速完成查询，从而极大地提升了后端系统的查询效率。</p> <p>然而，预编译技术并非总是适用且无懈可击的。在实际应用中，可能会遇到一些问题和挑战。例如，在某个场景下，当系统需要处理超过1亿条记录的数据量时，即使采用了预编译技术，查询速度仍然会变得缓慢甚至导致超时现象的发生。尽管从接口层面进行了充分的优化，并建立了相应的索引以加速查询过程，但在实际运行环境中，由于数据规模的巨大差异，这些措施可能无法完全解决问题。</p>https://ygwa.github.io/writings/spring-boot-docker-layer/Tue, 03 Dec 2024 15:49:51 +0800https://ygwa.github.io/writings/spring-boot-docker-layer/<p>在实际项目中，我们偶尔会遇到由于客户部署环境的网络限制问题，导致 Docker 镜像的推送与拉取速度很慢，影响部署的效率。 最近接手的一个项目中，我就遇到了类似的情况，我们在客户的内网部署了 Docker 的私有仓库，Jenkins 打包完后需要推送到 Docker 仓库中。 由于客户基于安全要求对于内部网络之间的传输做了网速的限制，通过传统的 Spring Boot 的 FatJar 生成的 Docker 镜像过大，在每次推送镜像和拉取镜像都需要花不少时间。 我们在私有仓库部署的服务较多，对私有仓库的存储容量要求较高。</p>