性能优化

程序员吕洞宾

开源多维表格SmartTable v1.6.10 —— 用户名登录、数据评论及@人、表单分享二维码、性能优化、部署及升级优化一句话总结：这版主要干了这几件：💬 记录评论与 @提及——表里面每条记录都能开聊、喊人；📱 表单分享二维码——扫一下就能填表；🔄 版本检测与自动更新——新版本主动提醒你，避免历史缓存的问题；👤 用户名登录——不绑邮箱也能登系统了；性能和安全：优化大表性能、搜索分页更轻、脚本沙箱 / SSRF / SQL 注入 / XSS 等等一系列安全加固。最后划重点——这版升级有讲究，记得先备份再升。

MySQL 8.0 联合索引走错：为什么加了索引查询反而从 200ms 变成 8s本文摘要：线上订单加联合索引后从 200ms 变 8 秒，索引命中却更慢。根因是 MySQL 8.0 偏好免排序索引，低选择性前缀致回表暴涨。仅适用于非覆盖索引场景，统计信息过期需先刷新再判断。

预算给够了，时间花错了地方：三跳链路给了 27 秒，实际只用掉 9 秒一套超时配置通常就三行：单跳 3 秒、每跳重试 2 次、链路总预算 30 秒。这套配置在中小团队的三跳链路里出现频率很高，写的人大多觉得它稳，理由是重试两次等于给长尾留了余量，长尾再慢，三次里总有一次撞上快的。

WebGPU 性能优化：Three.js 千万级点云调度与渲染实践图 1：WebGPU 点云查看器全景效果，当前视角提交约 64.3 万个点实例。点云优化不只是“减少点数”。更关键的是：数据如何组织、如何从二进制进入 GPU、如何按视角选出需要的细节，以及如何让加载、绘制和内存占用保持可控。本文以 L0 含 38,300,617 点的园区数据为例，从数据结构与 Three.js 渲染原理出发，逐步实现分块、LOD、预算调度和 WebGPU 圆珠渲染，最后展示真实页面效果与性能评估。

异常处理 - Native 层的崩溃捕获机制及实现 (一)在 Android 开发中，Java 层的崩溃可以通过 Thread.setDefaultUncaughtExceptionHandler 轻松捕获

只睡四小时

Three.js Sub-tick：漏判 60.7%→0同一个 Three.js 第一人称小项目，把「每帧只在当前点测一次」换成「拿这一帧的移动线段去测」，10fps 下必中弹的落空率从 60.7% 掉到 0。这篇把思路拆成 3 段源码讲清。

图片管线：一张商品图从 1.2MB 到 58KB给自己做的柴烧陶艺概念站（Next.js 静态导出，手写 CSS）里，商品图原本都是相机直出：长边 4000px，单张 1.2MB。首页放四张，光图片就 4.8MB。

【共创稿事节】HarmonyOS 7.0 BindContentCover全屏模态：从接入到生产验证全屏模态(bindContentCover)是介于"弹窗"与"页面跳转"之间的第三种形态:覆盖全屏但不进路由栈,关闭即回到原页面,状态原样保留。健康菜谱助手的图片查看器、全屏编辑器、引导页三个场景用它承接,前两个踩过状态同步和退出确认的坑,后一个验证了引导场景的适配。这篇复盘 bindContentCover 的完整接入:什么时候用它而不是 push 一个页面、modalTransition 的取值、全屏下的返回键与状态栏、以及一次重复打开的事故。

Python日志拖慢请求？QueueHandler排队、丢失与退出实测业务处理只花十几毫秒，接口却偶尔卡到数百毫秒。监控显示数据库查询和计算都正常，最后追到一条看似无关的日志：请求线程把一段内容写到网络日志接收器，网络等待使处理函数没法及时返回。开发者常把日志视为“顺手记一下”，实际上普通日志处理器是在调用日志的线程里执行输出操作，磁盘、网络和格式化开销都可能直接计入请求延迟。

【共创稿事节】HarmonyOS 7.0 Menu菜单与上下文：从接入到生产验证菜单是交互密度最高却最少被认真设计的组件——它出现在长按、点更多按钮、工具栏右键等各种入口,承载高频操作,但大多数应用里的菜单就是一排文字的堆叠。健康菜谱助手的菜单体系覆盖三个场景:菜谱卡片的快捷操作、列表项长按的上下文菜单、工具栏的批量操作。这篇复盘 Menu 从接入到治理的全过程:三种入口的分工、bindMenu 与 bindContextMenu 的选择、动态构建、以及回调引用过期状态的事故。

