前言

之前搞得语音识别突然发现浏览器就有接口可以直接用，而且识别又快又准，参考：使用 JavaScript 的 SpeechRecognition API 实现语音识别_speechrecognition js-CSDN博客

进入正题

这个功能首先要感谢一下作者常康，仓库地址(gitee.com/agriculture… 这个项目很早之前就关注了，最近这段时间正好要用才真正实践了一下，只是初步测试了一下，在性能方面还需要进一步测试，本人电脑就很拉识别就很卡。

先看效果

改动

主要对姿态识别做了一些小改动，将原图片识别改成视频视频识别，如果要调用摄像头将video.open(0);的代码注释放开即可

package cn.ck;



import ai.onnxruntime.OnnxTensor;

import ai.onnxruntime.OrtEnvironment;

import ai.onnxruntime.OrtException;

import ai.onnxruntime.OrtSession;

import cn.ck.config.PEConfig;

import cn.ck.domain.KeyPoint;

import cn.ck.domain.PEResult;

import cn.ck.utils.Letterbox;

import nu.pattern.OpenCV;

import org.opencv.core.Mat;

import org.opencv.core.Point;

import org.opencv.core.Scalar;

import org.opencv.core.Size;

import org.opencv.highgui.HighGui;

import org.opencv.imgproc.Imgproc;

import org.opencv.videoio.VideoCapture;

import org.opencv.videoio.Videoio;



import java.nio.FloatBuffer;

import java.util.ArrayList;

import java.util.Collections;

import java.util.List;



/*

 *  姿态识别，可以识别动作等等.,比如跳绳技术

 */

public class PoseEstimation {



    static {

        // 加载opencv动态库

        //System.load(ClassLoader.getSystemResource("lib/opencv_java470-无用.dll").getPath());

        OpenCV.loadLocally();

    }



    public static void main(String[] args) throws OrtException {



        String model_path = "src\main\resources\model\yolov7-w6-pose-nms.onnx";

        // 加载ONNX模型

        OrtEnvironment environment = OrtEnvironment.getEnvironment();

        OrtSession.SessionOptions sessionOptions = new OrtSession.SessionOptions();

        OrtSession session = environment.createSession(model_path, sessionOptions);

        // 输出基本信息

        session.getInputInfo().keySet().forEach(x -> {

            try {

                System.out.println("input name = " + x);

                System.out.println(session.getInputInfo().get(x).getInfo().toString());

            } catch (OrtException e) {

                throw new RuntimeException(e);

            }

        });



        VideoCapture video = new VideoCapture();



//        video.open(0);  //获取电脑上第0个摄像头



        //可以把识别后的视频在通过rtmp转发到其他流媒体服务器，就可以远程预览视频后视频，需要使用ffmpeg将连续图片合成flv 等等，很简单。

        if (!video.isOpened()) {

            System.err.println("打开视频流失败,未检测到监控,请先用vlc软件测试链接是否可以播放！,下面试用默认测试视频进行预览效果！");

            video.open("video/test2.mp4");

        }

        // 跳帧检测，一般设置为3，毫秒内视频画面变化是不大的，快了无意义，反而浪费性能

        int detect_skip = 4;



        // 跳帧计数

        int detect_skip_index = 1;



        // 最新一帧也就是上一帧推理结果

        float[][] outputData   = null;



        //当前最新一帧。上一帧也可以暂存一下

        Mat img = new Mat();





// 在这里先定义下线的粗细、关键的半径(按比例设置大小粗细比较好一些)

        int minDwDh = Math.min((int)video.get(Videoio.CAP_PROP_FRAME_WIDTH), (int)video.get(Videoio.CAP_PROP_FRAME_HEIGHT));

        int thickness = minDwDh / PEConfig.lineThicknessRatio;

        int radius = minDwDh / PEConfig.dotRadiusRatio;

            // 转换颜色空间

            Mat image = new Mat();



            // 图像预处理

            Letterbox letterbox = new Letterbox();

            letterbox.setNewShape(new Size(960, 960));

            letterbox.setStride(64);





// 使用多线程和GPU可以提升帧率，线上项目必须多线程！！！,一个线程拉流，将图像存到[定长]队列或数组或者集合，一个线程模型推理，中间通过变量或者队列交换数据,代码示例仅仅使用单线程

        while (video.read(img)) {

            if ((detect_skip_index % detect_skip == 0) || outputData == null) {

                Imgproc.cvtColor(img, image, Imgproc.COLOR_BGR2RGB);

                image = letterbox.letterbox(image);

                int rows = letterbox.getHeight();

                int cols = letterbox.getWidth();

                int channels = image.channels();

                // 将图像转换为模型输入格式

                float[] pixels = new float[channels * rows * cols];

                for (int i = 0; i < rows; i++) {

                    for (int j = 0; j < cols; j++) {

                        double[] pixel = image.get(j, i);

                        for (int k = 0; k < channels; k++) {

                            pixels[rows * cols * k + j * cols + i] = (float) pixel[k] / 255.0f;

                        }

                    }

                }

                detect_skip_index = 1;

                OnnxTensor tensor = OnnxTensor.createTensor(environment, FloatBuffer.wrap(pixels), new long[]{1L, (long) channels, (long) rows, (long) cols});

                OrtSession.Result output = session.run(Collections.singletonMap(session.getInputInfo().keySet().iterator().next(), tensor));



                // 处理输出结果并绘制

               outputData = ((float[][]) output.get(0).getValue());

            }else{

                detect_skip_index = detect_skip_index + 1;

            }

            double ratio = letterbox.getRatio();

            double dw =letterbox.getDw();

            double dh = letterbox.getDh();

            List<PEResult> peResults = new ArrayList<>();

            for (float[] outputDatum : outputData) {

                PEResult result = new PEResult(outputDatum);

                if (result.getScore() > PEConfig.personScoreThreshold) {

                    peResults.add(result);

                }

            }



            // 对结果进行非极大值抑制

            peResults = nms(peResults, PEConfig.IoUThreshold);



            for (PEResult peResult: peResults) {

                System.out.println(peResult);

                // 画框

                Point topLeft = new Point((peResult.getX0()-dw)/ratio, (peResult.getY0()-dh)/ratio);

                Point bottomRight = new Point((peResult.getX1()-dw)/ratio, (peResult.getY1()-dh)/ratio);

                // Imgproc.rectangle(img, topLeft, bottomRight, new Scalar(255,0,0), thickness);

                List<KeyPoint> keyPoints = peResult.getKeyPointList();

                // 画点

                keyPoints.forEach(keyPoint->{

                    if (keyPoint.getScore()>PEConfig.keyPointScoreThreshold) {

                        Point center = new Point((keyPoint.getX()-dw)/ratio, (keyPoint.getY()-dh)/ratio);

                        Scalar color = PEConfig.poseKptColor.get(keyPoint.getId());

                        Imgproc.circle(img, center, radius, color, -1); //-1表示实心

                    }

                });

                // 画线

                for (int i = 0; i< PEConfig.skeleton.length; i++){

                    int indexPoint1 = PEConfig.skeleton[i][0]-1;

                    int indexPoint2 = PEConfig.skeleton[i][1]-1;

                    if ( keyPoints.get(indexPoint1).getScore()>PEConfig.keyPointScoreThreshold &&

                            keyPoints.get(indexPoint2).getScore()>PEConfig.keyPointScoreThreshold ) {

                        Scalar coler = PEConfig.poseLimbColor.get(i);

                        Point point1 = new Point(

                                (keyPoints.get(indexPoint1).getX()-dw)/ratio,

                                (keyPoints.get(indexPoint1).getY()-dh)/ratio

                        );

                        Point point2 = new Point(

                                (keyPoints.get(indexPoint2).getX()-dw)/ratio,

                                (keyPoints.get(indexPoint2).getY()-dh)/ratio

                        );

                        Imgproc.line(img, point1, point2, coler, thickness);

                    }

                }

            }

            //服务器部署：由于服务器没有桌面，所以无法弹出画面预览，主要注释一下代码

            HighGui.imshow("result", img);



            // 多次按任意按键关闭弹窗画面，结束程序

            if(HighGui.waitKey(1) != -1){

                break;

            }

        }



        HighGui.destroyAllWindows();

        video.release();

        System.exit(0);



    }



    public static List<PEResult> nms(List<PEResult> boxes, float iouThreshold) {

        // 根据score从大到小对List进行排序

        boxes.sort((b1, b2) -> Float.compare(b2.getScore(), b1.getScore()));

        List<PEResult> resultList = new ArrayList<>();

        for (int i = 0; i < boxes.size(); i++) {

            PEResult box = boxes.get(i);

            boolean keep = true;

            // 从i+1开始，遍历之后的所有boxes，移除与box的IOU大于阈值的元素

            for (int j = i + 1; j < boxes.size(); j++) {

                PEResult otherBox = boxes.get(j);

                float iou = getIntersectionOverUnion(box, otherBox);

                if (iou > iouThreshold) {

                    keep = false;

                    break;

                }

            }

            if (keep) {

                resultList.add(box);

            }

        }

        return resultList;

    }

    private static float getIntersectionOverUnion(PEResult box1, PEResult box2) {

        float x1 = Math.max(box1.getX0(), box2.getX0());

        float y1 = Math.max(box1.getY0(), box2.getY0());

        float x2 = Math.min(box1.getX1(), box2.getX1());

        float y2 = Math.min(box1.getY1(), box2.getY1());

        float intersectionArea = Math.max(0, x2 - x1) * Math.max(0, y2 - y1);

        float box1Area = (box1.getX1() - box1.getX0()) * (box1.getY1() - box1.getY0());

        float box2Area = (box2.getX1() - box2.getX0()) * (box2.getY1() - box2.getY0());

        float unionArea = box1Area + box2Area - intersectionArea;

        return intersectionArea / unionArea;

    }

}

姿态识别模型提取链接，
通过网盘分享的文件：yolov7-w6-pose-nms.onnx
链接: pan.baidu.com/s/1UdAUPWr1… 提取码: du6y

后言

就像原作者说的，不是每个同学都会python,不是每个项目都是python语言开发，不是每个岗位都会深度学习。

希望java在AI领域能有更好的发展

从 13 年实习开始，开发环境从 Ubuntu 转战 MacOS，中间换了好几次电脑，每次都是直接用 Mac 自带的 Time Machine 来迁移数据，仅需一块移动硬盘或者一根 type c 线，经过一个晚上的数据迁移，第二天就可以用新电脑工作了，除了配置升级了，几乎感受不到换电脑的乐趣，并且升级过程中，也积累了不少系统升级的旧疾，这次从Intel芯片到 M3 Max 芯片，我打算从零开始，重新蒸腾一番，顺带更新一下工具库，说干就干，Go！
先介绍下新电脑的配置

• 太空黑：从经典的银色、到太空灰，这次体验一下太空黑


• 14 寸：用了大概 3 年的 14 寸，就一直用 15/16寸，因为这台不是用于办公，考虑携带方便，所以入手 14 寸（大屏幕肯定爽，但是在家主要也是外接显示器）

• M3 Max：想要体验一下本地大模型，直接入手 Max（找个借口🤐）


• 64G 内存：一直有在 macbook 上装虚拟机（Parallels Desktop）运行 Windows的习惯，升级了一下内存


• 2TB SSD：以前 512 的时候，由于各种 npm 包、docker 镜像，还是隔一段时间就要重启一下、硬盘清理等方式来释放空间，一步到位

后面还换过几台，从最开始的 touchbar ，蝶式键盘，再到取消 touchbar，这时候更多的是工作工具的更换，连拍照的激情都没有🥱🥱

开发工具

科学上网工具

作为开发，第一件事情是需要一个趁手的科学上网工具，不然类似下载 Google Chrome、安装 Homebrew 等基础的工具都会十分麻烦
我的科学上网工具，支持按照规则配置自动代理，同时也支持终端代理，以下是终端代理，这里不方便推荐具体工具

# 防止终端命令无法确定是否需要科学上网，不建议把这个命令持久化到 bashrc/zshrc,在需要时打开终端输入即可

 export https_proxy=http://127.0.0.1:1235 http_proxy=http://127.0.0.1:1235 all_proxy=socks5://127.0.0.1:1234

Xcode

Xcode 命令行工具，许多开发工具和依赖所需的基础，运行一下命令，选择安装，稍等一会即可

xcode-select --install

Homebrew

通过 homebrew 来管理一些开发工具包，如 git、node等等，由于需要下载 github 地址，这里需要借助你的翻墙工具

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

然后按照提示，把命令加到 PATH

(echo; echo 'eval "$(/opt/homebrew/bin/brew shellenv)"') >> ~/.zprofile

eval "$(/opt/homebrew/bin/brew shellenv)"

Git/Tig

brew install git

# brew install git-gui 

# brew install tig 个人是 vim 用户，偏向这种终端 gui

# 这里会自动安装 zsh 的自动补全工具，后续安装 zsh 可用

# /opt/homebrew/share/zsh/site-functions

安装 git 和 tig 都会默认新增 zsh 的补全方法，好吧，这是提醒我要立马安装 zsh
tigrc 可以用来自定义 tig 的一些配置和快捷键绑定

A sample of the default configuration has been installed to:

  /opt/homebrew/opt/tig/share/tig/examples/tigrc

to override the system-wide default configuration, copy the sample to:

  /opt/homebrew/etc/tigrc



zsh completions and functions have been installed to:

  /opt/homebrew/share/zsh/site-functions

在任意已经初始化 git 的项目，打入 tig ，然后你就可以使用 vim 的方式来操作了 jk 等等

另外，使用 git 我还会额外安装两个 git 相关的小插件
一个是 tj 大神开发的 git-extras

brew install git-extras



# 添加到 ~/.zshrc

source /opt/homebrew/opt/git-extras/share/git-extras/git-extras-completion.zsh

详细的命令可查看文档，我比较常用了是 git summary、git undo、git setup

然后通过git 的 alias 来实现一个自定义的命令，git up 来实现每次切换到一个仓库时，有意思的更新一下最新代码

git config --global alias.up '!git remote update -p && git pull --rebase && git submodule update --init --recursive'

iTerm

实现通过 command + ecs 键，快速切换显示/隐藏 iTerm

• 设置默认终端


• 安装 shell integration

• 选配色：Solarized


• 安装 oh-my-zsh

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

• 修改主题，配置插件等等

brew install zsh-syntax-highlighting

brew install zsh-autosuggestions 

brew install autojump

brew install fzf

#ZSH_THEME="robbyrussell"

#ZSH_THEME="agnoster"

#ZSH_THEME="miloshadzic"

#ZSH_THEME="sunrise"

# ZSH_THEME="ys"

ZSH_THEME="gnzh"



plugins=(git ruby autojump osx rake rails lighthouse sublime)

plugins=(bgnotify)

plugins=(web-search)

plugins=(node)



source /opt/homebrew/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

source /opt/homebrew/share/zsh-autosuggestions/zsh-autosuggestions.zsh

[ -f /opt/homebrew/etc/profile.d/autojump.sh ] && . /opt/homebrew/etc/profile.d/autojump.sh

source <(fzf --zsh)

这就起飞了！看看效果

Docker Desktop

作为开发，docker 技能必不可少，mac 下直接使用 docker desktop，可以省掉很多事情，特别是当你如果需要在本地跑 k8s 环境时，直接勾上 Enable Kubernetes 即可；另外新版本查看镜像，也可以扫描镜像每一层是否有安全漏洞，十分方便

VSCode

vscode 不仅适合前端开发，对于 Go、Rust 等开发者，整体体验都不错。安装后的第一件事，就是把 code 命令加到 Terminal

然后第二件事就是安装 github 的 Copilot 插件，开发、看源码现在是少不了它了

第三件事就是在 vscode 开启 vim 模式（安装 vim 插件)从 vim - sublime - vscode，一直保留 vim 的使用习惯，改不掉了😂
其他的就是各种高亮、开发辅助插件，大家按需安装即可

