1 、select * from info where a = 1 and c = 200
multi 索引总长度为 15 字节，可以用到 multi 索引的 a 字段（ 5 字节），不能用到 c 字段（不满足最左前缀匹配原则）；
icp 开启的情况下，可以把 c=200 的条件下推到引擎层过滤，可以减少回表次数
2 、select * from info where a > 1 and b < 200
首先，即使使用索引+icp ，也是和场景 1 相同，只能使用 multi 中 a 字段的索引，b<200 作为条件下推。
实际上，根据索引中 a 字段的基数来判断，只有在使用索引能大量减少扫描的行时才会使用索引+下推；假设表中有 10W 行数据，a 字段的取值范围是 1-100 ，在数据分布均匀的情况下，a 字段的基数为 1000 ，当你使用 a>1 and b<200 时，使用 multi 索引查询基本是全索引扫描+icp ，然后回表；全索引扫描代价与全表扫描差别不大；而当你使用 a>95 and b<200 时，通过 multi 索引的 a 字段可以过滤 95%的行，代价肯定比全表低。

我也推荐#1 的方法

usmile

生个娃 每个月两千免税额度，不比你考证来抵扣个税香吗

现在 mysql 使用的磁盘都说 ssd ，亿级数据，只要使用姿势正确完全没有问题
建议先优化原 db
前面也有老哥说了，不清楚你的数据结构，使用场景是这些确实不好推荐

好玩 IllllIllIlIIIIlIllIllIllIlIIlIIl.llIlI.lI

monica

享受生活

不粘锅，好甩

去 A 有什么好处？

@wenxueywx 简单说就是把串行操作变成批处理

一、同时跟你发生交易的客户数量是有限的；
二、采用 mysql 事务实现，受限于行锁，高并发下会有严重的锁等待现象，分桶可以缓解，例如你可以把公司账号分为 0-9 共计 10 个子账号。查找账号时引入随机性没有用，因为你总的并发不会因为你的随机性降低。
三、 高并发下，随着并发数（ n ）的增加，innodb 的死锁检测占用的资源会以 n^2 级数上升，你可以简单暴力地关闭死锁检测，但是这治标不治本；治本的方法是在 innodb 中明确地需要串行执行地操作不要进入引擎层，可以在业务上进行排队，排队时还可以对队列进行优化，比如同时 100 人并发转入到子账号 0 ，此时数据库中给子账号 0 增加余额，以及记录流水的操作是明确需要串行执行的，如果进行业务上进行排队优化，你可以合并这些转入操作到一次数据库变更中。

使用 awk 计算指定目录下当天的所有日志文件总和

更好的做法是做好文件管理规划，程序上做约束，限制目录深度。

一定的场景下是可以省钱的，但是会带来一些新的问题

康酸莫米松+尿素软膏
平时多运动提高抵抗力，注意保湿；