各位大佬，给看下 mysql 语句的问题

[magicdu]

SELECT
			factor_war,
			warning_id
		FROM
			pes_warning_log_detail
		WHERE
			deptid = '517d16f720f7c6624cfb4245cc0586c0'

这个语句查询十几秒，表数据量 50 多万，还能优化吗？不加 limit

[rekulas]

索引不正常吧 单字段查询 5 千万都不会这么慢

[zpfhbyx]

建个前缀索引？

[magicdu]

 @rekulas 索引是这样的

[RRRoger]

50w 单表查询不至于这么慢吧。

确定加索引了？

[magicdu]

@RRRoger 加了，是不是加的有问题 ，看下上面的图

[rekulas]

重建索引试试？低版本 mysql 有可能索引失效 bug

另外磁盘是什么型号，测试下，大概率磁盘导致

[ch2]

对 18W 行的结果十几秒不算慢吧

[wpblank]

这个查询能查出 18w 条吗

[JasonLaw]

1. 在这张表中，大概有 18 万行的 deptid = '517d16f720f7c6624cfb4245cc0586c0'（数据库估计出来的），所以索引在这中情况下是没有太大用处的。
2. 索引虽然是顺序存储的，但是你 select 的 columns 在索引中不能找到，所以对于每个符合条件的行的主键，你都要去 primary index 中找出整行数据，但是这个时候，你会在 primary index 的东一个地方找，西一个地方找，磁盘 IO 超级严重。

当然，这只是我通过你给的一些信息判断出来的，不一定对。

[sha851092391]

索引的 Cardinality 太低了，通过 deptid 查询匹配记录数太多。
你的 SQL 匹配的记录快 20 万，不是有 limit 减少返回记录数，那就只能减少回表了，建立 deptid + factor_war + warning_id 的联合索引减少回表数看看。

[magicdu]

查询 10 万条 @wpblank

[JasonLaw]

@magicdu #3 顺便说一下，当 Cardinality 很小的情况下，建立索引是没有什么意义的。

[rekulas]

50w 总数据 即使 18w 我觉得还是偏慢了 考虑磁盘性能不足

作为对比 我测试下我这边的速度 2000w 数据表 查询 20w 记录的一个单字段 也不过才 2 秒左右

[jotpot]

18w 的结果集？ 想想都慢。磁盘要读，网络要传，客户端内存要加载，怎么不慢呢。话说你查 18w 出来干啥。

[ky11223344]

deptid 索引删了或者建个 deptid factor_war warning_id 的联合索引试试

[ikas]

这不是 sql 问题.........

[xuanbg]

把 18 万多条记录从数据库里面读出来传到你电脑上，十几秒不是很快了吗？

[securityCoding]

分页，带上上一次的游标

[SjwNo1]

覆盖索引试一下 （话说也不至于这么慢吧，磁盘出问题了吧）

[hbolive]

18 万的数据，这个时间正常。。

[rogerus]

50 万行数据，一个 key 对应 18 万行。兄弟，你确定这是 sql 而不是表结构设计的问题吗？

[mazyi]

联合索引试试，应该是回表导致变慢了

[qaqLjj]

这个没法优化，加了联合索引估计也不会变快很多，你这个查的方式有问题，查询条件匹配的结果过多，而已没有 limit