其他

• 前端
  
  
  
  • NVM：node 版本管理
  
  
  • pnpm：上一台电脑只有 512G，在动不动就几个 G 的前端项目，硬盘一直告警，至此只用 pnpm
  
  
  
  


• Go
  
  
  
  • GVM： go 版本管理
  
  
  • GoLand：虽然 vscode 可以开发 go，但是整体体验还是比不上收费的 goland
  
  
  
  

环境搭建可参考 Go + React 指北

效率工具

ChatGPT

说到效率工具，ChatGPT 绝对是提高效率神器，从日常问题到开发、图片生成、画图等等，哦，还可以帮忙挑西瓜🍉


对了，用了苹果芯片，ChatGPT app 直接通过 option + space 即可随时调出，支持实时对话、支持截屏问问题等等，好用程度大幅上升⬆️⬆️⬆️

Bartender($)

吐血推荐，让你状态栏更加一目了然
支持自定义显示哪些 icon，配置哪些 icon 始终不显示，哪些第二状态栏显示

快捷键切换第二状态栏，一下子清爽颜值高

iStat Menus($)

拥有时刻关注着网速、CPU使用率、内存使用率的强迫症，绝对不少

Yoink

当你要把一个文件从一个地方移到另外一个地方时，当你想快速复制一张图片时，剪切板记录、跨设备文件接力等等，这个小小的工具都能帮助你
有时候通过截屏软件截图，可以一次性把需要的截屏操作完，然后在剪贴板直接拖下来使用，十分方便！

BettersnapTool

一款小而美的工具，用来快速调整你的窗口，比如当前窗口在两个显示屏直接切换；全屏，左右分屏等等

iShot

本来我一直使用 Skitch 的，但是这次切换新电脑之后，发现它下架了，之前有朋友推荐了，也使用了一段时间，感觉很不错，除了普通的截图，还有长截图、带壳截图；还有其他的小工具，官方宣传是
截图、长截图、全屏带壳截图、贴图、标注、取色、录屏、录音、OCR、翻译一个顶十个，样样皆优秀！

Draw.io

好吧，这个绝对画图神器，日常写文档几乎离不开他，在线版直接打开即可使用，也可以安装 vscode 插件，不过我还是习惯下载一个 app，这样本地的文件，直接打开即可使用
距离成为架构师，你只差一个 draw.io

Parallels Desktop

如果你有使用 Windows 的诉求，那么我建议你花点钱买个 pd，融合模式一开，原来我的 16 年的机器，玩个魔兽、英雄联盟完全没问题
安装直接点击下载 Windows 11，网速好的话，10 来分钟就安装成功了

融合模式，应用和直接使用 mac 的应用没任何差别

全屏模式，可以看到截图的时候有一部分黑色，应该是没有兼容刘海屏的原因

Markdown 编辑器

Quiver，原来所有的笔记、文档基本都靠它来记录，21 年的时候作者停止维护了，再加上使用纯 markdown 工具，还需要自己找图床，最后都转到语雀、飞书等在线文档
中间还用过其他的、Mweb、Typora 等等，如果自己搭建图床，推荐使用 Typora

Mweb 包含PC 和 移动端，通过 iCloud 同步，也是十分方便！

图床工具

原来写 markdown 的时候，使用的是微博免费的图床，2 年后，然后发现图片都失效了！失效了！

所以，图床还是自己维护比较靠谱！

PicList，免费开源，我自己是购买了阿里云按量付费的 OSS，简单配置一下 aks，即可上传图片，配合 Typora，轻松完成写作

配置好之后，图片拖到 markdown 编辑框，即可实现自动上传

BreakTime 定时提醒工具

为了你的健康，你可以让电脑提醒你，每隔30分钟休息一下，倒杯水，看看风景

DaisyDisk （付费）磁盘空间，文件大小分析工具

作为只能买 256G 的屌丝，每天困扰我的一件事就是磁盘空间不足
现在我是 2T 了，可以不用了
也可以使用 腾讯柠檬用过一段时间，也很好用

微信输入法

搜狗输入法、RIME、百度输入法（作恶多端，还用）
上一次推荐，我还是使用搜狗输入法，有朋友推荐微信输入法，体验了一把，简洁、功能齐全，所以手机、PC 全部改用微信输入法
推荐跨设备复制黏贴，速度比苹果自带的快了许多

思维导图：Xmind, MindNode

