1
chenhua19940128 2021-04-14 16:08:23 +08:00
建一个 start_datetime 和 end_datetime 的联合索引?
|
2
zengxs 2021-04-14 16:15:38 +08:00
两个字段分别建一个索引不就行了
|
3
uselessVisitor 2021-04-14 16:16:14 +08:00
联合索引,但是要注意顺序。。
|
4
sue0917 OP @chenhua19940128
@zengxs @beichenhpy 联合索引或者分别建立索引感觉用处都非常有限啊,老哥们。。 比如开始结束时间都在今天前的,和开始结束时间都在今天后的,分别有 200 万条数据。 单独建开始时间或结束时间索引,都扫描出了 200 万条以上的主键 id 去回表?,基本是无效索引了。。 搞个联合索引,好处可能是可以通过索引确实找到了主键 id 去回表,不过依然需要连续比对几百万条数据,开销依然很大 |
5
uselessVisitor 2021-04-14 16:34:38 +08:00
@sue0917 #4 数据太多确实无效索引。。应该加限制条件的吧。。
|
6
sue0917 OP @beichenhpy 看看其他老哥们有方案没有,确实有点打脑壳。,。
|
7
uselessVisitor 2021-04-14 17:27:28 +08:00
@sue0917 #6 话说 int 类型字段的索引,not in 会走索引吗?我测了一下 type=range 。。网上都说不走索引。。range 好像也算走了索引吧
|
8
billlee 2021-04-14 21:06:38 +08:00
换个思路,加个状态字段,然后用定时器维护这个字段
|
9
sue0917 OP |
11
RangerWolf 2021-04-15 09:55:43 +08:00
@beichenhpy 我个人理解,是不是走索引要看成本优化器的预估。
如果优化器发现需要扫描的数据非常多,比如超过 20% 或者 三分之一,类似这种,就不会走索引。 你还可以试试看,比如网上经常说的 性别 字段的索引问题。 比如 10 条记录,1 个男的 9 个女的,查询条件分别测试 gender = m 与 gender != m 在我的环境( MySQL 5.7 ) 索引的使用情况是不一样的 |
13
dongtingyue 2021-04-15 10:08:24 +08:00
具体语句丢出来。筛选后数据有那么多你说会有啥办法,走索引只是说能减少时间而已。
|
14
sue0917 OP @dongtingyue 关键是走不上索引,或者说没有找到合适的索引怎么建。,。
现在就是来问问,索引怎么建才比较好。,。 |
15
Cy1 2021-04-15 17:59:39 +08:00
@sue0917 除非索引覆盖,不然回表肯定是避免不了
建联合索引,(start_datetime asc, end_datetime desc) 基本上数据分布就很符合你这个需求吧? 这个顺序比对的次数应该不会比实际返回的行数大很多? 如果优化器决定不走索引,你又想要用索引,那就自己手动标明使用的索引就行了。 |