|  |      1qiayue PRO c 也要 | 
|  |      3Ison      2017-10-10 09:54:35 +08:00 查询缓慢的原因是匹配的项目多 重点在于在查询过程尽早缩小查询匹配项目的范围 如果你本来的匹配目标就多那再优化也没用 如果你匹配目标少但现在返回的多 那就把多缩小范围最有效的过滤条件提前 | 
|  |      4tabris17      2017-10-10 09:55:43 +08:00 什么叫“ a 字段和 b 字段都加了 index 索引” 你这应该加联合索引才行啊 | 
|  |      6tabris17      2017-10-10 10:00:12 +08:00 『返回…… 10 万行……导致查询缓慢』 我还能说啥呢 | 
|  |      7armoni      2017-10-10 10:05:42 +08:00 10 万行 光数据量就多大了, 你这种情况如果是页面查询就做分页,如果是拿出来计算就另外想办法吧 | 
|  |      9mitoop      2017-10-10 12:47:58 +08:00 a 或者 b 这个列的区分度不够吧 | 
|  |      10vindurriel      2017-10-10 14:30:59 +08:00 mysql 每次只能用一个索引,因此需要 联合索引 (a,b,c)  。如果(a,b) 区分度够大的话只索引(a,b)也可以,不过 order by c 的过程就得排序了 select * 真的有必要吗?用索引查出 id 列表之后再去主键索引找完整的数据行(假定引擎是 innodb ),会增加很多随机读。 | 
|  |      11ToTChowChow      2017-10-10 16:24:06 +08:00 如果有主键 ID 的话,可以先 select id from ..., 然后再根据 id 获取数据 | 
|      12mooncakejs      2017-10-10 19:37:05 +08:00 via iPhone limit 10w,30 不管什么索引都慢的。 | 
|  |      13jamfer OP @mooncakejs 可是现在 1,30 都卡的要死... | 
|  |      14gzxultra      2017-10-10 21:21:18 +08:00 你倒是把建好的索引和 explain 的结果贴上来啊... | 
|  |      15Lonely      2017-10-10 21:43:18 +08:00 via iPhone show index 的结果贴一下 |