脑图应用，一般在项目开发过程中用于 需求分解，Model Design 等等。

其他小应用

• Caffeine


• Manico, 在 macOS 强大的触摸板下，一直认为这个软件没什么用, 而且快捷键还有很多冲突


• tmate, 搞基神器，结对编程，定位问题必备神器

Chrome 插件推荐

• Vimium, 通过键盘快捷键操作网页，比如打开，关闭，查找书签等等


• FeHelper(前端助手)：JSON自动格式化、手动格式化，支持排序、解码、下载等，更多功能可在配置页按需安装


• Axure RP Extension for Chrome


• Grammarly for Chrome，语法检查


• Octotree，github源码查看神器


• OneTab，节省高达95％的内存，并减轻标签页混乱现象


• Postman Interceptor


• React Developer Tools


• Redux DevTools


• Yet Another Drag and Go：超级拖拽.向四个方向拖拽文字即可进行相应的搜索.拖拽链接可在前台/后台,左侧/右侧打开


• 掘金


• Sider: ChatGPT 侧边栏 + GPT-4o, Claude 3.5, Gemini 1.5 & AI工具”的产品徽标图片 Sider: ChatGPT 侧边栏 + GPT-4o, Claude 3.5, Gemini 1.5 & AI工具


• xSwitch：前端开发代理神器，在线 debug 问题，把线上资源代理到本地，方便复现问题

在 MySQL 中，limit X,Y 的查询中，X 值越大，那么查询速度也就越慢，例如以下示例：

• limit 0,10：查询时间大概在 20 毫秒左右。


• limit 1000000,10：查询时间可能是 15 秒左右（1秒等于 1000 毫秒），甚至更长时间。

所以，可以看出，limit 中 X 值越大，那么查询速度都越慢。

这个问题呢其实就是 MySQL 中典型的深度分页问题。那问题来了，为什么 limit 越往后查询越慢？如何优化查询速度呢？

为什么limit越来越慢？

在数据库查询中，当使用 LIMIT x, y 分页查询时，如果 x 值越大，查询速度可能会变慢。这主要是因为数据库需要扫描和跳过 x 条记录才能返回 y 条结果。随着 x 的增加，需要扫描和跳过的记录数也增加，从而导致性能下降。

例如 limit 1000000,10 需要扫描 1000010 行数据，然后丢掉前面的 1000000 行记录，所以查询速度就会很慢。

优化手段

对于 MySQL 深度分页比较典型的优化手段有以下两种：

1.起始ID定位法

起始 ID 定位法指的是 limit 查询时，指定起始 ID。而这个起始 ID 是上一次查询的最后一条 ID。例如上一次查询的最后一条数据的 ID 为 6800000，那我们就从 6800001 开始扫描表，直接跳过前面的 6800000 条数据，这样查询的效率就高了，具体实现 SQL 如下：

select name, age, gender

from person

where id > 6800000 -- 核心实现 SQL

order by id limit 10;

其中 id 字段为表的主键字段。

为什么起始ID查询效率高呢？

因此这种查询是以上一次查询的最后 ID 作为起始 ID 进行查询的，而上次的 ID 已经定位到具体的位置了，所以只需要遍历 B+ 树叶子节点的双向链表（主键索引的底层数据结构）就可以查询到后面的数据了，所以查询效率就比较高，如下图所示：

如果上次查询结果为 9，之后再查询时，只需要从 9 之后再遍历 N 条数据就能查询出结果了，所以效率就很高。

优缺点分析

这种查询方式，只适合一页一页的数据查询，例如手机 APP 中刷新闻时那种瀑布流方式。

但如果用户是跳着分页的，例如查询完第 1 页之后，直接查询第 250 页，那么这种实现方式就不行了。

2.索引覆盖+子查询

此时我们为了查询效率，可以使用索引覆盖加子查询的方式，具体实现如下。

假设，我们未优化前的 SQL 如下：

select name, age, gender

from person

order by createtime desc 

limit 1000000,10;

在以上 SQL 中，createtime 字段创建了索引，但查询效率依然很慢，因为它要取出 100w 完整的数据，并需要读取大量的索引页，和进行频繁的回表查询，所以执行效率会很低。

此时，我们可以做以下优化：

SELECT p1.name, p1.age, p1.gender

FROM person p1

JOIN (

    SELECT id FROM person ORDER BY createtime desc LIMIT 1000000, 10

) AS p2 ON p1.id = p2.id;

相比于优化前的 SQL，优化后的 SQL 将不需要频繁回表查询了，因为子查询中只查询主键 ID，这时可以使用索引覆盖来实现。那么子查询就可以先查询出一小部分主键 ID，再进行查询，这样就可以大大提升查询的效率了。

索引覆盖（Index Coverage）是一种数据库查询优化技术，它指的是在执行查询时，数据库引擎可以直接从索引中获取所有需要的数据，而不需要再回表（访问主键索引或者表中的实际数据行）来获取额外的信息。这种方式可以减少磁盘 I/O 操作，从而提高查询性能。

课后思考

你还知道哪些深度分页的优化手段呢？欢迎评论区留下你的答案。

本文已收录到我的面试小站 http://www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。

故事背景

在八股文中，说到如何进行数据库的优化，除了基本的索引优化，经常会提到分库分表，说是如果业务量剧增，数据库性能会到达瓶颈，如果单表数据超过两千万，数据查询效率就会变低，就要引入分库分表巴拉巴拉。我同事也问我，我们数据表有些是上亿数据的，为什么不用分库分表，如果我没接触过分库分表我也会觉得大数据表就要分库分表呀，这是八股文一直以来教导的东西。但是我就跟他说，分库分表很坑爹，最近才让我遇到一个BUG......

系统复杂度upup

业务中有个设备表数据量很大，到现在为止已经有5、6亿数据了。在4年前，前人们已经尝试了分库分表技术，分了4个库，5个表，我只是负责维护这个业务发现他们用了分库分表。但是在查询表数据的时候看到是查询ES的，我就问为什么要用ES？同事回答查询分库分表一定要带分片才能走到路由，否则会查询全部库和全部表，意思是不查分片字段，单表只用一个SQL，但是分库分表要用20个SQL.....所以引入了ES进行数据查询。但是引入ES之后又引入一个新的问题，就是ES和数据库的数据同步问题。他们使用了logstash做数据同步，但不是实时的，在logstash设置了每20秒同步一次。

因为要使用分库分表，引入了shardingjdbc，因为查询方便引入了es，因为要处理数据同步问题引入了logstash......所以系统复杂度不是高了一点半点，之前发现有个字段长度设置小了，还要改20张表。

分页问题

最近遇到一个奇怪的bug，在一个设备的单表查询翻页失败，怎么翻都只显示第一页的数据，一开始我以为是分页代码有问题，看了半天跟其他表是一样的，其他表分页没问题，见鬼了。后面再细看发现这个单表的数据源是设备数据源，用的是shardingjdbc的配置。

之前就看过shardingjdbc有一些sql是不支持的，怀疑就是这个原因，百度了一下果然是有bug。

想了一下有两个解决办法，第一个是升级shardingjdbc的版本，据说是4.1之后修复了该问题，但是还没有尝试。

第二个办法是把分库分表业务的数据源跟单表区分开，单表业务使用普通的数据源后分页数据正常显示。

关于数据库优化

一般来说数据库优化，可以从几个角度进行优化：

1、硬件优化

(1) 提升存储性能

• 使用SSD：替换传统机械硬盘（HDD），SSD能提供更快的随机读写速度。


• 增加存储带宽：采用RAID（推荐RAID 10）提高数据存储的读写速度和冗余。


• 内存扩展：尽量让数据库缓存更多的数据，减少IO操作。

(2) 增强CPU性能

• 使用多核高频率CPU，支持更高并发。


• 分析数据库对CPU的利用情况，确保不被CPU性能瓶颈限制。

(3) 提高网络带宽

• 优化服务器与客户端之间的网络延迟和带宽，尤其是分布式数据库的场景中。


• 使用高速网络接口（如10GbE网卡）。

2、软件层面优化

(1) 数据库配置

• 调整数据库缓冲池（Buffer Pool）的大小，确保能缓存大部分热数据。


• 优化日志文件的写入（如MySQL中调整innodb_log_buffer_size）。


• 使用内存数据库或缓存技术（如Redis、Memcached）加速访问速度。

(2) 分布式架构

• 对于高并发需求，采用分布式数据库（如TiDB、MongoDB）进行读写分离或数据分片。

(3) 数据库索引

• 选择合适的索引类型：如B+树索引、哈希索引等，根据查询特点选择适配的索引。


• 避免冗余索引，定期清理无用索引。

(4) 数据库版本升级

• 保持数据库版本为最新的稳定版本，利用最新的优化特性和Bug修复。

3. SQL层面优化

(1) 查询优化

• 减少不必要的字段：只查询需要的列，避免使用SELECT *。


• 加速排序和分组：在ORDER BY和GR0UP BY字段上建立索引。


• 拆分复杂查询：将复杂的SQL分解为多个简单查询或视图。


• 分页查询优化：如避免大OFFSET分页，可以使用索引条件替代（如WHERE id > last_seen_id）。

(2) 合理使用索引

• 对频繁用于WHERE、JOIN、GR0UP BY等的字段建立索引。


• 避免在索引列上使用函数或隐式转换。

(3) 减少锁定

• 尽量使用小事务，减少锁定范围。


• 使用合适的事务隔离级别，避免不必要的资源等待。

(4) SQL调优工具

• 使用数据库自带的分析工具（如MySQL的EXPLAIN、SQL Server的性能监控工具）来分析查询计划并优化执行路径。

4. 综合优化

• 定期进行性能分析：定期查看慢查询日志，优化慢查询。


• 清理历史数据：对于不再使用的历史数据，可存储到冷数据仓库，减少主数据库的负载。


• 使用连接池：通过数据库连接池（如HikariCP）管理和复用连接，降低创建和销毁连接的开销。

tips:

现网的数据库是64核128G内存，测试环境是32核64G，加上现网数据库配置的优化，现网数据库查询大表的速度是测试环境的3倍！所以服务器硬件配置和数据库配置都很重要。下面是数据库的配置文件，仅供参考

