迫于水平不够， MySQL 查询语句出现问题，例如：使用 LIMIT 速度变慢，使用 IN 少数据

[la2la]

这几天协助开发接口，使用 MySQL 查询出现问题

第一个问题使用 ORDER BY + LIMIT 查询变慢

这个问题猜测是索引问题，查阅资料使用 force index 解决

# DEV_INFO 表数据量 5 千万级别，DEV_ID 唯一索引，C_TIME 普通索引
sql> SELECT DEV_INFO FROM DEVICE_INFO WHERE DEV_ID = "500000022" ORDER BY C_TIME DESC limit 1;
结果：太慢了 直接 timeout 了

sql> SELECT DEV_INFO FROM DEVICE_INFO FORCE INDEX(DEV_ID) WHERE DEV_ID = "500000022" ORDER BY C_TIME DESC limit 1;
结果：1 row retrieved starting from 1 in 106 ms (execution: 94 ms, fetching: 12 ms)

第二个问题很奇怪，目前没有想通

明明应该能查出 13 条数据，结果只有 12 条记录，我确定少的那个 ID 82985 数据库中存在

# (里面有 13 个 ID)
sql> select * from POINT where ID in (82925,82909,82905,82901,82929,82981,82979,82977,82975,82983,92985,83013,83005);
结果：12 rows retrieved starting from 1 in 87 ms (execution: 55 ms, fetching: 32 ms)

sql> select * from POINT WHERE ID=82985;
结果：1 row retrieved starting from 1 in 83 ms (execution: 58 ms, fetching: 25 ms)

我想到这些问题应该都是 MySQL 执行的问题

所以 我想系统的学习一下 sql 深一点的知识，有没有推荐的 教程或者书籍

啊 第二个问题，确实需要我配个眼镜

第一个，DEV_ID 不是唯一索引，我写错了，就是普通索引，所以会查出多条数据

[sagaxu]

你需要治疗近视眼

[telami]

第一个问题，搞不太懂都用 id 查了，为啥还要 order by limit 1，难道会查出来多条么

第二个问题，附议楼上。

[lecoo]

你 13 个 ID 里就没有 82985。

[zhuangjia]

82985 确实不在 13 个 ID 里面。附议上三楼

[RubyJack]

1L 笑尿了哈哈哈哈哈哈

[dilu]

不要强制使用索引，除非你已经 diao 到爆炸

[akira]

遇到性能问题，先上 explain，大部分性能问题都能通过这个确认

[sagaxu]

把 DEV_ID 索引去掉，建一个(DEV_ID, C_TIME DESC)联合索引

[la2la]

@akira explain 了下，加了 limit ref 变成了 index，但是不清楚为啥会变

[la2la]

@sagaxu 这个没有权限