性能优化

晚安日记wanna

MySQL 回表为什么这么慢？5 种优化手段逐个拆解回表不必然产生随机 IO，乱序主键回表才是。更坑的是：回表太贵时优化器会直接放弃索引去扫全表——执行计划里没索引，不代表索引写错了。

晚安日记wanna

索引建了却不走？7 个失效原因逐层排查EXPLAIN 里 key 是 NULL，多半不是索引没建好，而是写法逼优化器放弃了它：函数运算、隐式转换、最左前缀、前置百分号、OR 不对等、回表成本过高——逐个排查，优先改写 SQL。

工作10年+，存储芯片行业

Linux NVMe 中断排查与性能优化：CPU 亲和性目录一、背景知识二、原理2.1 NVMe 多队列模型2.2 中断亲和性机制2.3 NUMA 拓扑的影响

Java框架 SpringCloud 快速入门: Feign 的性能优化Feign 的接口调用写起来很舒服，但默认配置下它并不快：底层用的 HttpURLConnection 没有连接池，每个请求都要重新建 TCP 连接。这篇把 Feign 的性能开销拆成四个可控因素，逐个给出配置写法、生效验证方式和踩坑点，核心是"换带连接池的客户端"这一步。

打工仔折腾 AI

从零写一个CAD 05：以鼠标为中心的滚轮缩放，招法能复用但顺序不能反做简易 CAD 视图器到第五篇，前四篇把画布、图元、世界坐标与屏幕坐标的映射、以及基础的平移（pan）都搭起来了。这一篇专门处理滚轮缩放。

手写一个线程池：任务队列、工作线程与停止顺序的三个设计点每个任务 new 一个 std::thread 是并发编程里最贵的偷懒方式：线程创建要走系统调用，栈空间按兆算，销毁又要再来一遍。当任务本身只有几微秒时，你花在「造线程」上的时间会比干活多几十倍。线程池的思路很朴素：线程只创建一次，任务排队，谁空谁取。这篇从零把它写出来，然后把三个最容易写错的设计点讲透。

常州晟凯电子科技

sigmaStar SSC305DE/SSC308开发笔记之开发环境搭建和SDK编译sigmaStar SSC305/SSC308 作为新一代IPC芯片，性能优异，功耗低，可以支持快启，也可用于电池供电的AOV产品。SSC305/SSC308共用同一个SDK，硬件共用同一个设计，方便用户选型和使用。下面简单介绍下它们的开发环境的搭建和SDK编译。

打工仔折腾 AI

从零写一个CAD 05：以鼠标为中心的滚轮缩放矩阵顺序不能反做 CAD 类工具，滚轮缩放看着是最没技术含量的功能，但真正写起来，它往往是第一个把视图坐标系搞乱的地方。前面几篇里我已经把画布、世界坐标、变换栈搭起来了，这一篇专门处理缩放。目标很明确：滚轮滚动时，鼠标指着的那个点在屏幕上不动，视图围绕它放大或缩小。听起来一句话，实际写的时候我改了三次才稳定下来，问题全都出在矩阵乘法的顺序上。

锁进阶：atomic_flag 自旋锁、shared_mutex 读写锁与无锁的代价std::mutex 不是免费的：一旦发生竞争，抢不到锁的线程会被挂进内核，等锁释放再被唤醒，这一挂一醒就是两次上下文切换，微秒级开销。可如果你的临界区只有「++counter」这么短，等锁的时间可能比干活的时间还长。这篇讲清锁的三条进阶路线：极短临界区用自旋锁（atomic_flag 实现）、读多写少用读写锁（shared_mutex）、以及「别迷信无锁，先测再选」。

大模型推理：部署方式与性能优化思路大模型部署的目标，不只是让模型成功运行，还要让它在真实请求下，满足响应速度、生成速度和并发量的要求。增加 GPU 数量并不必然带来加速：每张 GPU 都有独立的显存，把任务拆开以后，设备之间需要传输数据、同步结果，有时通信的成本会超过节省的计算时间。