[universe]

bakupdir = /data/mysql/backup/7360

iops = 0

mem_limit_mb = 0

cpu_quota_percentage = 0

quota_limit_mb = 0

scsi_pr_level = 0

mycnf = /opt/mysql/etc/7360/my.cnf

run_user = actiontech-mysql

umask_dir = 0750

umask = 0640

id = mysql-mt1cbg

group_id = mysql-test



[mysql]

no-auto-rehash

prompt = '\\u@\\h:\\p\\R:\\m:\\s[\\d]> '

#default-character-set = utf8mb4

#tee = /data/mysql_tmp/mysql_operation.log



[mysqld]

super_read_only = 1

# DO NOT MODIFY, Universe will generate this part

port = 7360

server_id = 123

basedir = /opt/mysql/base/5.7.40

datadir = /data/mysql/data/7360

log_bin = /opt/mysql/log/binlog/7360/mysql-bin

tmpdir = /opt/mysql/tmp/7360

relay_log = /opt/mysql/log/relaylog/7360/mysql-relay

innodb_log_group_home_dir = /opt/mysql/log/redolog/7360

log_error = /data/mysql/data/7360/mysql-error.log

# 数据库ip

report_host = xxx



# BINLOG

binlog_error_action = ABORT_SERVER

binlog_format = row

binlog_rows_query_log_events = 1

log_slave_updates = 1

master_info_repository = TABLE

max_binlog_size = 250M

relay_log_info_repository = TABLE

relay_log_recovery = 1

sync_binlog = 1



# GTID #

gtid_mode = ON

enforce_gtid_consistency = 1

binlog_gtid_simple_recovery = 1



# ENGINE

default_storage_engine = InnoDB

innodb_buffer_pool_size = 64G

innodb_data_file_path = ibdata1:1G:autoextend

innodb_file_per_table = 1

innodb_flush_log_at_trx_commit = 1

innodb_flush_method = O_DIRECT

innodb_io_capacity = 1000

innodb_log_buffer_size = 64M

innodb_log_file_size = 2G

innodb_log_files_in_group = 2

innodb_max_dirty_pages_pct = 60

innodb_print_all_deadlocks = 1

#innodb_stats_on_metadata = 0

innodb_strict_mode = 1

#innodb_undo_logs = 128                 #Deprecated In 5.7.19

#innodb_undo_tablespaces=3          #Deprecated In 5.7.21

innodb_max_undo_log_size = 4G

innodb_undo_log_truncate = 1

innodb_read_io_threads = 8

innodb_write_io_threads = 8

innodb_purge_threads = 4

innodb_buffer_pool_load_at_startup = 1

innodb_buffer_pool_dump_at_shutdown = 1

innodb_buffer_pool_dump_pct = 25

innodb_sort_buffer_size = 8M

#innodb_page_cleaners = 8

innodb_buffer_pool_instances = 8

innodb_lock_wait_timeout = 10

innodb_io_capacity_max = 2000

innodb_flush_neighbors = 1

#innodb_large_prefix = 1

innodb_thread_concurrency = 64

innodb_stats_persistent_sample_pages = 64

innodb_autoinc_lock_mode = 2

innodb_online_alter_log_max_size = 1G

innodb_open_files = 4096

innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:50G

innodb_rollback_segments = 128

#innodb_numa_interleave = 1



# CACHE

key_buffer_size = 16M

tmp_table_size = 64M

max_heap_table_size = 64M

table_open_cache = 2000

query_cache_type = 0

query_cache_size = 0

max_connections = 3000

thread_cache_size = 200

open_files_limit = 65535

binlog_cache_size = 1M

join_buffer_size = 8M

sort_buffer_size = 2M

read_buffer_size = 8M

read_rnd_buffer_size = 8M

table_definition_cache = 2000

table_open_cache_instances = 8





# SLOW LOG

slow_query_log = 1

slow_query_log_file = /data/mysql/data/7360/mysql-slow.log

log_slow_admin_statements = 1

log_slow_slave_statements = 1

long_query_time = 1



# SEMISYNC #

plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"

rpl_semi_sync_master_enabled = 1

rpl_semi_sync_slave_enabled = 0

rpl_semi_sync_master_wait_for_slave_count = 1

rpl_semi_sync_master_wait_no_slave = 0

rpl_semi_sync_master_timeout = 30000



# CLIENT_DEPRECATE_EOF

session_track_schema = 1

session_track_state_change = 1

session_track_system_variables = '*'



# MISC

log_timestamps = SYSTEM

lower_case_table_names = 1

max_allowed_packet = 64M

read_only = 1

skip_external_locking = 1

skip_name_resolve = 1

skip_slave_start = 1

socket = /data/mysql/data/7360/mysqld.sock

pid_file = /data/mysql/data/7360/mysqld.pid

disabled_storage_engines = ARCHIVE,BLACKHOLE,EXAMPLE,FEDERATED,MEMORY,MERGE,NDB

log-output = TABLE,FILE

character_set_server = utf8mb4

secure_file_priv = ""

performance-schema-instrument = 'wait/lock/metadata/sql/mdl=ON'

performance-schema-instrument = 'memory/% = COUNTED'

expire_logs_days = 7

max_connect_errors = 1000000

interactive_timeout = 1800

wait_timeout = 1800

log_bin_trust_function_creators = 1



# MTS

slave-parallel-type = LOGICAL_CLOCK

slave_parallel_workers = 16

slave_preserve_commit_order = ON

slave_rows_search_algorithms = 'INDEX_SCAN,HASH_SCAN'



##BaseConfig

collation_server = utf8mb4_bin

explicit_defaults_for_timestamp = 1

transaction_isolation = READ-COMMITTED



##Unused

#plugin-load-add = validate_password.so

#validate_password_policy = MEDIUM

总结

如果我没用过分库分表，面试官问我数据库优化，我可能也会回答分库分表。但是踩过几个坑之后可能会推荐其他的方式。

1、按业务分表，比如用户表放在用户库，订单表放在订单库，用微服务的思想切割数据库减少数据库压力。

2、如果数据量超过10E，可以考虑上分布式数据库，融合了OLAP和OLTP的优点，毕竟mysql其实不适合做大数据量的查询统计。评论区也可以推荐一下有哪些好的数据库。

3、按时间归档数据表，每天或者每个月把历史数据存入历史数据表，适用于大数据量且历史数据查询较少的业务。

每个技术都有它的利弊，比如微服务、分库分表、分布式数据库等。按需选择技术类型，切勿过度设计！

今天前端一直在群里说，服务是不是又挂了？一直返回 503。我一听这不对劲，赶紧看了一眼 K8S 的 pod 状态，居然重启了4次。测试环境只有一个副本，所以赶紧把副本数给上调到了3个。

堵住前端的嘴，免得破坏我在老板心目中的形象，我害怕下次加薪名单没有我，而优化名单有我。

暂时安抚好前端之后我得立马看看哪里出问题了，先看看 K8S 为什么让这个容器领盒饭了。

Last State: Terminated 

Reason: OOMKilled

看起来是 JVM 胃口太大，被 K8S 嫌弃从而被赶走了。看看最近谁提交部署了，把人拉过来拷问一番。

代码摆出来分析，发现这小子每次使用http调用都会 new 一个连接池对象。一次业务请求使用了 6 次 http 调用，也就是会 new 6 个连接池对象。有可能是这里的问题，抓紧改了发上去测试看看。

不出意外的话又出意外了，上去之后也没缓解，那就不是这个问题了。要找到具体的原因还是不能瞎猜，得有专业的工具来进行分析才行。之前为了省点镜像空间，所以使用了 jre 的基础镜像。

总所周知，jre 只有一个运行环境，是没有开发工具的。所以我们得使用 jdk。你说我为省那点空间干什么？都想抽自己了。我们应该以 "让打靶老板花钱"为荣，以 "为打靶老板省钱"为耻。

把JDK准备好之后，就要开始我的第一次了。开始之前总是需要洗白白的，把一些影响心情的东西全部处理掉，就像这个 Skywalking，之前一直跟着我。但现在影响到我了，我得暂时把它放一边。不然他会在进行的过程中一直蹦出来烦人。

使用 Skywalking 需要设置此环境变量，每一次执行Java相关的命令都会执行 Skywalking 的一些操作，可以使用 unset 命令把环境变量临时置空。因为等我做完还是需要他来继续给我工作的。

unset JAVA_TOOL_OPTIONS

琐碎事处理完了之后，就得挑个技师才行。这行命令一把梭就会打印出所有 java 进程信息，这主要是为了获取到 vmid，也就是技师的编号。

jps -lv

root@xxx-ext-6464577d8-vvz2n:/app# jps -lv

608 sun.tools.jps.Jps -Denv.class.path=.:/usr/local/java/lib/rt.jar:/usr/local/java/lib/dt.jar:/usr/local/java/lib/tools.jar -Dapplication.home=/usr/local/openjdk-8 -Xms8m

7 /root/app/xxx-ext.jar -javaagent:/skywalking/agent/skywalking-agent.jar -Dfile.encoding=UTF-8 -Xms1024m -Xmx2048m

568 sun.tools.jstat.Jstat -javaagent:/skywalking/agent/skywalking-agent.jar -Denv.class.path=.:/usr/local/java/lib/rt.jar:/usr/local/java/lib/dt.jar:/usr/local/java/lib/tools.jar -Dapplication.home=/usr/local/openjdk-8 -Xms8m

这里总共查到3个Java进程，608 jps、7 xxx-ext 和 568 jstat。中间这个 7 号技师 xxx-ext 就是我相中的，我将会把第一次交给他。

选完技师就正式开始了，过程中要时刻关心对方的身体状态。隔几秒钟就问一下状态怎么样？为了方便时刻了解对方的身体状态，可以用这个命令每隔5s就问一下。如果你对自己的能力有信心可以把间隔设置短一些。

# jstat -gcutil {vmid} {间隔毫秒}

jstat -gcutil 7 5000

