做技术这些年我最常被问的一句话就是“能不能帮我优化一下”。这句话的范围可以小到把电脑开机从两分钟缩到三十秒也可以大到把一个几百行的 SQL 从跑十分钟压到跑十秒甚至还能落到游戏画面帧率、模型训练成本这些完全不同的场景。“优化”这个词看起来通用得不像话但真正上手之后你会发现所有有效的优化背后都有一个共同的逻辑先找到真正的瓶颈再做最少的改动拿数据验证改动到底有没有用。这篇文章我想把自己在不同场景里做优化的经验拆开来讲从 Windows 系统日常卡顿到慢 SQL、动态规划、Unity 渲染再到借助豆包这类 AI 工具来辅助优化给你一套可以直接参考的实操思路。无论你是普通用户想解决电脑卡顿还是开发者想压榨代码性能这篇都值得往下看。“更好的优化”是什么我的理解是在不动摇稳定性和原有功能的前提下用更少的资源达成同样的目标或者用同样的资源获得更高的收益。优化不是越激进越好也不是改动越多越好而是要在约束条件里找到那个最划算的平衡点。下面这些章节就是我在不同约束条件下做优化的真实记录。1. 优化这件事先回答三个问题再动手1.1 你的瓶颈到底在哪很多人一上来就开任务管理器看到哪个进程顺眼就关哪个这种操作纯属碰运气。做系统优化也好做代码优化也罢第一步永远是定位瓶颈。判断瓶颈我用过最实用的办法是“替代法”把资源换掉、把环节去掉看看效果变化有多大。比如电脑卡顿你先问自己是开机慢还是运行某些软件时慢开机慢大概率是启动项太多运行软件慢可能是内存不够后台常驻杀毒工具吃满 CPU或者硬盘碎片堆积导致随机读写变慢。如果只给你十分钟你应该去观察性能监视器里的 CPU、内存、磁盘这三个指标——它们几乎能解释 90% 的日常卡顿问题。在代码和 SQL 的优化里同样的逻辑完全成立。一条 SQL 慢先看执行计划确认是全表扫描还是走了索引一段算法慢先做性能剖析Profiling确认时间耗在循环里还是耗在 I/O 上。跳过“定位”直接“优化”十有八九会做无用功。1.2 优化本质上是在做取舍有句话说得很实在优化不是在“好”和“坏”之间选而是把“好”从一个维度挪到另一个维度。我想把开机速度从一分钟提到十秒代价可能是关闭了一些有价值的安全防护想把 SQL 从全表扫描改成走索引代价是索引会占磁盘空间、写操作会变慢想把游戏帧率从 60 提到 120代价通常是画质下降。所以做优化之前我建议你先把“指标”和“代价”写下来。普通用户优化电脑优先保的是稳定性和数据安全开发者优化代码优先保的是正确性和可维护性游戏玩家优化体验优先保的是流畅度和画面观感的平衡。没有想清楚要什么就不要动手这是我一贯的做法。1.3 没有基线就没有优化听起来像废话但到现在我还会踩这个坑改了一堆东西结果忘了记录改动前的数据后面想判断哪一步真的有效时只能凭感觉猜。后来我给自己定了一条铁律——动手之前先把“基线”记录好开机用了多少秒SQL 跑了多少毫秒游戏平均帧率是多少内存占用百分比是多少统统记在备忘录里。改一个变量测一次效果才能确认每一处改动到底值不值。2. 系统层面的优化不重装系统先把这三块处理干净2.1 Windows 10/11 日常优化的正确顺序网上一搜“Win10 优化”结果一半是让你装各种卫士一半是给你发一堆注册表脚本说实话这两类我都不推荐。我自己的优化顺序很简单从上到下处理四件事。第一个是启动项。按下 Ctrl Shift Esc 打开任务管理器切到“启动”标签页把不需要开机自启的程序挨个禁用。注意一个关键区别杀毒软件尽量保留显卡驱动控制面板尽量保留而那些下载工具、播放器、聊天工具的自启动图标禁用掉一点不影响日常使用。禁用前看看“启动影响”那一列优先处理标“高”的项。第二个是视觉效果。在“系统”设置里搜索“性能”选择“调整为最佳性能”把所有动画、阴影、透明效果关掉。这招对老电脑立竿见影但对新电脑影响不大因为现代 CPU 处理这点动画根本不费劲。如果你内存只有 8GB那么关掉动画释放出来的资源还是很可观的。第三个是电源计划。笔记本用户尤其注意默认的“均衡”方案会把 CPU 频率降下来省电如果你经常觉得电脑反应慢半拍切到“高性能”模式试试代价是风扇转速提高、续航缩短。这是典型的取舍场景看你是想要流畅还是想要续航。第四个才是外部工具。Windows Utility也就是社区里常说的 WinUtil 一键脚本这类一键优化工具能做很多事清理预装应用、关闭遥测、调整服务状态确实省事。但我的建议是任何一键脚本都不要无脑跑全量先用记事本打开脚本看看每一条命令在干嘛至少把涉及注册表备份和系统还原点的选项打开。跑完脚本再做一次基线测试确认优化效果是真的。这里提一个我踩过的冷门坑西门子博图TIA Portal这类工业软件在开启“优化的块访问”之后能显著提高 PLC 程序的读写效率但如果你之前写的代码里有依赖传统块布局的指令改成优化模式后这些指令会直接报“不能修改”的错。所以说系统级工具也好专业工程软件也罢优化前一定要确认兼容性别为了提速把工作流弄崩了。2.2 Edge 浏览器变慢的真凶不在浏览器本身被要求帮忙优化电脑的人里十个有八个会顺手抱怨一句“我的 Edge 怎么越用越卡。”我帮人看过很多次结论都差不多——浏览器本身没毛病是标签页、扩展和后台服务在拖后腿。Edge 的提速操作分三步。第一步开启“睡眠标签页”在设置里把闲置标签页进入睡眠的时间调短比如 5 分钟。这个功能能把那些长期挂着但很少看的页面冻结起来大幅降低内存占用。第二步卸载不常用的扩展。很多人觉得扩展没几个但每个扩展都是一个独立进程有的扩展还会在后台偷偷做数据上报占用比你想象中大得多。第三步把 Edge 的“启动增强”关掉。这个选项是让浏览器在后台预启动看似开网页更快但它会常驻好几个进程内存本来就不宽裕的机器就别开了。另外说一句容易被忽略的传递优化缓存。如果你在系统设置里看到“传递优化”占了几个 GB 的存储空间别慌这是 Windows 用 P2P 方式分发系统更新时留下的缓存本质上是一个下载缓存文件。删掉它不会影响系统稳定性只是下次更新需要重新下载一部分数据。操作路径在“设置—系统—存储—清理临时文件”勾选“传递优化”再清掉即可。如果你的网络环境本身就不稳定建议保留它至少下次更新不用全量下载。3. 代码与算法优化别小看一行循环的改动3.1 一个质数判断函数的“进化史”代码优化最基础也最直观的例子我特别喜欢拿“判断一个数是不是质数”来讲。第一次写的人往往长这样bool isPrime(long long n) { for (long long i 2; i n; i) { if (n % i 0) return false; } return true; }这段代码逻辑完全正确但效率极低从 2 一直试到 n-1时间复杂度 O(n)。优化第一步把循环上限缩到sqrt(n)理由是如果 n 是合数那么它一定有一个因数不大于它的平方根。复杂度立刻变成 O(√n)。再进一步利用“质数一定落在 6k±1 上”这个规律。理由很简单大于 3 的数如果能被 2 整除必然不是质数能被 3 整除也必然不是质数而所有整数除以 6 的余数只有 0、1、2、3、4、5其中余数为 0、2、3、4 的都已经被 2 或 3 整除掉了只可能余 1 或 5。所以循环可以从 i5 开始每次加 6判断 i 和 i2。这一步又把计算量减少到原来的约三分之一。bool isPrime(long long n) { if (n 3) return n 1; if (n % 2 0 || n % 3 0) return false; for (long long i 5; i * i n; i 6) { if (n % i 0 || n % (i 2) 0) return false; } return true; }如果 n 是 64 位长整数上面这套仍然不够快这时候我会直接上 Miller-Rabin 素性测试。它的原理基于费马小定理如果 n 是质数那么对于任意 a且 gcd(a,n)1都有 a^(n-1) ≡ 1 (mod n)。利用这个性质加上二次探测定理来排除伪素数可以在 O(k·log³n) 的复杂度下完成判断k 次测试就能把错误率压到几乎可以忽略。做竞赛或做加密相关工作时Miller-Rabin 几乎是必经之路。3.2 动态规划的优化不只是“换一种写法”在算法领域“单调队列优化 DP”和“四边形不等式优化 DP”这两类高频词本质上都是在干同一件事把状态转移方程里不必要的重复计算剪掉。单调队列优化的典型场景是这样一种状态转移dp[i] max(dp[j] w(j, i))其中 j 的取值落在一个随 i 移动的滑动窗口内。朴素做法是每个 i 都把窗口里的 j 全部扫一遍复杂度 O(n·k)优化做法是把窗口内的候选 j 放进单调队列队首就是最优值每个元素最多进出队列一次总复杂度降到 O(n)。这和你手工维护一堆数据时“先排个序再依次取”的思路是一模一样的——把无序的暴力比较变成有序的线性操作。四边形不等式优化稍微难理解一些但它的触发条件很明确当最优决策点随着 DP 阶段的推进呈现单调性时就可以在计算时缩小决策点的枚举范围。最经典的例子是最优二叉搜索树和石子合并问题原本的 O(n³) 复杂度可以压到 O(n²)。很多人学这类优化时容易卡住我的建议是别上来直接看证明先把“决策单调性”这个直觉建立起来画一张表格把每个阶段的最优决策点标出来看到它们逐渐右移你就能理解四边形不等式到底省掉了哪些枚举。3.3 慢 SQL 优化先看执行计划再谈索引做过后端的人几乎都会被一条慢 SQL 折磨过。我处理慢 SQL 的流程非常固定第一步打开慢查询日志定位具体的 SQL第二步执行 EXPLAIN看它到底慢在哪第三步逐项排查 Execution Plan 里几个关键字段。type字段的值里ALL意味着全表扫描range和ref说明用上了索引范围或等值查询const是最理想的主键或唯一索引查找。rows是个估算值表示扫描了多少行如果这个数字大得离谱优先考虑加索引。Extra里如果出现Using filesort或Using temporary说明数据库额外做了排序或建临时表这往往是排序字段缺索引或查询本身就写得不合理。我举一个典型的例子。某条查询写了WHERE DATE(create_time) 2024-01-01无论怎么加索引都全表扫描原因是DATE()这种函数包裹住字段后索引就失效了。改成WHERE create_time 2024-01-01 AND create_time 2024-01-02数据库直接走范围索引查询时间从 800ms 降到 30ms。类似的问题还有隐式类型转换字段是字符串你传入数字索引一样会失效。还有一类大分页问题LIMIT 1000000, 20这种写法数据库会先把前面一百万行全部扫出来扔掉再取 20 条。优化方式是“延迟关联”先通过覆盖索引查到主键再用主键回表取完整数据。SQL 改写本身不难难的是养成“先看执行计划再改”的习惯。4. 数据与存储优化小文件、并行和向量数据库的坑与招4.1 Hive 小文件问题一个让集群变慢的“慢性病”数据工程师一定对小文件深有感触几万个几十 KB 的小文件分布在 HDFS 上先不说查询时 NameNode 光处理元数据就要累死MapReduce 拉起的 Map Task 数量也会多到失控。文件越小、数量越多每次任务启动的固定开销就越大整个集群就像被堵了一条路的车流一样。小文件产生的来源我总结为三个一是动态分区插入时每个分区产生的文件数量不受控制二是过度调大 Reduce 数量三是数据表本身的源文件就没合并过。对应的优化方案也直接开启hive.merge.mapfiles和hive.merge.mapredfiles让 Map 阶段和 Reduce 阶段结束后自动合并小文件用INSERT OVERWRITE重写一遍目标表让数据重新落盘时按合理大小聚拢同时控制hive.exec.max.dynamic.partitions避免动态分区数量爆炸。判断“文件数量是否合理”我一般看两个指标目标文件大小是否接近 HDFS 默认块大小128MB单目录文件数量是否超过几百个。把这两个指标控制好小文件问题就解决了一大半。4.2 并行 SQL 不是万能药要分场景开很多人听到“并行查询”就觉得能变快但实际跑下来可能还不如单线程。原因在于并行执行有固定的调度和通信开销小查询触发并行时准备并行执行计划的成本已经超过了查询本身。我自己的经验是单条 SQL 扫描的数据量在亿级以上或者要做大量聚合计算时开并行才有明显收益几百毫秒就能跑完的查询老老实实保持默认设置。以 PostgreSQL 为例调整max_parallel_workers_per_gather可以控制一个查询最多能用几个并行 worker配合parallel_setup_cost和parallel_tuple_cost两个成本参数能影响优化器是否选择并行计划。如果你发现一条 SQL 明明数据量很大却还是没走并行可以先把parallel_setup_cost调低一点让优化器更“倾向”选并行路径。而在 Oracle 里/* PARALLEL(表名, 4) */这种 hint 能强制指定并行度但前提是硬件资源确实有富余否则并行线程之间抢资源只会互相拖慢。4.3 向量数据库集成与优化的几个真实注意点最近做 AI 应用的人绕不开向量数据库比如 FAISS、Milvus 这类。向量检索的优化我踩过三个坑先说最常被忽略的向量归一化。如果业务里算的是余弦相似度而向量没有归一化那么嵌入向量模长不一致会直接影响检索精度。做法是在写入之前统一做 L2 归一化精度立刻上一个台阶。索引类型的选择也很关键。数据量大的场景用 HNSW核心参数是M每个节点的最大连接数和efConstruction构建时的候选池大小。M越大召回越准但内存占用和构建时间也越大efConstruction同理建索引更慢但质量更好。建议先从小到大调参结合召回率评估指标拍板而不是一上来就拉满。批量写入时批次大小控制在 1000 到 5000 条之间比较稳定太小吞吐上不去太大容易触发内存峰值。5. 游戏与图形优化帧率与画面从来都是“换”出来的5.1 Unity 游戏优化的两个核心阵地做 Unity 项目优化我首先看两个东西DrawCall绘制调用数和资源占用。DrawCall 是 CPU 向 GPU 发送渲染指令的次数一次指令之间如果频繁切换材质和贴图CPU 就会成为瓶颈帧率上不去。常规手段是动态合批、静态合批和 Texture Atlas图集。把零散贴图打包到一张大图集里相同材质的物体就能在一次 DrawCall 内绘制完。这是省时省力的优化方式风险也很小我建议新手做项目优化从这里入手。另一个阵地是资源加载。运行时频繁加载和卸载 Prefab或者没有任何对象池会造成严重的内存抖动和 GC 卡顿。用对象池复用子弹、敌人这类高频生成销毁的物体对移动端帧率的提升几乎是立竿见影的。我用 Unity Profiler 检查过很多项目那些帧率不稳定但 CPU 占用不高的多半是 GC 在捣乱。移动端项目的纹理压缩格式也需要专门处理iOS 常用 ASTCAndroid 上 ETC2 兼容性更好直接压成对应格式内存占用能降好几档。GPU 逐帧生成的画面纹理带宽是很大的开销选对压缩格式相当于从源头减负。5.2 N 卡驱动面板与游戏优化的正确姿势台式机游戏卡顿很多人期待靠显卡驱动面板的“全局设置”解决但这里面的坑也不少。先说“电源管理模式”NVIDIA 控制面板里有“最高性能优先”和“优化功耗”两个选项。选“最高性能优先”确实能让 GPU 全速跑但代价是功耗和发热双双拉满笔记本用户会明显感觉风扇狂转、续航骤降。笔记本我建议默认不动台式机想要极限帧率再打开。垂直同步要不要关取决于你有没有 G-Sync / FreeSync 显示器。如果显示器支持可变刷新率建议在控制面板打开垂直同步配合 G-Sync 能避免画面撕裂又不会掉帧如果显示器就是普通的 60Hz 屏开了垂直同步等同于把帧率锁 60显卡性能再高也发挥不出来那就可以考虑关闭。还有“低延迟模式”设置成“超高”能减少输入延迟但前提是 GPU 占用率没有顶满否则它会反而让帧率波动更明显。如果你实在摸不准这些参数GeForce Experience 的一键优化可以作为起点它会根据你的 CPU、GPU 和内存自动配置画质。它给出的不是极限画质但大概率是这台机器能稳住的帧率最合理的组合。把它的设置当成基线再手动微调阴影和抗锯齿比从头瞎试要高效。5.3 移动端性能优化的核心不只是看 FPS手游性能优化和 PC 端不同移动端发热降频的影响远大于参数微调。我优化移动端项目时除了帧率还会记录设备温度、CPU 频率、Jank 次数掉帧卡顿次数。一款游戏如果在 iPhone 和 Android 低端机上都能稳住 30 帧但每隔十几秒就出现一次长卡顿用户感知会比“稳定 25 帧”还差。应对策略主要有两层。第一层是资源层面动态合批、纹理压缩、音频用压缩格式、热更包瘦身。第二层是代码层面避免每帧分配新对象避免在 Update 里做字符串拼接把高频逻辑移到对象池里。很多时候优化的感觉就像在做减法——减少每帧要做的事帧率自己会回来。6. 借助 AI 工具做优化豆包指令和 Prompt 的正确用法6.1 用豆包优化电脑指令要这样写现在很多朋友遇到电脑卡顿第一个想到的是问豆包这类 AI 助手“怎么优化电脑”。你直接问它能给你一堆通用建议但通用建议往往不解决你机器上的具体问题。想让它真正帮上忙Prompt 里要包含三个信息你的硬件配置、你遇到的具体场景、你已经尝试过的方法。我常用的指令模板是我的电脑是 Windows 11CPU 是 i5-12400内存 16G硬盘是 SSD最近开机要 1 分半 运行浏览器时内存占用经常到 80% 以上。我试过关了几次启动项但效果不明显。 请按“先排查瓶颈、再给步骤”的方式给出针对性优化建议每步说明目的和风险。加粗划线的地方就是让 AI 回答从“泛泛而谈”变“对症下药”的三个关键配置、场景、已有尝试。给它这些约束它才能帮你判断是内存不足、启动项残留还是浏览器扩展拖累内存。给 AI 一个输出结构先排查再给步骤也可以避免它把一堆建议平铺开来你根本不知道先做哪个。6.2 关键词提炼与 GEO 优化里的 Prompt 设计如果你做过内容运营大概率听过 GEO生成式引擎优化Generative Engine Optimization。它的核心是让 AI 搜索引擎在回答用户问题时更愿意引用你的内容。做 GEO 的第一步也是最关键的一步是提取行业核心关键词这一步本身也可以用 AI 来优化。我给内容团队用的是这样一个 Prompt你是资深内容策略师。请基于“工业自动化”这个核心主题扩展出 50 个长尾关键词 要求覆盖产品词、场景词、痛点词、对比词A和B的区别、时间词2025年/最新。 每个关键词后面标注用户搜索意图找产品/找教程/做对比。最后按意图分类输出表格。这个 Prompt 有三个设计点数字约束50 个避免 AI 偷懒只给十个、意图标注让关键词可直接指导内容选题、分类输出后面排版和选题会很省事。好的 Prompt 不是一句话“帮我找关键词”而是把目标、约束、输出格式一次性限定清楚。这套逻辑放到向量数据库优化、慢 SQL 场景也适用——你描述得越精确AI 给你的结果越接近可用状态。6.3 ComfyUI 工作流优化和样本效率优化经常用 ComfyUI 做 AI 绘画的朋友可能遇到过工作流跑不动、显存爆掉的情况。ComfyUI 的优化方向通常是三个一是尽量复用缓存节点不重跑前面没改动的模块这个在界面里勾选“缓存已执行的部分”就行二是降低显存占用低显存机器上加--lowvram参数启动让模型计算分段进行速度变慢但不会崩三是合并重复流程把多个采样器串联的工作流精简成单链路能大幅减少中间节点保存大张量图的开销。样本效率优化则是训练侧的事。当训练数据量有限时与其花钱买更多数据不如先做好数据增强。图像领域是随机裁剪、翻转、色彩增强文本领域是同义替换、回译。结合预训练模型微调一组高质量增强数据往往能带来比堆量更多轮训练更明显的提升。这类优化的逻辑和我前面强调的完全一致先找最影响结果的变量再投入最少的成本去改动它。最后分享一点个人经验做优化这些年我最深刻的体会是好的优化者不是一个“什么都懂”的人而是一个“什么都不乱动”的人。你看到的那些漂亮数据背后都有一条条被我亲手记录的基线和一次次只改一个变量的测试。很多用户拿着别人的一键脚本跑完电脑确实快了几天过阵子又卡回去了就是因为不知道每一步操作到底改了什么。你会发现不管是用户电脑、数据库、Unity 工程还是 AI 工作流优化的本质永远是这四步定位瓶颈、设计测量、最小改动、验证效果。把这四步内化成习惯你遇到再复杂的优化需求也不会慌。最后再送一个小技巧每次优化完顺手把你做过的操作和测得的数据写在一个文本文件里。这个简单的习惯会在下一次系统重装或项目复盘时救你一命。