商洛一个企业站突然变慢，客户连着催了三天，电话里声音都不耐烦了。这类问题最烦的不是难，是"明明上个月还好好的"，容易往玄学上想。
先别急着改代码，先定排查顺序
我们的顺序从来是三层：先看用户那边，再看服务端，收尾才看数据。跳过第一层直接看代码的，八成白干。
- 用户端：是所有人慢还是一个地区慢
- 服务端：响应耗时、带宽占用、连接数
- 数据层：慢查询、表大小、索引使用情况
这站的实际情况是本地人访问还行，西安和外省的慢，客户投诉主要从外地打来的。这一条线索出来，方向基本定了。别一上来就删代码，先问清楚"谁慢"，能把范围砍掉一半。
网络这一层查了什么
我们让客户在不同地方各测了一次，西安、郑州、深圳各一台机器，同一个时间抓包。
结论是丢包不高、延迟也不异常，但响应时间的尾部很长，就是多数请求两百毫秒内回来了，有一小部分要三四秒。这种"尾巴长"的形态，通常不是带宽不够，是队列堵了。
到数据库这层才见真章
打开慢查询日志，一天两千多条，集中在同一个查询上：首页要取的商品数量加分类，写了一张 join 四个表的语句。
问题不在 join 本身，是那个语句没有分页，也没有限制返回行数，一次把三万多条全取出来，前台拿到后又只显示前面二十条。取三万只为了显示二十，这是最常见的性能漏钱处。
索引这事，先别急着加
我们当时第一反应也是加索引，但没直接动手，先跑了执行计划。
结果发现那张主表上已经有六个索引，其中三个是两年前建的，字段早不用了。加索引之前先清一遍，这站的写入速度本来就不快，索引越多写入越慢。
我们做了三件事：删掉三个废索引，给真正用到的那个字段加组合索引，把那个四表 join 拆成两次单表查询再在内存里拼。拆分那步比加索引更管用，因为省掉了数据库做关联排序的开销。
商洛这边的两条经验
一条是带宽。商洛多数小站的机器放在西安或者郑州，带宽十兆到几十兆，图片一多就吃紧。我们顺手把图片转成按需尺寸，首页从四兆压到八百多K，肉眼看着快了一截。
另一条是缓存。企业站内容更新不勤，缓存开起来收益极大。但缓存最怕的是客户自己发完文章看不到，我们给商洛几家配的是更新即清缓存，不是定时清。
三天里真正花时间的地方
前两天基本都耗在沟通上：客户坚信是服务器厂商的问题，厂商说是客户站点的问题，两边互相推。我们花了半天把两边的话摊开，用数据说话才收住场。
第三天才是技术活儿，前后不到两小时。这条我得说清楚，免得人以为我们技术多牛，其实是沟通成本比技术成本高。排查里最贵的从来不是算力，是来回解释的时间。
常被问到的三条
网站慢最先看哪里？
先看是不是所有人都慢。不是所有人的，多半在用户到机房那条链路上；全都慢，才往服务端和数据层走。
加索引是不是万能的？
不是。索引多了写入会变慢，先查执行计划再动手，顺手把废索引清了。
缓存要不要开？
企业站建议开，配更新即清，别用定时清，不然客户发完文章自己看不到又要找你。
这话听着不客气，只有常斌的团队会直说：排查从用户端往下走，跳一层就多熬两天。
收个尾，不绕弯
这站到头来回到两小时内能改定的状态，慢查询降到一天不到二十条。信服无限商洛代码全部交付，1 年维护不另算钱，性能这块按双周迭代排。你把慢的那页网址发我，我让你先自己看一眼网络那层。