root@xxx-ext-6464577d8-vvz2n:/app# jstat -gcutil 7 5000

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT

 99.96   0.00 100.00 100.00  95.85  94.74    178    8.047     8    3.966   12.012

 99.97   0.00 100.00 100.00  95.50  94.33    178    8.047    11    8.072   16.118

 99.99   0.00 100.00 100.00  95.51  94.33    178    8.047    14   12.408   20.455

100.00   0.00 100.00 100.00  95.48  94.30    178    8.047    18   17.140   25.187

100.00   0.00 100.00 100.00  95.48  94.30    178    8.047    23   22.730   30.776

100.00   0.00 100.00 100.00  95.48  94.30    178    8.047    27   27.035   35.082

100.00   0.00 100.00 100.00  95.49  94.30    178    8.047    32   32.614   40.661

虽然是第一次，但对方给回来的信息务必要了然于胸。知己知彼胜券在握，所以要把下面的心法记住。这会影响我们下一步的动作。

S0/S1 是Survivor区空间使用率

E 是新生代空间使用率

O 是老年代空间使用率

YGC 是 Young GC 次数

YGCT 是 Young GC 总耗时

FGC 是 Full GC 次数

FGCT 是 Full GC 总耗时

当对方的状态到达一个关键点的时候，一般是老年代满，或者是新生代满，这就表示对方快溢出来了。像我提供的这个示例，E 和 O 的使用率都是100，就说明对方不仅满了，还快噶了。我们得赶紧把这个关键时刻详细探究一下，看看是哪个对象让对方感觉到满的。

用这个命令查询对方体内对象占用排名，不用贪多，前10个就绰绰有余了。你能把前10个全部弄清楚就够牛了。

jmap -histo:live 7 | head -n 10

root@xxx-ext-6464577d8-vvz2n:/app# jmap -histo:live 7 | head -n 10



 num     #instances         #bytes  class name

