关于一次面试问的SQL问题，至今还没有搞懂？

没有覆盖索引，走了回表；或者索引有问题，导致还是走了大量回表

数据量小的时候回表不会很慢，一般你说的这个情况导致很慢的情况有

1. 别的事务拿了锁没释放


2. 连接池耗尽了


3. 用了 select *，并且有大字段，比如 text blob 这种，但是这个比较少见

目前能先到的就这几种情况

问题描述：数据库数据很少，也有索引，查询也走索引了,数据库性能不差，为什么查询会很慢。

短时:首先排除网络问题,例如某次在ping 进出现了延迟较大,下载50万行需要超半小时,切换线路后恢复正常.

长时:回表开销大

就是回表问题？回表是会慢一点，但是会很慢吗？

数据映射回实体类也需要时间。当 HotSpot 把 JIT 编译后的机器码放在 Code Cache 里，如果 Code Cache 满了，JVM 可能停止继续编译热点方法。这个时候就会很慢。

同理可能是其他其他问题，所以要问清楚是数据查询慢还是接口慢。还是什么。

直接是SQL慢，和接口没有关系。

（帖子已被作者删除）

首先排除网络问题,其次排除索引失效问题,然后排除索引效率问题。

我刚毕业的时候面试官问的一个问题我到现在都还记得

“你知道什么是开窗函数吗？你写一个开窗函数给我看看”

我连听都没听过 ^-^

另外我们常说的数据量很小是通常基于数据行数来判断的,实际上除了关注数据行数以外更应该关注数据本身所占用的磁盘空间。

我现在也不知道 是MySQL8的窗口函数？

数据行数小，io出来的数据量很大，也不是没有可能 ^-^。

分表分库，索引，sql语句优化，查询优化，备份监控

我真遇到过这个问题 最后发现是

硬盘电压不足会导致磁头寻道困难或闪存芯片（Flash）响应迟缓，从而引发读写缓慢甚至卡顿

这个问题是咋定位到的啊。感觉放我这就是玄学问题不算bug了

为了复现这个问题我们做了三套对等环境测试，最终发现就是那套环境有问题

正好坐边上一个信息科大哥，这大哥是真神，他问我 为什么你们程序员总是不去怀疑硬件是不是故障了呢 找机房一看还真是

他遭过什么毒打我就不知道了

倒是遇到过索引字段的字符集/排序规则不一致 导致查询慢的情况

如果是 mysql 的话，假定数据库连接正常。

1. 检查表结构，desc，explain 对应的 sql 得到准确查询执行计划


2. 检查是不是聚簇索引


3. 查询字段，是否全部覆盖在索引中。


4. 如果查询多个字段过滤，只建立单字段索引，那仍旧会回到主键，得到原始数据，再过滤其他字段


5. 查询有没有排序呢，如果还有排序，分页。字段是主键，还是其他字段。


6. 这些都会有影响

这种不走索引了吧，我就遇到过类似的，旧业务升级过来的。

我这边遇到的一个，mssql的

字段中使用了函数计算，把这个字段排除之后1s之内查询6k条（全表），添加这个字段之后，查询89s

还有一个问题，超大字段，导致网络的传输，我可能给了一个字段，里面二进制，存储了50M（这个就是猜测了）