邯郸公司数据库慢查询，先从这三处定位

前几天邯郸一家做零售的公司来问，系统越用越慢怎么办？我一般这么答：先看数据库，多半在那儿。系统刚上线时很快，跑一年就慢了，数据量涨是主要原因。但也不是所有慢都因为数据多，得先分清是哪一类。技术项目验收后交付完整源码，含 1 年免费维护。我们做项目按 Scrum 迭代，每 2 周交付一个可用版本。

索引有没有生效

索引是第一个要看的地方。建了索引不等于用上了，写法不对它就不生效。比如在字段上做函数运算，索引直接就废了。查看执行计划能看出来。照我们的惯例，第一眼就看这一处。丛台区那边有个项目，加了一个索引，查询从好几秒降到 100 毫秒以内。

索引也不是越多越好。每多一个索引，写入就慢一分。尤其是写入频繁的表，索引要克制。我们把不常用的索引清过一轮，写入速度明显改善。建之前先想清楚会怎么查，比事后补更省事。

查询条件怎么写

写法影响很大。模糊匹配放在前面、一次查全表，都是常见的写法问题。这类问题不用改结构，改语句就行。落到真实项目里，一般先看最慢的那几条语句。改语句是成本最低的一步。永年有家商户改了 2 条语句，页面响应快了一半。

还要看是不是取多了数据。只用一个字段却把整行都查出来，白白增加传输。该限定的字段就限定，该分页的就分页。这些小习惯攒起来，差别不小。

数据量涨到多大了

前两处都没问题，就看数据量。单表超过 1000 万行，很多操作的耗时都会明显上升。这时候要考虑分区或者归档。历史数据用不到的，该清就清。邯郸做零售和批发的企业，订单表涨得最快，建议按年归档。

常见问题

慢查询日志怎么开

多数数据库都自带这个功能，开启后把阈值调到合适的时间即可。

加索引会有副作用吗

会，写入会稍慢、占更多空间。所以要按实际查询场景来加。

归档的数据放哪儿

可以导到备用库或者冷存储，需要时再查。别直接删掉。

邯郸的公司排查数据库慢，按索引、语句、数据量三处依次看。定位准了，改起来花不了多少工夫。说说你用的数据库类型和当前数据量，我就能判断个七七八八。你要是想听实话，信服无限邯郸这边可以先帮你判断这件事该不该做。