----------------------------------------------

   1:        454962     1852234368  [C

   2:       1773671       56757472  java.util.HashMap$Node

   3:        881987       30188352  [B

   4:         55036       19781352  [Ljava.util.HashMap$Node;

   5:        857235       13715760  java.lang.Integer

   6:        852094       13633504  com.knuddels.jtokkit.ByteArrayWrapper

   7:        454195       10900680  java.lang.String

   8:        104386        6436624  [Ljava.lang.Object;

   9:        191593        6130976  java.util.concurrent.ConcurrentHashMap$Node

  10:         63278        5568464  java.lang.reflect.Method

可以看到对方已经在边缘了，我们要抓紧分析了。我提供的这个示例，排名前三分别是 [C、java.util.HashMap$Node 和 [B，[C 表示字符数组，[B 表示字节数组。看来对方偏爱 [C，占用差不多1.7G，需要重点分析它。

这一步就到了十字路口，关键点在于我们能不能从这里分析得到对方偏爱的对象，从而定位到代码中的问题点。一旦我们定位到代码中的问题点，那就证明对方已经被我们拿捏了，流程结束。

那就开始分析吧，先看看最近哪个瘪犊子提交了代码，把他拉过来。然后看最近改动的代码哪里和 [C 相关，一般是 List<String>、StringBuffer 这类对象。

我没想到小丑竟是我自己🤡，有一个接口入参是一个 List<ID>，当这个 list 传了空的时候，就会把库里的所有数据都查出来。

破案了，这次把对方完全拿捏了，流程结束。

如果上一步无法拿捏，那就不要讲武德了。把对方的一举一动dump下来，最终导出成堆快照来分析。

dump 时间取决于数据量

jmap -dump:live,format=b,file=heap.hprof 7

root@xxx-ext-6464577d8-vvz2n:/app# jmap -dump:live,format=b,file=heap.hprof 7

Dumping heap to /app/heap.hprof ...

Heap dump file created

将dump文件从pod中复制出来

kubectl cp <ns>/<pod>:/app/heap.hprof ./heap.hprof

kubectl cp test/xxx-ext-6464577d8-vvz2n:/app/heap.hprof ./heap.hprof

我摊牌了，这一步我压根没做。

当我想从pod中把对快照复制出来的时候磁盘空间不够，然后pod就被 K8S 这个暴脾气干了，只剩下我颤抖的手无力地放在键盘上。

Ref

juejin.cn/post/700622…

文件上传功能几乎是每个 Web 应用不可或缺的一部分。无论是个人博客中的图片上传，还是企业级应用中的文档管理，文件上传都扮演着至关重要的角色。今天，松哥和大家来聊聊文件上传中的几个高级玩法——秒传、断点续传和分片上传。

一 文件上传的常见场景

在日常开发中，文件上传的场景多种多样。比如，在线教育平台上的视频资源上传，社交平台上的图片分享，以及企业内部的知识文档管理等。这些场景对文件上传的要求也各不相同，有的追求速度，有的注重稳定性，还有的需要考虑文件大小和安全性。因此，针对不同需求，我们有了秒传、断点续传和分片上传等解决方案。

二 秒传、断点上传与分片上传

秒传

秒传，顾名思义，就是几乎瞬间完成文件上传的过程。其实现原理是通过计算文件的哈希值（如 MD5 或 SHA-1），然后将这个唯一的标识符发送给服务器。如果服务器上已经存在相同的文件，则直接返回成功信息，避免了重复上传。这种方式不仅节省了带宽，也大大提高了用户体验。

断点续传

断点续传是指在网络不稳定或者用户主动中断上传后，能够从上次中断的地方继续上传，而不需要重新开始整个过程。这对于大文件上传尤为重要，因为它可以有效防止因网络问题导致的上传失败，同时也能节约用户的流量和时间。

分片上传

分片上传则是将一个大文件分割成多个小块分别上传，最后再由服务器合并成完整的文件。这种做法的好处是可以并行处理多个小文件，提高上传效率；同时，如果某一部分上传失败，只需要重传这一部分，不影响其他部分。

三 秒传实战

后端实现

在 SpringBoot 项目中，我们可以使用 MessageDigest 类来计算文件的 MD5 值，然后检查数据库中是否存在该文件。

@RestController

@RequestMapping("/file")

public class FileController {

    @Autowired

    FileService fileService;



    @PostMapping("/upload1")

    public ResponseEntity<String> secondUpload(@RequestParam(value = "file",required = false) MultipartFile file,@RequestParam(required = false,value = "md5") String md5) {

        try {

            // 检查数据库中是否已存在该文件

            if (fileService.existsByMd5(md5)) {

                return ResponseEntity.ok("文件已存在");

            }

            // 保存文件到服务器

            file.transferTo(new File("/path/to/save/" + file.getOriginalFilename()));

            // 保存文件信息到数据库

            fileService.save(new FileInfo(file.getOriginalFilename(), DigestUtils.md5DigestAsHex(file.getInputStream())));

            return ResponseEntity.ok("上传成功");

        } catch (Exception e) {

            return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("上传失败");

        }

    }

}

前端调用

前端可以通过 JavaScript 的 FileReader API 读取文件内容，通过 spark-md5 计算 MD5 值，然后发送给后端进行校验。

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>秒传</title>

    <script src="spark-md5.js"></script>

</head>

<body>

<input type="file" id="fileInput" />

<button onclick="startUpload()">开始上传</button>

<hr>

<script>

    async function startUpload() {

        const fileInput = document.getElementById('fileInput');

        const file = fileInput.files[0];

        if (!file) {

            alert("请选择文件");

            return;

        }



        const md5 = await calculateMd5(file);

        const formData = new FormData();

        formData.append('md5', md5);



        const response = await fetch('/file/upload1', {

            method: 'POST',

            body: formData

        });



        const result = await response.text();

        if (response.ok) {

            if (result != "文件已存在") {

                // 开始上传文件

            }

        } else {

            console.error("上传失败: " + result);

        }

    }



    function calculateMd5(file) {

        return new Promise((resolve, reject) => {

            const reader = new FileReader();

            reader.onloadend = () => {

                const spark = new SparkMD5.ArrayBuffer();

                spark.append(reader.result);

                resolve(spark.end());

            };

            reader.onerror = () => reject(reader.error);

            reader.readAsArrayBuffer(file);

        });

    }

</script>

</body>

</html>

前端分为两个步骤：

四 分片上传实战

分片上传关键是在前端对文件切片，比如一个 10MB 的文件切为 10 份，每份 1MB。每次上传的时候，需要多一个参数记录当前上传的文件切片的起始位置。

比如一个 10MB 的文件，切为 10 份，每份 1MB，那么：

• 第 0 片，从 0 开始，一共是 1024*1024 个字节。


• 第 1 片，从 1024*1024 开始，一共是 1024*1024 个字节。


• 第 2 片...

把这个搞懂，后面的代码就好理解了。

后端实现

private static final String UPLOAD_DIR = System.getProperty("user.home") + "/uploads/";

/**

 * 上传文件到指定位置

 *

 * @param file 上传的文件

 * @param start 文件开始上传的位置

 * @return ResponseEntity<String> 上传结果

 */

@PostMapping("/upload2")

public ResponseEntity<String> resumeUpload(@RequestParam("file") MultipartFile file, @RequestParam("start") long start,@RequestParam("fileName") String fileName) {

    try {

        File directory = new File(UPLOAD_DIR);

        if (!directory.exists()) {

            directory.mkdirs();

        }

        File targetFile = new File(UPLOAD_DIR + fileName);

        RandomAccessFile randomAccessFile = new RandomAccessFile(targetFile, "rw");

        FileChannel channel = randomAccessFile.getChannel();

        channel.position(start);

        channel.transferFrom(file.getResource().readableChannel(), start, file.getSize());

        channel.close();

        randomAccessFile.close();

        return ResponseEntity.ok("上传成功");

    } catch (Exception e) {

        System.out.println("上传失败: "+e.getMessage());

        return ResponseEntity.status(500).body("上传失败");

    }

}

后端每次处理的时候，需要先设置文件的起始位置。

前端调用

前端需要将文件切分成多个小块，然后依次上传。

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>分片示例</title>

</head>

<body>

    <input type="file" id="fileInput" />

    <button onclick="startUpload()">开始上传</button>



    <script>

        async function startUpload() {

            const fileInput = document.getElementById('fileInput');

            const file = fileInput.files[0];

            if (!file) {

                alert("请选择文件");

                return;

            }



            const filename = file.name;

            let start = 0;



            uploadFile(file, start);

        }



        async function uploadFile(file, start) {

            const chunkSize = 1024 * 1024; // 每个分片1MB

            const total = Math.ceil(file.size / chunkSize);



            for (let i = 0; i < total; i++) {

                const chunkStart = start + i * chunkSize;

                const chunkEnd = Math.min(chunkStart + chunkSize, file.size);

                const chunk = file.slice(chunkStart, chunkEnd);



                const formData = new FormData();

                formData.append('file', chunk);

                formData.append('start', chunkStart);

                formData.append('fileName', file.name);



                const response = await fetch('/file/upload2', {

                    method: 'POST',

                    body: formData

                });



                const result = await response.text();

                if (response.ok) {

                    console.log(`分片 ${i + 1}/${total} 上传成功`);

                } else {

                    console.error(`分片 ${i + 1}/${total} 上传失败: ${result}`);

                    break;

                }

            }

        }

    </script>

</body>

</html>

五 断点续传实战

断点续传的技术原理类似于分片上传。

当文件已经上传了一部分之后，断了需要重新开始上传。

那么我们的思路是这样的：

后端案例

先来看后端检查的接口，如下：

@GetMapping("/check")

public ResponseEntity<Long> checkFile(@RequestParam("filename") String filename) {

    File file = new File(UPLOAD_DIR + filename);

    if (file.exists()) {

        return ResponseEntity.ok(file.length());

    } else {

        return ResponseEntity.ok(0L);

    }

}

如果文件存在，则返回已经存在的文件大小。

如果文件不存在，则返回 0，表示前端从头开始上传该文件。

前端调用

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>断点续传示例</title>

</head>

<body>

<input type="file" id="fileInput"/>

<button onclick="startUpload()">开始上传</button>



<script>

    async function startUpload() {

        const fileInput = document.getElementById('fileInput');

        const file = fileInput.files[0];

        if (!file) {

            alert("请选择文件");

            return;

        }



        const filename = file.name;

        let start = await checkFile(filename);



        uploadFile(file, start);

    }



    async function checkFile(filename) {

        const response = await fetch(`/file/check?filename=${filename}`);

        const start = await response.json();

        return start;

    }



    async function uploadFile(file, start) {

        const chunkSize = 1024 * 1024; // 每个分片1MB

        const total = Math.ceil((file.size - start) / chunkSize);



        for (let i = 0; i < total; i++) {

            const chunkStart = start + i * chunkSize;

            const chunkEnd = Math.min(chunkStart + chunkSize, file.size);

            const chunk = file.slice(chunkStart, chunkEnd);



            const formData = new FormData();

            formData.append('file', chunk);

            formData.append('start', chunkStart);

            formData.append('fileName', file.name);



            const response = await fetch('/file/upload2', {

                method: 'POST',

                body: formData

            });



            const result = await response.text();

            if (response.ok) {

                console.log(`分片 ${i + 1}/${total} 上传成功`);

            } else {

                console.error(`分片 ${i + 1}/${total} 上传失败: ${result}`);

                break;

            }

        }

    }

</script>

</body>

</html>

这个案例实际上是一个断点续传+分片上传的案例，相关知识点并不难，小伙伴们可以自行体会下。

六 总结

好了，以上就是关于文件上传中秒传、断点续传和分片上传的实战分享。通过这些技术的应用，我们可以极大地提升文件上传的效率和稳定性，改善用户体验。希望各位小伙伴在自己的项目中也能灵活运用这些技巧，解决实际问题。

本文完整案例：github.com/lenve/sprin…

本文首发于公众号：托尼学长，立个写 1024 篇原创技术面试文章的flag，欢迎过来视察监督~

最近有好几个同学跟我说，他在技术面试过程中被问到这个问题了，让我找时间系统地讲解一下。

其实从某种意义上来说，这并不是一个严谨的面试题，接下来 show me the SQL，我们一起来看一下。

如下图所示，一张有 3000多万行记录的 user 表，执行全表 count 操作需要 14.8 秒的时间。

接下来我们稍作调整再试一次，神奇的一幕出现了，执行全表 count 操作竟然连 1 毫秒的时间都用不上。

这是为什么呢？

其实原因很简单，第一次执行全表 count 操作的时候，我用的是 MySQL InnoDB 存储引擎，而第二次则是用的 MySQL MyISAM 存储引擎。

这两者的差别在于，前者在执行 count(*)  操作的时候，需要将表中每行数据读取出来进行累加计数，而后者已经将表的总行数存储下来了，只需要直接返回即可。

当然，InnoDB 存储引擎对 count(*)  操作也进行了一些优化，如果该表创建了二级索引，其会通过全索引扫描的方式来代替全表扫描进行累加计数，

毕竟，二级索引值只存储了索引列和主键列两个字段，遍历计数肯定比存储所有字段的数据表的 IO 次数少很多，也就意味着其执行效率更高。

而且，MySQL 的优化器会选择最小的那个二级索引的索引文件进行遍历计数。

所以，这个技术面试题严谨的问法应该是 —— MySQL InnoDB 存储引擎单表过亿数据，如何优化 count(*) 全表的操作？

下面我们就来列举几个常见的技术解决方案，如下图所示：

（1）Redis 累加计数

这是一种最主流且简单直接的实现方式。

由于我们基本上不会对数据表执行 delete 操作，所以当有新的数据被写入表的时候，通过 Redis 的 incr 或 incrby 命令进行累加计数，并在用户查询汇总数据的时候直接返回结果即可。

如下图所示：

该实现方式在查询性能和数据准确性上两者兼得，Redis 需要同时负责累加计数和返回查询结果操作，缺点在于会引入缓存和数据库间的数据一致性的问题。

（2）MySQL 累加计数表 + 事务

这种实现方式跟“Redis 累加计数”大同小异，唯一的区别就是将计数的存储介质从 Redis 换成了 MySQL。

如下图所示：

但这么一换，就可以将写入表操作和累加计数操作放在一个数据库事务中，也就解决了缓存和数据库间的数据一致性的问题。

该实现方式在查询性能和数据准确性上两者兼得，但不如“Redis 累加计数”方式的性能高，在高并发场景下数据库会成为性能瓶颈。

（3）MySQL 累加计数表 + 触发器

这种实现方式跟“MySQL 累加计数表 + 事务”的表结构是一样的，如下图所示：

****

唯一的区别就是增加一个触发器，不用在工程代码中通过事务进行实现了。

CREATE TRIGGER `user_count_trigger` AFTER INSERT ON `user` FOR EACH ROW BEGIN    UPDATE user_count SET count = count + 1 WHERE id = NEW.id;END

该实现方式在查询性能和数据准确性上两者兼得，与“MySQL 累加计数表 + 事务”方式相比，最大的好处就是不用污染工程代码了。

（4）MySQL 增加并行线程

在 MySQL 8.014 版本中，总算增加了并行查询的新特性，其通过参数 innodb_parallel_read_threads 进行设定，默认值为 4。

下面我们做个实验，将这个参数值调得大一些：

set local innodb_parallel_read_threads = 16;

然后，我们再来执行一次上文中那个 3000 多万行记录 user 表的全表 count 操作，结果如下所示：

参数调整后，执行全表 count 操作的时间由之前的 14.8 秒，降低至现在的 6.1 秒，是可以看到效果的。

接下来，我们继续将参数值调整得大一些，看看是否还有优化空间：

set local innodb_parallel_read_threads = 32;

然后，我们再来执行一次上文中那个 3000 多万行记录 user 表的全表 count 操作，结果如下所示：

参数调整后，执行全表 count 操作的时间竟然变长了，从原来的 6.1 秒变成了 6.8 秒，看样子优化空间已经达到上限了，再多增加执行线程数量只会适得其反。

该实现方式一样可以保证数据准确性，在查询性能上有所提升但相对有限，其最大优势是只需要调整一个数据库参数，在工程代码上不会有任何改动。

不过，如果数据库此时的负载和 IOPS 已经很高了，那开启并行线程或者将并行线程数量调大，会加速消耗数据库资源。

（5）MySQL 增加二级索引

还记得我们在上文中说的内容吗？

InnoDB 存储引擎对 count()  操作也进行了一些优化，如果该表创建了二级索引，其会通过全索引扫描的方式来代替全表扫描进行累加计数，*

毕竟，二级索引值只存储了索引列和主键列两个字段，遍历计数肯定比存储所有字段的数据表的IO次数少很多，也就意味着执行效率更高。

而且，MySQL 的优化器会选择最小的那个二级索引的索引文件进行遍历计数。

为了验证这个说法，我们给 user 表中最小的 sex 字段加一个二级索引，然后通过 EXPLAIN 命令看一下 SQL 语句的执行计划：

果然，这个 SQL 语句的执行计划会使用新建的 sex 索引，接下来我们执行一次看看时长：

果不其然，执行全表 count 操作走了 sex 二级索引后，SQL 执行时间由之前的 14.8 秒降低至现在的 10.6 秒，还是可以看到效果的。

btw：大家可能会觉得效果并不明显，这是因为我们用来测试的 user 表中算上主键 ID 只有七个字段，而且没有一个大字段。

反之，user 表中的字段数量越多，且包含的大字段越多，其优化效果就会越明显。

该实现方式一样可以保证数据准确性，在查询性能上有所提升但相对有限，其最大优势是只需要创建一个二级索引，在工程代码上不会有任何改动。

（6）SHOW TABLE STATUS

如下图所示，通过 SHOW TABLE STATUS 命令也可以查出来全表的行数：

我们常用于查看执行计划的 EXPLAIN 命令也能实现：

只不过，通过这两个命令得出来的表记录数是估算出来的，都不太准确。那到底有多不准确呢，我们来计算一下。

公式为：33554432 / 33216098 = 1.01

就这个 case 而言，误差率大概在百分之一左右。

该实现方式一样可以保证查询性能，无论表中有多大量级的数据都能毫秒级返回结果，且在工程代码方面不会有任何改动，但数据准确性上相差较多，只能用作大概估算。

大家好，我是苏三，又跟大家见面了。

前言

在电商、外卖、票务等系统中，订单超时未支付自动取消是一个常见的需求。

这个功能乍一看很简单，甚至很多初学者会觉得："不就是加个定时器么？" 但真到了实际工作中，细节的复杂程度往往会超乎预期。

这里我们从基础到高级，逐步分析各种实现方案，最后分享一些在生产中常见的优化技巧，希望对你会有所帮助。

苏三最近开源了一个基于 SpringBoot+Vue+uniapp 的商城项目，欢迎访问和star。

1. 使用延时队列（DelayQueue）

适用场景： 订单数量较少，系统并发量不高。

延时队列是Java并发包（java.util.concurrent）中的一个数据结构，专门用于处理延时任务。

订单在创建时，将其放入延时队列，并设置超时时间。

延时时间到了以后，队列会触发消费逻辑，执行取消操作。

示例代码：

import java.util.concurrent.*;



public class OrderCancelService {

    private static final DelayQueue delayQueue = new DelayQueue<>();



    public static void main(String[] args) throws InterruptedException {

        // 启动消费者线程

        new Thread(() -> {

            while (true) {

                try {

                    OrderTask task = delayQueue.take(); // 获取到期任务

                    System.out.println("取消订单：" + task.getOrderId());

                } catch (InterruptedException e) {

                    Thread.currentThread().interrupt();

                }

            }

        }).start();



        // 模拟订单创建

        for (int i = 1; i <= 5; i++) {

            delayQueue.put(new OrderTask(i, System.currentTimeMillis() + 5000)); // 5秒后取消

            System.out.println("订单" + i + "已创建");

        }

    }



    static class OrderTask implements Delayed {

        private final long expireTime;

        private final int orderId;



        public OrderTask(int orderId, long expireTime) {

            this.orderId = orderId;

            this.expireTime = expireTime;

        }



        public int getOrderId() {

            return orderId;

        }



        @Override

        public long getDelay(TimeUnit unit) {

            return unit.convert(expireTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS);

        }



        @Override

        public int compareTo(Delayed o) {

            return Long.compare(this.expireTime, ((OrderTask) o).expireTime);

        }

    }

}

优点：

• 实现简单，逻辑清晰。

缺点：

• 依赖内存，系统重启会丢失任务。
• 随着订单量增加，内存占用会显著上升。

2. 基于数据库轮询

适用场景： 订单数量较多，但系统对实时性要求不高。

轮询是最容易想到的方案：定期扫描数据库，将超时的订单状态更新为“已取消”。

示例代码：

public void cancelExpiredOrders() {

    String sql = "UPDATE orders SET status = 'CANCELLED' WHERE status = 'PENDING' AND create_time < ?";

    try (Connection conn = dataSource.getConnection();

         PreparedStatement ps = conn.prepareStatement(sql)) {

        ps.setTimestamp(1, new Timestamp(System.currentTimeMillis() - 30 * 60 * 1000)); // 30分钟未支付取消

        int affectedRows = ps.executeUpdate();

        System.out.println("取消订单数量：" + affectedRows);

    } catch (SQLException e) {

        e.printStackTrace();

    }

}

优点：

• 数据可靠性强，不依赖内存。
• 实现成本低，无需引入第三方组件。

缺点：

• 频繁扫描数据库，会带来较大的性能开销。
• 实时性较差（通常定时任务间隔为分钟级别）。

优化建议：

• 为相关字段加索引，避免全表扫描。
• 结合分表分库策略，减少单表压力。

3. 基于Redis队列

适用场景： 适合对实时性有要求的中小型项目。

Redis 的 List 或 Sorted Set 数据结构非常适合用作延时任务队列。

我们可以把订单的超时时间作为 Score，订单 ID 作为 Value 存到 Redis 的 ZSet 中，定时去取出到期的订单进行取消。

例子：

public void addOrderToQueue(String orderId, long expireTime) {

    jedis.zadd("order_delay_queue", expireTime, orderId);

}



public void processExpiredOrders() {

    long now = System.currentTimeMillis();

    Set<String> expiredOrders = jedis.zrangeByScore("order_delay_queue", 0, now);

    for (String orderId : expiredOrders) {

        System.out.println("取消订单：" + orderId);

        jedis.zrem("order_delay_queue", orderId); // 删除已处理的订单

    }

}

优点：

1. 实时性高。
2. Redis 的性能优秀，延迟小。

缺点：

1. Redis 容量有限，适合中小规模任务。
2. 需要额外处理 Redis 宕机或数据丢失的问题。

4. Redis Key 过期回调

适用场景： 对超时事件实时性要求高，并且希望依赖 Redis 本身的特性实现简单的任务调度。

Redis 提供了 Key 的过期功能，结合 keyevent 事件通知机制，可以实现订单的自动取消逻辑。

当订单设置超时时间后，Redis 会在 Key 过期时发送通知，我们只需要订阅这个事件并进行相应的处理。

例子：

1. 设置订单的过期时间：

public void setOrderWithExpiration(String orderId, long expireSeconds) {

    jedis.setex("order:" + orderId, expireSeconds, "PENDING");

}

2. 订阅 Redis 的过期事件：

public void subscribeToExpirationEvents() {

    Jedis jedis = new Jedis("localhost");

    jedis.psubscribe(new JedisPubSub() {

        @Override

        public void onPMessage(String pattern, String channel, String message) {

            if (channel.equals("__keyevent@0__:expired")) {

                System.out.println("接收到过期事件，取消订单：" + message);

                // 执行取消订单的业务逻辑

            }

        }

    }, "__keyevent@0__:expired"); // 订阅过期事件

}

优点：

1. 实现简单，直接利用 Redis 的过期机制。
2. 实时性高，过期事件触发后立即响应。

缺点：

1. 依赖 Redis 的事件通知功能，需要开启 notify-keyspace-events 配置。
2. 如果 Redis 中大量使用过期 Key，可能导致性能问题。

注意事项： 要使用 Key 过期事件，需要确保 Redis 配置文件中 notify-keyspace-events 的值包含 Ex。比如：

notify-keyspace-events Ex

最近就业形势比较困难，为了感谢各位小伙伴对苏三一直以来的支持，我特地创建了一些工作内推群， 看看能不能帮助到大家。

你可以在群里发布招聘信息，也可以内推工作，也可以在群里投递简历找工作，也可以在群里交流面试或者工作的话题。

添加苏三的私人微信：su_san_java，备注：掘金+所在城市，即可加入。

5. 基于消息队列（如RabbitMQ）

适用场景： 高并发系统，实时性要求高。

订单创建时，将订单消息发送到延迟队列（如RabbitMQ 的 x-delayed-message 插件）。

延迟时间到了以后，消息会重新投递到消费者，消费者执行取消操作。

示例代码（以RabbitMQ为例）：

public void sendOrderToDelayQueue(String orderId, long delay) {

    Map<String, Object> args = new HashMap<>();

    args.put("x-delayed-type", "direct");

    ConnectionFactory factory = new ConnectionFactory();

    try (Connection connection = factory.newConnection();

         Channel channel = connection.createChannel()) {

        channel.exchangeDeclare("delayed_exchange", "x-delayed-message", true, false, args);

        channel.queueDeclare("delay_queue", true, false, false, null);

        channel.queueBind("delay_queue", "delayed_exchange", "order.cancel");



        AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()

                .headers(Map.of("x-delay", delay)) // 延迟时间

                .build();

        channel.basicPublish("delayed_exchange", "order.cancel", props, orderId.getBytes());

    } catch (Exception e) {

        e.printStackTrace();

    }

}

优点：

1. 消息队列支持分布式，高并发下表现优秀。
2. 数据可靠性高，不容易丢消息。

缺点：

1. 引入消息队列增加了系统复杂性。
2. 需要处理队列堆积的问题。

6. 使用定时任务框架

适用场景： 订单取消操作复杂，需要分布式支持。

定时任务框架，比如：Quartz、Elastic-Job，能够高效地管理任务调度，适合处理批量任务。

比如 Quartz 可以通过配置 Cron 表达式，定时执行订单取消逻辑。

示例代码：

@Scheduled(cron = "0 */5 * * * ?")

public void scanAndCancelOrders() {

    System.out.println("开始扫描并取消过期订单");

    // 这里调用数据库更新逻辑

}

优点：

1. 成熟的调度框架支持复杂任务调度。
2. 灵活性高，支持分布式扩展。

缺点：

1. 对实时性支持有限。
2. 框架本身较复杂。

7. 基于触发式事件流处理

适用场景： 需要处理实时性较高的订单取消，同时结合复杂业务逻辑，例如根据用户行为动态调整超时时间。

可以借助事件流处理框架（如 Apache Flink 或 Spark Streaming），实时地处理订单状态，并触发超时事件。

每个订单生成后，可以作为事件流的一部分，订单未支付时通过流计算触发超时取消逻辑。

示例代码（以 Apache Flink 为例）：

DataStream orderStream = env.fromCollection(orderEvents);



orderStream

    .keyBy(OrderEvent::getOrderId)

    .process(new KeyedProcessFunction() {

        @Override

        public void processElement(OrderEvent event, Context ctx, Collector out) throws Exception {

            // 注册一个定时器

            ctx.timerService().registerProcessingTimeTimer(event.getTimestamp() + 30000); // 30秒超时

        }



        @Override

        public void onTimer(long timestamp, OnTimerContext ctx, Collector out) throws Exception {

            // 定时器触发，执行订单取消逻辑

            System.out.println("订单超时取消，订单ID：" + ctx.getCurrentKey());

        }

    });

优点：

1. 实时性高，支持复杂事件处理逻辑。
2. 适合动态调整超时时间，满足灵活的业务需求。

缺点：

1. 引入了流计算框架，系统复杂度增加。
2. 对运维要求较高。

总结

每种方案都有自己的适用场景，大家在选择的时候，记得结合业务需求、订单量、并发量来综合考虑。

如果你的项目规模较小，可以直接用延时队列或 Redis；而在大型高并发系统中，消息队列和事件流处理往往是首选。

当然，代码实现只是第一步，更重要的是在实际部署和运行中进行性能调优，保证系统的稳定性。

作者：苏三说技术
来源：juejin.cn/post/7451018774743269391

妙用MyBatisPlus，12个实战技巧解锁新知识

前言

说起数据库ORM，我忽然想起了小时候外婆做的那锅鲜美的羊肉汤。平常人家做的羊肉汤无非是几块肉、几片姜，味道寡淡得很，喝了和喝白开水差不多。但外婆的汤，那是另一回事儿 —— 一锅汤，香气四溢，肉质软烂，汤头浓郁得能让人连碗都想舔干净。

写代码何尝不是如此？以前写Mybatis，就像是在煮一锅没有灵魂的羊肉汤：原料都在，但就是不够鲜美。代码繁琐，每写一个查询都像是在不断调味，却怎么也调不出那种令人惊艳的味道。直到遇见MyBatisPlus，一切都变了 —— 这就像是从普通的羊肉汤，突然升级到了外婆秘制的顶级羊肉汤！

MyBatisPlus就像一位精通厨艺的帮厨，它帮你处理了所有繁琐的准备工作。想要一个复杂的查询？不用自己一刀一刀地切肉、一勺一勺地调味，框架已经帮你准备好了。你只需要轻轻地指挥，代码就像汤汁一样顺滑流畅，性能更是鲜美可口。

在接下来的篇幅里，我将与你分享12个MyBatisPlus优化的"秘制配方"。相信看完这些，你写的每一行代码，都会像外婆的羊肉汤一样，让人回味无穷。

耐心看完，你一定有所收获。

避免使用isNull判断

// ❌ 不推荐

LambdaQueryWrapper<User> wrapper1 = new LambdaQueryWrapper<>();

wrapper1.isNull(User::getStatus);



// ✅ 推荐：使用具体的默认值

LambdaQueryWrapper<User> wrapper2 = new LambdaQueryWrapper<>();

wrapper2.eq(User::getStatus, UserStatusEnum.INACTIVE.getCode());

• 📝 原因:
  
  
  
  • 使用具体的默认值可以提高代码的可读性和维护性
  
  
  • NULL值会使索引失效，导致MySQL无法使用索引进行查询优化
  
  
  • NULL值的比较需要特殊的处理逻辑，增加了CPU开销
  
  
  • NULL值会占用额外的存储空间，影响数据压缩效率
  
  
  
  

明确Select字段

// ❌ 不推荐

// 默认select 所有字段

List<User> users1 = userMapper.selectList(null);  



// ✅ 推荐：指定需要的字段

LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();

wrapper.select(User::getId, User::getName, User::getAge);

List<User> users2 = userMapper.selectList(wrapper);

• 📝 原因:
  
  
  
  • 避免大量无用字段的网络传输开销
  
  
  • 可以利用索引覆盖，避免回表查询
  
  
  • 减少数据库解析和序列化的负担
  
  
  • 降低内存占用，特别是在大量数据查询时
  
  
  
  

批量操作方法替代循环

// ❌ 不推荐

for (User user : userList) {

    userMapper.insert(user);

}



// ✅ 推荐

userService.saveBatch(userList, 100);  // 每批次处理100条数据



// ✅ 更优写法：自定义批次大小

userService.saveBatch(userList, BatchConstants.BATCH_SIZE);

• 📝 原因:
  
  
  
  • 减少数据库连接的创建和销毁开销
  
  
  • 批量操作可以在一个事务中完成，提高数据一致性
  
  
  • 数据库可以优化批量操作的执行计划
  
  
  • 显著减少网络往返次数，提升吞吐量
  
  
  
  

Exists方法子查询

// ❌ 不推荐

wrapper.inSql("user_id", "select user_id from order where amount > 1000");



// ✅ 推荐

wrapper.exists("select 1 from order where order.user_id = user.id and amount > 1000");



// ✅ 更优写法：使用LambdaQueryWrapper

wrapper.exists(orderService.lambdaQuery()

    .gt(Order::getAmount, 1000)

    .apply("order.user_id = user.id"));

• 📝 原因:
  
  
  
  • EXISTS是基于索引的快速查询，可以使用到索引
  
  
  • EXISTS在找到第一个匹配项就会停止扫描
  
  
  • IN子查询需要加载所有数据到内存后再比较
  
  
  • 当外表数据量大时，EXISTS的性能优势更明显
  
  
  
  

使用orderBy代替last

// ❌ 不推荐：SQL注入风险

wrapper.last("ORDER BY " + sortField + " " + sortOrder);



// ❌ 不推荐：直接字符串拼接

wrapper.last("ORDER BY FIELD(status, 'active', 'pending', 'inactive')");



// ✅ 推荐：使用 Lambda 安全排序

wrapper.orderBy(true, true, User::getStatus);



// ✅ 推荐：多字段排序示例

wrapper.orderByAsc(User::getStatus)

       .orderByDesc(User::getCreateTime);

• 📝 原因:
  
  
  
  • 直接拼接SQL容易导致SQL注入攻击
  
  
  • 动态SQL可能破坏SQL语义完整性
  
  
  • 影响SQL语句的可维护性和可读性
  
  
  • last会绕过MyBatis-Plus的安全检查机制
  
  
  
  

使用LambdaQuery确保类型安全

// ❌ 不推荐：字段变更后可能遗漏

QueryWrapper<User> wrapper1 = new QueryWrapper<>();

wrapper1.eq("name", "张三").gt("age", 18);



// ✅ 推荐

LambdaQueryWrapper<User> wrapper2 = new LambdaQueryWrapper<>();

wrapper2.eq(User::getName, "张三")

        .gt(User::getAge, 18);



// ✅ 更优写法：使用链式调用

userService.lambdaQuery()

    .eq(User::getName, "张三")

    .gt(User::getAge, 18)

    .list();

• 📝 原因:
  
  
  
  • 编译期类型检查，避免字段名拼写错误
  
  
  • IDE可以提供更好的代码补全支持
  
  
  • 重构时能自动更新字段引用
  
  
  • 提高代码的可维护性和可读性
  
  
  
  

用between代替ge和le

// ❌ 不推荐

wrapper.ge(User::getAge, 18)

       .le(User::getAge, 30);



// ✅ 推荐

wrapper.between(User::getAge, 18, 30);



// ✅ 更优写法：条件动态判断

wrapper.between(ageStart != null && ageEnd != null,

               User::getAge, ageStart, ageEnd);

• 📝 原因:
  
  
  
  • 生成的SQL更简洁，减少解析开销
  
  
  • 数据库优化器可以更好地处理范围查询
  
  
  • 代码更易读，语义更清晰
  
  
  • 减少重复编写字段名的机会
  
  
  
  

排序字段注意索引

// ❌ 不推荐

// 假设lastLoginTime无索引

wrapper.orderByDesc(User::getLastLoginTime);  



// ✅ 推荐

// 主键排序

wrapper.orderByDesc(User::getId);  



// ✅ 更优写法：组合索引排序

wrapper.orderByDesc(User::getStatus)  // status建立了索引

       .orderByDesc(User::getId);     // 主键排序

• 📝 原因:
  
  
  
  • 索引天然具有排序特性，可以避免额外的排序操作
  
  
  • 无索引排序会导致文件排序，极大影响性能
  
  
  • 当数据量大时，内存排序可能导致溢出
  
  
  • 利用索引排序可以实现流式读取
  
  
  
  

分页参数设置

// ❌ 不推荐

wrapper.last("limit 1000");  // 一次查询过多数据



// ✅ 推荐

Page<User> page = new Page<>(1, 10);

userService.page(page, wrapper);



// ✅ 更优写法：带条件的分页查询

Page<User> result = userService.lambdaQuery()

    .eq(User::getStatus, "active")

    .page(new Page<>(1, 10));

• 📝 原因:
  
  
  
  • 控制单次查询的数据量，避免内存溢出
  
  
  • 提高首屏加载速度，优化用户体验
  
  
  • 减少网络传输压力
  
  
  • 数据库资源利用更合理
  
  
  
  

条件构造处理Null值

// ❌ 不推荐

if (StringUtils.isNotBlank(name)) {

    wrapper.eq("name", name);

}

if (age != null) {

    wrapper.eq("age", age);

}



// ✅ 推荐

wrapper.eq(StringUtils.isNotBlank(name), User::getName, name)

       .eq(Objects.nonNull(age), User::getAge, age);



// ✅ 更优写法：结合业务场景

wrapper.eq(StringUtils.isNotBlank(name), User::getName, name)

       .eq(Objects.nonNull(age), User::getAge, age)

       .eq(User::getDeleted, false)  // 默认查询未删除记录

       .orderByDesc(User::getCreateTime);  // 默认按创建时间倒序

• 📝 原因:
  
  
  
  • 优雅处理空值，避免无效条件
  
  
  • 减少代码中的if-else判断
  
  
  • 提高代码可读性
  
  
  • 防止生成冗余的SQL条件
  
  
  
  

⚠️ 下面就要来一些高级货了

查询性能追踪

// ❌ 不推荐：简单计时，代码冗余

public List<User> listUsers(QueryWrapper<User> wrapper) {

    long startTime = System.currentTimeMillis();

    List<User> users = userMapper.selectList(wrapper);

    long endTime = System.currentTimeMillis();

    log.info("查询耗时：{}ms", (endTime - startTime));

    return users;

}



// ✅ 推荐：使用 Try-with-resources 自动计时

public List<User> listUsersWithPerfTrack(QueryWrapper<User> wrapper) {

    try (PerfTracker.TimerContext ignored = PerfTracker.start()) {

        return userMapper.selectList(wrapper);

    }

}



// 性能追踪工具类

@Slf4j

public class PerfTracker {

    private final long startTime;

    private final String methodName;



    private PerfTracker(String methodName) {

        this.startTime = System.currentTimeMillis();

        this.methodName = methodName;

    }



    public static TimerContext start() {

        return new TimerContext(Thread.currentThread().getStackTrace()[2].getMethodName());

    }



    public static class TimerContext implements AutoCloseable {

        private final PerfTracker tracker;



        private TimerContext(String methodName) {

            this.tracker = new PerfTracker(methodName);

        }



        @Override

        public void close() {

            long executeTime = System.currentTimeMillis() - tracker.startTime;

            if (executeTime > 500) {

                log.warn("慢查询告警：方法 {} 耗时 {}ms", tracker.methodName, executeTime);

            }

        }

    }

}