宜宾数据库慢查询怎么治？我建议先加索引

宜宾一家仓储服务公司的后台点一下要等半天，老板以为是服务器不够快。我抓了慢日志，一条没建索引的 SQL 跑了 40 秒。数据库慢这件事，先加索引，别急着加机器。

先量出慢在哪一条

慢日志会按耗时把语句排好序，前十条基本能看出问题。这一条跑了 40 秒，扫描的行数是正常语句的几万倍。缺索引的表一多，数据库就会把全表翻一遍再筛。表不大的时候看不出来，表一大就全暴露。

索引不是越多越好

给写入频繁的表加索引会拖慢插入。订单表每天进几万行，加四个索引，写入时间就明显上去了。索引建在真正用来筛选的字段上，写多查少的字段要慎。建完拿慢日志复测一遍，别凭感觉。

宜宾港的仓储和货代企业，一天进出几千条运单，订单和库存两张表都在猛写。这两张表加索引要挑着来，全加等于没加。

十年前的老库怎么动

老库的字段命名是拼音首字母，表关系靠程序员记。我们做这类项目第一步不是重构，是给每张表补一份说明，写在代码里。说明没写就重构，改到一半自己也不知道动了什么。这份说明还有一个用处：新同事接手时照着看，不用挨个问人。十年老库里真正还在跑的表可能只有五张，剩下的要不要留，一起定。

• 给每张表写一句话说明，跟着代码走
• 大表先归档和分区，再谈加机器
• 备份跑通一次恢复，再动表结构

我们交付过 100 多个商业 APP，慢查询这类问题是交付前的必查项。自动化测试加代码审查再过一道安全审计，交付代码通过质量门禁。定制项目按双周迭代交付可用版本，一版一版看。

数据库优化的常见疑问

加索引能解决多少？

慢日志前十条里有一半是索引问题，就能解决一大半。具体占比得实测，看不到慢日志谁也算不准。

要不要直接换更快的数据库？

先别换。加索引和改查询能把大部分问题解决，换数据库是最后一步，代价大得多。

这项排查要多久？

取慢日志半天，出报告一天。改完再复测一轮，整套走完通常一周。

先加索引，再谈机器

宜宾港的船期、宜宾东站的车次一改，线上那几个系统的访问量跟着变。

宜宾信服无限接这类数据库调优，先要一段慢日志。40 秒和 4 秒之间的差别，很多时候只是一条索引。把慢日志导出来发来，我们先看前十条。