.NET 性能优化：先找瓶颈，再谈技巧很多 .NET 性能问题，根源不在于“不知道某个优化技巧”，而在于优化了不该优化的地方。有人一听说 Span<T> 快，就把所有字符串处理改一遍；有人觉得 Task.Run 能提速，就给每个数据库查询套一层。结果 CPU 没降，线程池先撑不住了。

Perf 逐步探查性能缺口并优化perf 是一套覆盖硬件计数器、调用栈采样、缓存行一致性、指令级归因与数据源标注的分层诊断系统。下文给出一条递进式工作流，面向台式机 Linux 环境下的计算密集型程序。整条工作流分为七个步骤，每一步只回答一个问题，并为下一步缩小问题空间：

【共创稿事节】HarmonyOS 7.0 BindSheet半模态浮层：从接入到生产验证半模态浮层(bindSheet)是 API 26 里我最愿意主动安利的组件——健康菜谱助手的评论面板、筛选面板、菜谱快捷操作三个场景从手搓 CustomDialog 迁到 bindSheet 后,交互手感直接对齐系统应用:三档高度拖拽、下拉关闭、嵌套滚动全是系统给的。但它的工程细节也不少:detents 的取值策略、内容区嵌套滚动的让渡规则、列表内容动态变化时的高度重算、以及半屏里套输入框的键盘避让。这篇复盘 bindSheet 三个场景的完整接入过程。

【共创稿事节】HarmonyOS 7.0 Want隐式跳转：从接入到生产验证Want 隐式跳转是鸿蒙开放体系里最容易被低估的机制——很多团队第一次接触它是在"应用拉起应用"的需求评审上,自己页面的跳转还停在 router.pushName。健康菜谱助手做过三个真场景:菜谱详情一键唤起系统分享、从冷启动 deeplink 直接进菜谱详情、接入了美食类意图的标准拉起。三个场景走完,才理解隐式跳转的核心不是"跳",是"声明与匹配":调用方描述意图,系统在所有 ability 的 skill 配置里找最合适的承接方,两边的契约写清楚,跳转才稳。这篇记录 Want 隐式跳转的匹配规则、配置

Spring Boot 3.2 偶发500无日志：线程池复用导致请求上下文丢失本文摘要：线上接口偶发 500，按 traceId 查不到对应异常堆栈。根因是 MDC 未跨线程传递，用 TaskDecorator 在任务前后恢复即可。

ABAP 程序性能优化总结目录关键词关键步骤运行效果程序性能优化、效率优化、速度优化尽量减少第一步结果集的行数，这样可以大量减少后续连接大表时的耗时

数据库小学妹

MySQL磁盘IO瓶颈：iostat与刷脏fsync大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。上个月底跑对账，批处理一开，接口开始超时。CPU 只有 30%，慢查询日志里一条慢 SQL 都没有。我盯着 SQL 看了半小时，最后在 iostat 里看到 w/s 飙高，util 贴着 100%。业务不是被 SQL 拖慢的，是被磁盘排队拖慢的。

极限实验室

Easysearch 布尔查询子句重排序（二）｜ConjunctionDISI 按 cost 排序源码解析Lucene 如何让最稀疏的迭代器领跑，最大化跳过无效文档INFINI Easysearch 是一款专注于企业级场景的分布式近实时搜索与分析引擎。它以 Apache Lucene 为内核进行了增强，在保持与行业主流搜索协议及开发生态完全兼容的同时，重点强化了安全性、稳定性、压缩率及信创兼容性。

缓存淘汰实测：一次全表扫描把 LRU 命中率从 46% 打到 38%，W-TinyLFU 守住 50% 却贵 11 倍容量 1000、2 万 key、Zipf 0.9 的 16 万次请求里每 2 万次插一波 3000 个冷 key、3 轮实测：LRU 命中 45.84–46.07%，扫描后 5000 次掉到 38.10–41.30%；LFU 53.99–54.31%，但朴素实现每个操作 26.872–28.223 微秒，换成计数桶同命中率只要 0.519–0.606 微秒；W-TinyLFU 56.46–56.65%，扫描后仍有 49.88–53.66%。

Redis 为什么快？把 "存内存" 这句话拆开看聊 Redis 的性能，绕不开那句被说烂的话："快是因为数据放内存里。" 这话不算错，但太偷懒了。同样把数据放内存的数据库不少，跑到每秒十万级 QPS 的没几个 —— 单节点 Redis 在一台普通服务器上，读能到 10 万 +，写能到 8 万 +，比 MySQL 快一到两个数量级。光靠内存解释不了这个差距，真正的答案藏在它的架构选择里。