表的字段明明有index的，但为什么用不上呢？

表的字段明明有index的，但为什么用不上呢？

今天在搞维护的时候，客户说有个功能太慢了，要求改善一下。

主要逻辑的sql如下：

SELECT

(SELECT user_name

FROM user

WHERE user_id = (SELECT value

FROM data

WHERE id = history.id

AND code = 'counselor_id'

)

) AS "指导者名 "

… //其他项目

FROM user_history history

user_history表：用户履历信息，大概有 10万条左右

user表：用户信息，大概有 3万条左右

data表：用户每个履历的具体信息，每个履历有几十条数据。还有其他很多数据，总的大概几千万条。

index（索引）情况如下：

user用户的表： user_id字段

data表：id，code

咋一看sql写的也没有问题，索引按理说也是能够用上的。但为什么执行的时候特别慢呢，差不多要一个小时才能执行完。

没办法只能看Postgresql的执行计划分析了，一看大吃一惊。居然没有user的user_id没有用上索引。速度慢的原因是找到了。

那究竟是什么原因呢？所谓有果必有因，就是说肯定是哪个地方肯定有问题。

仔细比较两个表的字段，发现了一个可能的原因。就是user表的user_id是char（10），而data表的value是text类型。

发现了这个可疑点后，就改写sql，让条件的类型保持一致。

修改前sql： WHERE user_id = (SELECT value

修改后sql： WHERE user_id = (SELECT value::char(10)

修改后查看执行计划，乖乖好了，用上了index了。执行时间就1分钟多一点，客户是相当高兴哦。呵呵

也许有的人会修改为：WHERE user_id::text = (SELECT value。这种改法效率是不高的，因为先要去做user_id字段的转型动作，做了无用功。

从这个例子我们可以得到启示：

①数据设计的时候，同样意义的字段的话，类型必须保持一致。

②有很多场合由于功能的关系，类型是不一致的，如果这个时候出现效率问题，可以在 sql把数据少的一方的类型转换成数据多的一方的类型。

原文链接：https://www.f2er.com/postgresql/197204.html

猜你在找的Postgre SQL相关文章