念何架构之路

zap采样器与性能优化内幕设计要点：FNV-1a：一遍扫描、每字节一次异或一次乘法。抄标准库只为直接吃 string（标准库接口收 []byte 会强制分配）。

Token 用量观测实战：从会话结构拆前缀/工具/生成，建立个人降本仪表盘省 Token 的文章很多，教你砍 Rules、用 @、换模式。但若没有观测，你不知道哪一刀真有效——很容易陷入「这周换了模型，下周又觉得贵」的轮回。本文不重复四步省 Token 操作清单，而做一件更基础的事：把会话成本结构拆开，建成个人能坚持的降本仪表盘。

React Native for OpenHarmony 实战：三方库 react-native-url-polyfill 的鸿蒙化适配指南本文记录把 react-native-url-polyfill（WHATWG URL 标准实现）适配到 HarmonyOS 的完整过程。

RAG Chunks 切分优化后成本骤降 86%大家好，我是 HLAIA 光子。最近在给我的项目 OpenMMV 做 RAG 检索优化，其中很重要的一环是 Chunks 切分优化。之所以要优化，其一是因为服务器性能实在不好，有两台服务器是我在闲鱼上淘的七八年前退役、淘汰的硬件组成的，也就比 E3、E5之流强一点；内存、存储更是丐中之丐了。优化之后，服务器性能压力会少一些。其二就是烧钱的问题，本文主角之一“父子切割”策略，实测下来是烧钱大户，优化了之后成本可以降低 86%。对你没听错，降低 86%

传奇开心果编程

【现代声明式UI学与练】第9课性能优化——渲染优化、列表优化、内存优化、启动优化学完这一课，你要建立七个认知：本课核心线索：贯穿全文的核心问题：渲染优化的本质：减少不必要的函数重执行，减少不必要的 UI 描述对比。

RAF 渲染帧速通：从渲染帧到性能优化最近整理前端性能优化相关的知识，发现 requestAnimationFrame（RAF）这个 API 看着简单，但真要讲清楚它和浏览器渲染、事件循环、性能优化的关系，还是有不少细节。这篇是我自己的学习笔记，把之前搞混的点梳理一下。

移动构造与移动赋值：把资源偷过来「std::move 是什么」那一篇已经讲清楚了：它只是个类型转换，真正搬数据的是移动构造函数。这一篇换个视角，从类的实现者出发，亲手写出正确、高效的移动操作。有几个问题只有写实现时才碰得到：noexcept 为什么不是装饰、移动后源对象到底处于什么状态、移动赋值怎么处理自赋值。还有一个更隐蔽的：编译器可能压根没给你生成移动操作。

eBPF 开发实践：使用 eBPF 隐藏进程或文件信息eBPF（扩展的伯克利数据包过滤器）是 Linux 内核中的一个强大功能，可以在无需更改内核源代码或重启内核的情况下，运行、加载和更新用户定义的代码。这种功能让 eBPF 在网络和系统性能分析、数据包过滤、安全策略等方面有了广泛的应用。

shared_mutex 读写锁该不该用，以及 volatile 的三大误解「读多写少，那用读写锁肯定更快吧。」这句话是并发优化里最常见的直觉，也是最常翻车的一个。std::shared_mutex（C++17）确实做到了多读者并存、写者独占，但它的独占成本比 std::mutex 高，读者路径还要动一个共享计数器。下面先讲清该怎么用、什么时候别用，再顺手把 volatile 的三大误解拆掉。这两件事总是一起出现，因为动机都一样：想省掉那把锁。

unique_ptr 完全指南：独占所有权与零开销裸指针最大的麻烦其实不是「会忘写 delete」，而是所有权含糊不清：这段内存归谁，谁来释放，读代码的人只能猜。std::unique_ptr 把答案钉死在类型里，同一时刻只有一个 unique_ptr 拥有这块内存，要转移就必须显式写 std::move。代价几乎为零，既不比裸指针多占内存，也不比它多花时间。下面把常用接口和几个容易踩的点一起讲清。