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

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

• 資深大佬 : 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