慢查询治理相关

1. 没有索引，全表扫描，需要进行添加索引
2. 扫描没有使用where id>xxx order by id limit 进行扫描，直接where xxx order by id limit offset,limit,两种前者是explain : type range,后面是 index，性能 range > index, range 是索引树上范围查询，index 是对索引树整个做扫描
   3.聚合数据： 每次获取数据量较大进行计算 如 b端的 表获取时间段数据进行计算 select * from table where date >= 20220101 and date< 20220401，有可能获取到几百上千条，业务改造 改成 xxx_display 表 每次可以只获取到一条数据，减少扫描行数 rows - 提前计算，空间换时间
3. b端操作、审核数据表和c端读取数据表分离，b端的表业务复杂、如审核字段、额外信息字段，对于c端读取来说不需要，所以可以将b端和c端的表进行分离，c端的表简单直接读取
4. count(*) 统计 数据量大，需要时间>100ms，目前这种场景没有好的方案
5. join 场景，两张表进行聚合，如果是大表 join 小表 建议优先改为 小表 join 大表，建议能不使用 join 就不使用，偶尔可以用一下做报表统计，不使用join可以查两次db，先查A 然后查B；类似报表/后台的复杂的查询场景可以用替代的存储， 比如 es替代db
6. in 的mid 太多了，发现有1w mid的in查询，建议 代码里面如果in查询，后面都可以加下限制，500个最大？如果超过直接提示？
7. mysql命中索引 rows (扫描行数很少)，出现不频繁，可能是在刷脏页，这种可以忽略
8. 扫表方式切换到 id 方式进行扫表，如 select * from table where id > ? and id <= ? limit 500
9. 慢查治理放平时：技术方案设计的时候，如果有新增字段或者select 查询的时候或者管理 后台筛选场景都可以 review 下我们建的索引是否合理，同时考虑下数据量的增长，几十万的数据量很少会有慢查询，还是建议加上索引

扩展：
数据量大 sharding 进行分表？
是否回表，走覆盖索引？
索引下推？