“我的朋友请删掉一些动态吧”——当社区动态堆积成山发布视频时的加载速度就会肉眼可见地变慢。这句看似玩笑的吐槽背后其实藏着一整套性能优化问题。本文就从“动态太多导致加载变慢”这个场景切入展开聊聊动态流性能优化、视频上传与加载优化、数据库查询优化、前端懒加载与虚拟列表等关键技术点。不管你是做社交 App、内容社区、电商评价流还是个人博客的动态模块这套优化思路基本都能迁移使用。1. 问题背景动态多了系统为什么就慢下来了1.1 用户视角的“慢”到底指什么先解读一下开头那句话。用户说“请删掉一些动态吧”这个抱怨的关键词有两个一个是动态数量多一个是发布视频加载慢。把这个问题翻译成技术语言大概是这样的动态数量达到几十万、上百万甚至上亿条时列表接口响应时间从几十毫秒涨到几百毫秒甚至秒级。视频内容体积大上传时容易超时播放时首帧加载慢、卡顿。用户发布一条带视频的动态整个过程从前端上传到后端存储再到内容分发链路的每一步都可能成为瓶颈。动态列表渲染大量图片和视频标签导致页面滚动卡顿、内存占用高、白屏时间长。所以“删掉一些动态吧”这句话本质上是在说当前系统已经处理不了这种数据规模了需要从架构和代码层面做优化。1.2 技术本质动态流的四个核心瓶颈结合上面用户遇到的现象可以把动态变慢的原因拆成四个维度瓶颈维度具体表现典型场景数据库压力查询动态列表时全表扫描、深分页、索引失效动态数量增长到百万级后SQL 执行变慢数据体积动态关联的图片、视频文件过大视频几十 MB上传耗时加载卡顿网络传输资源未走 CDN客户端串行请求较多列表一次性加载几十个资源地址前端渲染一次性渲染过多 DOM 节点下拉加载几页后页面明显卡顿这四个瓶颈通常不是独立出现的。动态多导致数据库查询慢同时动态里的视频多导致带宽压力大而前端又把所有动态一次性渲染出来自然就会形成“又卡又慢”的体验。1.3 为什么这个问题值得系统解决如果不做优化业务上会发生什么用户发布视频动态的成功率下降体验差留存降低。运营人员想通过动态做活动运营结果列表打不开活动效果大打折扣。服务端数据库连接被慢查询占满会拖垮同库的其他业务。用户被迫“删动态”才能恢复流畅这显然不是一个健康的产品形态。所以把“删动态”变成一个技术优化的系统方案比真的让用户删数据要靠谱得多。本文后续的方案就是从数据、查询、资源、前端四个层面来解决问题的。2. 先搞清楚慢在哪里性能排查基础思路2.1 慢的环节如何定位在没有监控系统的情况下最简单的方法是用浏览器开发者工具做一次链路分析。打开动态社区的页面按 F12 切换到 Network 面板然后刷新页面并发布一条动态。观察这几个关键指标指标含义如果异常说明什么DOMContentLoadedHTML 解析完成时间首屏资源太多HTML 太大接口响应时间动态列表接口的耗时后端 SQL 或数据组装慢资源加载时间图片、视频的加载耗时文件体积大或 CDN 配置有问题页面滚动流畅度渲染帧率是否稳定前端 DOM 节点过多发布视频时还要观察上传阶段文件是否被压缩、上传是串行还是并行、后端接收后是否立即转码、有没有走对象存储和 CDN。2.2 常见定位结果对照现象大概率原因优先级接口返回 JSON 就耗时 2 秒数据库查询慢或后端逻辑慢高接口很快但图片加载慢源站带宽不足、CDN 未生效高页面滚动掉帧、卡顿一次渲染了太多动态卡片中上传视频直接超时视频未压缩、未分片、带宽受限高数据量只有几千条但已经很慢代码里存在 N1 查询、没有索引高只有先把慢的环节定位出来后面做的优化才有的放矢。接下来就按“数据层、存储层、前端层”的顺序逐层给出优化方案。3. 数据层优化动态那么多数据库怎么办3.1 不要真的删数据软删除与归档用户说“删掉一些动态吧”但从系统设计角度动态是用户产生的内容资产不能随便物理删除。尤其是带有视频的动态一旦删除用户之前发布的内容就彻底消失了这里既有产品问题也有合规风险。更合理的做法是引入软删除和冷热数据分离。软删除指的是在动态表中增加一个状态字段例如status用 0 表示正常、1 表示删除。用户或运营删除动态时只更新状态字段不执行物理 DELETE。-- 动态表增加状态字段 ALTER TABLE user_post ADD COLUMN status TINYINT NOT NULL DEFAULT 0 COMMENT 0-正常 1-删除; -- 删除动态时更新状态 UPDATE user_post SET status 1, deleted_time NOW() WHERE post_id ?;这样做的优势是数据仍然保留运营可以恢复。不会因为删除操作触发大事务。业务层面可以继续按状态过滤查询。冷热数据分离的思路则是把访问频率极低的历史动态迁移到归档表或归档库中。比如动态表主表只保留最近 90 天的数据更早的数据迁移到user_post_archive表。查询时先查主表查不到再查归档表或者通过创建时间直接路由到对应表。3.2 给动态表设计合理的索引动态列表最常见的查询模式是SELECT * FROM user_post WHERE user_id ? AND status 0 ORDER BY create_time DESC LIMIT 20;这种查询要高效需要建立联合索引。注意这里不是为user_id和create_time各建一个独立索引而是要建一个联合索引ALTER TABLE user_post ADD INDEX idx_user_status_time (user_id, status, create_time);索引设计原则是等值条件放前面排序字段放后面。user_id和status用于等值过滤create_time用于排序。这样查询时可以通过索引直接定位目标记录而不需要临时文件排序。3.3 深分页问题LIMIT 100000, 20 为什么慢动态量大的时候很多人喜欢用LIMIT offset, size做分页。这个写法在页数很小的时候没问题但当用户翻到第 5000 页时SQL 会变成SELECT * FROM user_post WHERE user_id ? AND status 0 ORDER BY create_time DESC LIMIT 100000, 20;数据库需要扫描前面 100000 条记录然后丢弃再返回后续 20 条。页数越深扫描越多耗时自然就上去了。更高效的做法是游标分页也叫 keyset pagination。用上一次返回的最后一条记录的排序字段作为查询条件-- 第一页 SELECT * FROM user_post WHERE user_id ? AND status 0 ORDER BY create_time DESC LIMIT 20; -- 后续页通过 lastCreateTime 游标 SELECT * FROM user_post WHERE user_id ? AND status 0 AND create_time ? ORDER BY create_time DESC LIMIT 20;这种方式的查询条件直接走索引定位不需要扫描大量无关数据。手机端下拉加载动态、滚动加载评论列表都更适合用游标分页。如果业务必须使用传统页码分页可以考虑延迟关联优化SELECT p.* FROM user_post p INNER JOIN ( SELECT post_id FROM user_post WHERE user_id ? AND status 0 ORDER BY create_time DESC LIMIT 100000, 20 ) tmp ON p.post_id tmp.post_id;先用子查询只查主键再回表查完整数据虽然也会扫描大量主键但比直接回表要轻量一些。3.4 动态内容的组装避免 N1 查询动态列表除了查询动态表本身通常还需要关联查询用户头像、昵称、图片列表、点赞数、评论数等。如果每次循环动态列表都执行一次额外的 SQL就会出现 N1 问题。比如下面这种伪代码ListPost posts postMapper.queryPage(...); for (Post post : posts) { User user userMapper.selectById(post.getUserId()); // 每条动态查一次用户 ListPostImage images imageMapper.selectByPostId(post.getId()); // 每条动态查一次图片 }假设一页返回 20 条动态那这一页就要额外执行 40 次查询。换成批量查询后只需要 3 次 SQLListPost posts postMapper.queryPage(...); ListLong userIds posts.stream().map(Post::getUserId).distinct().collect(Collectors.toList()); ListLong postIds posts.stream().map(Post::getId).collect(Collectors.toList()); MapLong, User userMap userMapper.selectBatchIds(userIds) .stream().collect(Collectors.toMap(User::getId, u - u)); MapLong, ListPostImage imageMap imageMapper.selectByPostIds(postIds) .stream().collect(Collectors.groupingBy(PostImage::getPostId));查询次数从 41 次降到了 3 次整体接口耗时会明显下降。4. 视频存储与加载优化发布视频慢传输环节怎么解4.1 发布视频慢的视频文件侧原因发布视频加载慢除了动态列表本身视频文件生成和上传链路是一个更关键的因素。很多情况下用户用手机录制的高清视频体积非常大1 分钟的视频可能就要占用上百 MB 空间。如果客户端不做压缩就直接上传原始文件会带来三个问题上传耗时长弱网环境很容易超时。后端存储成本高对象存储费用随体积线性增长。播放端在低带宽环境下加载原始视频会特别卡。所以发布视频的第一步优化是客户端压缩 服务端转码。客户端压缩通常可以在录制完成后用系统自带的视频编辑能力或第三方 SDK 将视频压缩到合理码率。服务端则负责将上传的视频转成多种清晰度例如 480p、720p、1080p并生成对应的播放地址。4.2 视频分片上传解决大文件超时问题大文件直接上传一旦网络抖动整个上传就失败了。更稳的方案是分片上传也就是把视频切成若干小块依次上传全部上传完成后再通知服务端合并文件。流程大致如下前端计算文件的 MD5生成上传任务 ID。前端将文件切片例如每片 5 MB。逐片上传服务端保存分片信息。全部上传完成前端调用合并接口。服务端合并分片生成完整视频文件并触发转码。以 Java 后端为例接收分片上传的接口大致是这个思路PostMapping(/upload/chunk) public ResponseEntityString uploadChunk( RequestParam(taskId) String taskId, RequestParam(chunkIndex) Integer chunkIndex, RequestParam(totalChunks) Integer totalChunks, RequestPart(file) MultipartFile file) { // 按 taskId 保存分片实际工程中通常写入临时目录或对象存储的临时分区 String chunkDir uploadPath File.separator taskId; File dir new File(chunkDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(chunkDir, chunkIndex .part)); // 可以在此处记录分片上传进度 return ResponseEntity.ok(chunk uploaded); } PostMapping(/upload/merge) public ResponseEntityString mergeChunks( RequestParam(taskId) String taskId, RequestParam(fileName) String fileName) { // 按 chunkIndex 顺序合并分片 File dir new File(uploadPath File.separator taskId); File[] chunkFiles dir.listFiles(); Arrays.sort(chunkFiles, Comparator.comparingInt(f - Integer.parseInt(f.getName().replace(.part, )))); // 合并为完整文件并上传到对象存储然后触发转码 File mergedFile new File(uploadPath File.separator fileName); try (FileOutputStream fos new FileOutputStream(mergedFile); BufferedOutputStream bos new BufferedOutputStream(fos)) { for (File chunk : chunkFiles) { Files.copy(chunk.toPath(), bos); } } return ResponseEntity.ok(merged); }这段代码展示了分片上传和合并的核心思路。实际生产环境通常会把分片直接写入对象存储并在合并时使用流式处理避免占用服务器本地磁盘空间。核心原则是不要一次性把大文件读入内存而是以流的方式处理每个分片。为了让前端能够真正执行分片上传这里也给出一个简单的客户端示例使用 JavaScript 的File.slice方法const fileInput document.getElementById(videoInput); const file fileInput.files[0]; const chunkSize 5 * 1024 * 1024; // 5MB const totalChunks Math.ceil(file.size / chunkSize); const taskId file.name _ file.size _ Date.now(); async function uploadChunks() { for (let i 0; i totalChunks; i) { const start i * chunkSize; const end Math.min(start chunkSize, file.size); const chunk file.slice(start, end); const formData new FormData(); formData.append(taskId, taskId); formData.append(chunkIndex, i); formData.append(totalChunks, totalChunks); formData.append(file, chunk); // 这里需要根据后台上传地址做调整 await fetch(/upload/chunk, { method: POST, body: formData }); } const mergeForm new FormData(); mergeForm.append(taskId, taskId); mergeForm.append(fileName, file.name); await fetch(/upload/merge, { method: POST, body: mergeForm }); }4.3 播放链路CDN 与播放器预加载视频上传完成后播放端也要优化。视频文件一旦上传到对象存储就应该通过 CDN 分发而不是让用户直接从源站拉取。CDN 可以根据用户地理位置就近返回节点内容大幅降低跨地域访问的延迟。CDN 配置上需要注意几个点对象存储需要开启 CDN 加速域名而不是直接使用存储桶默认域名。如果业务有防盗链需求需要配置签名鉴权例如 URL 鉴权或 Key 防盗链。视频文件建议设置较长的缓存时间因为视频内容不像库存价格那样需要频繁更新。播放器侧可以开启首帧优化和预加载策略。比如用户滚动到视频所在位置附近时提前加载前面几个字节的数据用户真正点击播放时首帧出现的速度就会明显提升。5. 前端渲染优化动态再多也不能一次全渲染5.1 图片懒加载按需加载动态中的图片很多动态列表慢不是接口慢而是页面上所有图片都同时请求了。一个动态包含 9 宫格图片首页加载 20 条动态那就是上百张图片同时请求。解决方案是使用图片懒加载也就是图片进入视口区域时才加载资源。最简单的方式是使用原生属性loadingimg srcdefault.png>const observer new IntersectionObserver((entries) { entries.forEach(entry { if (entry.isIntersecting) { const img entry.target; img.src img.dataset.src; observer.unobserve(img); } }); }); document.querySelectorAll(img[data-src]).forEach(img { observer.observe(img); });5.2 视频懒加载与点击播放策略视频和图片一样不能全部预加载。最常见的做法是动态列表中的视频只展示封面图不自动播放。用户点击封面后才加载并播放视频。离开当前区域后暂停播放并释放资源。使用preloadnone或preloadmetadata来控制预加载行为。video classpost-video controls preloadnone posterhttps://cdn.example.com/video-cover.jpg src /video用户点击封面时再触发视频加载const videoCards document.querySelectorAll(.video-card); videoCards.forEach(card { card.addEventListener(click, () { const video card.querySelector(video); video.src card.dataset.videoUrl; video.play(); }); });这样可以避免页面一次性加载多个视频流很大程度上降低卡顿和流量消耗。5.3 虚拟列表几万条动态也不再 DOM 爆炸假设一个用户特别活跃动态特别多前端一次加载 20 条滚动加载 20 次后就渲染了几百个节点。每一条动态都包含图片、视频、文字、操作按钮等结构DOM 节点数量很容易上万。这时候即使数据和网络正常页面也会因为渲染压力而卡顿。虚拟列表的核心思想是只渲染用户当前可见的区域滚动时动态替换列表中的元素。用户向下滚动时离开视口的节点被回收即将进入视口的新数据被渲染。这里给出一个简化版的纵向滚动虚拟列表核心实现以 Vue 3 为例template div classvirtual-list scrollonScroll refcontainer div classlist-placeholder :style{ height: totalHeight px } div classlist-content :style{ transform: translateY(${startIndex * itemHeight}px) } div v-for(item, index) in visibleItems :keyitem.id classlist-item :style{ height: itemHeight px } {{ item.content }} /div /div /div /div /template script setup import { ref, computed, onMounted } from vue; const props defineProps({ items: { type: Array, default: () [] }, itemHeight: { type: Number, default: 120 } }); const container ref(null); const scrollTop ref(0); const containerHeight ref(600); onMounted(() { containerHeight.value container.value.clientHeight; }); const totalHeight computed(() props.items.length * props.itemHeight); const startIndex computed(() Math.floor(scrollTop.value / props.itemHeight)); const endIndex computed(() Math.min(props.items.length, startIndex.value Math.ceil(containerHeight.value / props.itemHeight) 1) ); const visibleItems computed(() props.items.slice(startIndex.value, endIndex.value)); function onScroll() { scrollTop.value container.value.scrollTop; } /script这个示例展示了虚拟列表的核心逻辑通过总高度撑开滚动区域通过transform让可见内容定位到正确位置只渲染可见区间的数据。在实际项目中推荐使用成熟的虚拟列表组件库例如vue-virtual-scroller或react-virtualized但理解原理对排查和定制会有很大帮助。6. 综合实战案例一个动态列表从“卡顿”到“流畅”的改造过程6.1 改造前的业务背景假设有一个内容社区 App动态表user_post已经有 50 万条数据。业务反馈动态列表打开要 3 秒左右发布视频动态经常超时用户滚动页面非常卡。原始实现有两个明显的问题动态列表接口使用LIMIT offset, size翻页超过 20 页后响应时间急剧上升。查询接口返回了完整视频地址和全部评论数据但前端并没有做懒加载所有资源同时请求。6.2 后端接口改造游标分页 批量组装数据改造后的列表接口接收两个参数userId和lastCreateTime。第一次访问不传lastCreateTime后续下拉加载时把上一页最后一条动态的create_time传回来。Service public class PostService { Resource private PostMapper postMapper; public ListPostVO pageFeed(Long userId, LocalDateTime lastCreateTime, int limit) { // 游标分页查询 ListPost posts postMapper.pageByCursor(userId, lastCreateTime, limit); if (posts.isEmpty()) { return Collections.emptyList(); } // 批量查询用户信息与图片信息 ListLong userIds posts.stream().map(Post::getUserId).distinct().collect(Collectors.toList()); ListLong postIds posts.stream().map(Post::getId).collect(Collectors.toList()); MapLong, User userMap userMapper.selectByIds(userIds) .stream().collect(Collectors.toMap(User::getId, u - u)); MapLong, ListString imageMap postImageMapper.selectUrlsByPostIds(postIds) .stream().collect(Collectors.groupingBy( PostImage::getPostId, Collectors.mapping(PostImage::getUrl, Collectors.toList()) )); // 组装 VO return posts.stream().map(post - { PostVO vo new PostVO(); vo.setId(post.getId()); vo.setContent(post.getContent()); vo.setCreateTime(post.getCreateTime()); vo.setAuthor(userMap.getOrDefault(post.getUserId(), new User())); vo.setImages(imageMap.getOrDefault(post.getId(), Collections.emptyList())); // 视频信息单独从对象存储读取只返回封面与播放地址 vo.setVideoCover(post.getVideoCover()); vo.setVideoUrl(post.getVideoUrl()); return vo; }).collect(Collectors.toList()); } }对应的 Mapper 查询Select(script SELECT * FROM user_post WHERE status 0 if testuserId ! null AND user_id #{userId} /if if testlastCreateTime ! null AND create_time lt; #{lastCreateTime} /if ORDER BY create_time DESC LIMIT #{limit} /script) ListPost pageByCursor(Param(userId) Long userId, Param(lastCreateTime) LocalDateTime lastCreateTime, Param(limit) int limit);这里需要注意create_time作为游标字段必须唯一稳定否则可能出现重复。如果同一时刻有多条动态可以在排序中追加主键作为第二排序字段例如ORDER BY create_time DESC, id DESC游标条件也改成(create_time ? OR (create_time ? AND id ?))。6.3 前端改造懒加载 虚拟列表前端把原来的直接渲染全部动态改为三件事每次只请求 10 条到 20 条数据滚动到底部时继续请求下一页。图片全部使用懒加载。动态列表使用虚拟滚动只渲染可见区域的动态卡片。改造完成后接口耗时从原来的 3 秒降到了 300 毫秒到 500 毫秒左右页面滚动也基本不会再出现掉帧情况。6.4 优化效果对照指标优化前优化后动态列表接口耗时2.8 秒350 毫秒首页图片请求数量60 个12 个发布视频成功率弱网62%96%用户滚动帧率18 fps55 fps这里的数值只是示例实际项目中的数据会因服务器配置、带宽、数据量而不同但优化的整体方向和收益是确定的。7. 常见问题与排查清单7.1 常见问题对照表问题现象常见原因解决思路动态列表接口很慢没有索引、深分页、N1 查询添加联合索引改游标分页批量查询翻到后面几页越来越慢使用LIMIT offset, size改为游标分页页面图片加载很慢图片没有懒加载请求过多使用IntersectionObserver懒加载视频发布总是超时直接上传大文件客户端压缩 服务端分片上传视频播放卡顿源站带宽不足没有走 CDN接入 CDN开启多码率转码页面滚动掉帧渲染的 DOM 节点过多使用虚拟列表删除动态后数据无法恢复物理删除改为软删除动态表数据量巨大主表查询慢冷热数据未分离按时间归档迁移历史数据7.2 排查顺序建议遇到“动态加载慢”这类问题不要一开始就改代码。建议按下面顺序排查先看网络面板区分是接口慢还是资源加载慢。如果是接口慢看后端日志和慢 SQL 日志定位 SQL 耗时。用EXPLAIN查看 SQL 执行计划检查索引是否生效。检查代码中的循环查询确认是否有 N1 问题。检查文件存储的带宽和 CDN 命中率。用性能工具分析前端渲染耗时例如 Lighthouse 或 Performance 面板。7.3 发布视频慢的专项排查发布视频慢要分别看客户端和服务端的日志检查点需要确认的内容客户端视频是否压缩分片大小是否合理上传接口每个分片的上传耗时是否有重试机制服务端合并分片耗时转码任务是否排队对象存储上传带宽地域是否与用户一致CDN转码完成后 CDN 缓存是否刷新如果分片上传速度正常但合并后播放卡顿重点检查转码参数和 CDN 预热是否完成。不要等到用户点开视频时才回源拉取运营可以在视频审核通过后主动预热 CDN。8. 从“删动态”到“架构自愈”最佳实践与工程建议8.1 数据规模增长前就要设计好分页方案很多项目的分页方案都是在数据量小的时候定的当时用LIMIT offset, size很流畅于是就一直用到了线上。等数据量上来再改就会面临接口兼容、客户端改动、数据迁移等一系列问题。建议在新项目初期就采用游标分页风格如果客户端确实需要页码类的交互也要在服务端加一层转换。另外给所有核心查询提前设计好联合索引不要等慢 SQL 报警了才去加。8.2 动态内容的缓存策略对于热门动态可以考虑在服务端加一层本地缓存或 Redis 缓存。例如前 100 条热门的动态列表缓存 30 秒查询时先走缓存缓存未命中再走数据库。但要注意缓存一致性。动态被删除、用户被禁言时需要主动清理对应缓存避免删除后动态仍然出现在推荐列表里。8.3 视频处理流程做成异步管道视频上传后不要在上传接口里同步等待转码完成。发布动态接口需要给用户快速响应正确的流程是上传完成接口先返回“发布成功”。后端发送消息到 MQ例如 Kafka 或 RocketMQ。转码服务消费消息执行转码、截图、审核。转码完成后更新动态状态通知客户端。这个方案的好处是即使转码服务出现了抖动也不会影响用户发布动态的体验。8.4 权限与安全注意事项在优化过程中有几点安全问题需要特别留意动态删除接口必须校验操作人身份。用户只能删除自己的动态运营删动态需要单独的角色权限。分片上传合并文件时要对文件名做合法性校验防止路径穿越。视频播放地址如果涉及付费或私密内容应该使用带签名的临时 URL而不是永久公开地址。涉及删除、归档、批量更新数据时必须先在测试环境验证再在低峰期执行。执行前备份相关表数据避免误操作无法恢复。8.5 监控与告警优化完成后要建立持续监控否则下次动态量再翻倍问题还会重新出现。建议至少监控以下指标动态列表接口的 TP99 耗时。慢 SQL 数量。COS / OSS 上传耗时与失败率。CDN 命中率。转码队列积压数。前端页面 FPS。只有这些指标都可视化了团队才能在用户抱怨之前发现性能劣化趋势。9. 总结回到开头那句“我的朋友请删掉一些动态吧”现在已经不需要真的让用户删动态了。通过数据层索引与游标分页、查询层批量组装、视频层压缩分片与 CDN、前端层懒加载与虚拟列表这套组合优化动态再多也能保持流畅体验。当然性能优化是一个持续迭代的过程。如果你的项目现在还没有遇到动态慢的问题可以先做一次体检看看分页方式、索引设计、视频上传链路是否已经合理避免等业务增长后再来补课。如果文中内容对你有帮助可以收藏备用。后续遇到相关报错或优化问题也欢迎在评论区一起交流。