根据离散度低的字段查询优化

sdyy321 2020-05-26 05:09:46
有个表有20个字段左右,数据量在250W左右,主键是字段item_no varchar类型,创建时间和更新时间分别加了索引
执行计划 select count(1) from items


执行计划 select count(1) from items where is_batch = 0 and is_deleted = 0;
is_batch和is_deleted都是tinyint(1)类型的boolean值,离散度太低,所以没有建索引


首次执行时间在6秒左右,后续重复执行时间在1秒左右

第一次执行时间长猜测是因为全表扫将数据从磁盘加载到内存花费时间上,后续重复执行直接从内存中计算返回数据,请教如何优化第一次查询效率
1、离散度低的字段是否真的没必要加索引?
2、如果我对is_batch和is_deleted加联合索引是否合理?
3、如果加了上述联合索引如果有个查询是select count(1) from items where user_id = 10086 and is_batch = 0,并且user_id有建立索引,此时是否会走index merge导致查询慢
...全文
496 2 打赏 收藏 转发到动态 举报
写回复
用AI写文章
2 条回复
切换为时间正序
请发表友善的回复…
发表回复
ybhcolin 2020-05-30
  • 打赏
  • 举报
回复
执行时间长的原因是: 第一次执行完后 会生成对应的SQL执行计划. 第二次用相同的SQL查询,会用已有的执行计划. 而不再进行语法分析 语义分析 以及SQL执行计划选择 1: 离散值低的字段 不建议加索引 但特殊查询 可以建立位图索引 2: 对is_batch=0 and is_deleted=0加联合索引 选择性同样低. 执行计划同样会走全表扫码. 不合理 3: 可以针对user_id,is_batch 加联合索引
大雨将至 2020-05-26
  • 打赏
  • 举报
回复
如果is_batch = 0 and is_deleted = 0的数据只占很少一部分,建索引还是有效的。如果大部分,效果不大

第3点你可以explain看一下。不过user_id上有索引的话怎么也不会慢

count(1)建议改为count(*), mysql专门优化过

56,677

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