首先, cron 分用户的,你切换系统已有用户都试试看 sudo crontab -u userName -l (替换其中的 userName),
其次可以通过 alias 重命名 wget 为其他命令

msyql 优化器会根据非常多的优化策略后, 最终决定当前使用索引是哪个, 且线上数据随时都在变, 也会影响最终实际使用的索引, 这个估计一般的 dba 都没法回答你

force index 只是测试用一下, 只对当前 sql 有效, 不影响其他语句的

第一列 type:
ref: 使用非唯一索引(即非 unique,primary key)扫描或唯一索引的前缀扫描,
index: 索引全扫描, MySQL 遍历整个索引来查询匹配的行

这个估计表明 create_time 了扫描了过多的索引,

另外我觉得纠结这些没必要, 就像上面说的, 优化你的 sql 才是关键

@zuiye111 另外, filtered 这个值范围是 0-100, 你理解的 0-1 是错的

我建议直接强制使用两种索引的情况下,分别打印一下时间耗在哪里, 一会贴出来看看
set profiling = 1;
select * from order ... force index (xxx);
show profiles;

哪来的扫全表呢, rows: 预估需要扫描的行数, 你的值在使用 create_time 索引时才 1131

@zuiye111 是百分比啊, 存储引擎返回的数据在 server 层过滤后, 剩下多少满足查询的记录数量的比例
你能贴一下当用 mchcode 索引时的 explain 记录吗, 看一下 rows 这列值

@zuiye111 很显然使用 mchcode 索引时(其`选择性`很大), 存储引擎该索引筛选出的结果集很小了啊, 而 create_time 并没有筛除任何数据啊, 你没看到用 create_time 索引时 filtered 这列为 0 吗? 你再看看用 mchcode 索引时, 这一列应该有几十了

@zuiye111 如果是这样的话, 你仍然可以用我上面那个 sql, 只不过那个联合索引改成多个单列索引或者多个较小的联合索引, 但是这个(order_property_bit & 128)=128 语句一定要移出来在业务层处理, 这个会导致很多索引用不上, 而移出这行也就要导致移出后面的 order by 到业务层面处理

首先该一下你的 sql:
select * from order
where user_id = 12345
and mchcode = '56789'
and order_state in (2,4,5)
and channel_type = 2;

然后增加索引(先不不考虑列选择性):
create index idx_xx on order (user_id, mchcode, order_state, channel_type)

最后业务层通过上面的 sql 应该查不来的结果集很小了, 手动代码处理:
(order_property_bit & 128) == 128
order by order by create_time desc LIMIT 1 OFFSET 0;

你试试

虚拟机里面装个 Windows

@OysterQAQ 是耗时增加了的意思吗

因为 artist_id 过多导致子查询不方便的话, 你就增加一下(type, create_date)这个索引吧, explain 如下
1 SIMPLE illusts ref artist_id_type_create_date_index,type_create_date_index type_create_date_index 82 const 1 100 Using index condition
1 SIMPLE user_artist_followed ref user_id_artist_id_create_date,idx_artist_id user_id_artist_id_create_date 14 const,func 1 100 Using where; Using index

另外我觉得你第一个子查询中的 order by artist_id,type,create_date 很奇怪, 能否和最后的 order by 合并呢

explain select artist_id from user_artist_followed where user_id = 53;
explain select * from illusts where artist_id in (?, ?) and type = 'illust' order by artist_id, type, create_date;
感觉拆分一下子查询好点

create index type_create_date_index
on illusts ( type, create_date);
illusts 表上的 where 条件中 artist_id 用了表达式没走联合索引, 重新建一个

show create tables;

包菜，花菜，蒜台，藕，蒜苗 都好弄