优化查询步骤总结

慢查询调优。

1.索引本身：有无对应索引，联合索引的所有列是否能都被用到，字符串索引是否满足最左，联合索引是否区分度高的在前，索引是不是太多了影响插入，能否能用索引本身不用实际去聚簇索引取数据；

2.实际查询方案：数据库会根据数据库的现状调整方案，比如对于特别小的表数据库可能直接扫表而非用索引，所以有时候需要explain看实际查询方案是否按自己的想的做；

3.查询优化：例如前公司的最佳实践是在mysql基本不用join，排序和合并（特别是文件排序和不用索引排序的）如果本地能干就本地干，基本把mysql当mongo用；对于mysql简单查询能更好地利用mysql查询缓存；当时我有点不理解，后来k线图mongo最多30分钟k线一次取8000条来算也能50ms内返回，才开始部分理解；

4.加缓存减少库的访问量，但是对于本身很慢的查询也是没有用的。以前php本身有个yac的mysql本地缓存能针对mysql访问语句精确缓存，redis可以做业务缓存比如页面缓存也可以存耗时的计算结果等，数据库本身也能存储结果集比如上面说的30分钟k线图结果，还有超大规模的敏感联系方式用的布朗过滤器也是一种缓存，秒杀redis减计数也是减少库访问；

5.分区分库分表：都是有量才能反映出来，比如敏感图的查询优化其实就是分区加routing；分表最右的上报日志必须用阿里云的oceandb按日期分表；分库主写从读，这点mysql和mongo不同，目的都是保证redolog和journal顺序写入从库，但是mysql从库是用一个线程来写，mongo是直接卡死从库操作多线程同时写，所以mysql会高延时，mongo会卡死读操作；

6.重新设计表：数据冗余减少查询，但是冗余要考虑到事务一致性，增加业务复杂度，并且mongo无事务；遵守最佳实践，了解点数据库底层，比如mysql能全部char就别varchar，用最小的数据格式，时间用timestamp，mongo key尽量短，varchar尽量不大于718，ip用数字存，少用null，索引用递增的最好，少用删除多用删除标记等等；

7.硬件和系统参数：ssd或者带点硬盘，或者raid阵列，系统参数有binlog同步到表等；