RabbitMQ消息持久化
●索引中不包括一个或几个待排序的列；
转：https://www.cnblogs.com/bigberg/p/8195622.html
- 队列持久化需要在声明队列时添加参数 durable=True，这样在rabbitmq崩溃时也能保存队列
- 仅仅使用durable=True ，只能持久化队列，不能持久化消息
- 消息持久化需要在消息生成时，添加参数 properties=pika.BasicProperties(delivery_mode=2)
转：https://www.cnblogs.com/liehen2046/p/11052666.html
1.有or必全有索引;
2.复合索引未用左列字段;
3.like以%开头;
4.需要类型转换;
5.where中索引列有运算;
6.where中索引列使用了函数;
7.如果mysql觉得全表扫描更快时（数据少）;
springbot是同步还是异步的？
异步的。SpringBoot的异步调用，异步调用类似与定时任务，使用起来简单方便
JVM调优：
https://www.cnblogs.com/jay36/p/7680008.html
如何调优
观察内存释放情况、集合类检查、对象树：
堆查看：
可查看堆空间大小分配（年轻代、年老代、持久代分配）
提供即时的垃圾回收功能
垃圾监控（长时间监控回收情况）
查看堆内类、对象信息查看：数量、类型等
对象引用的查看
有了堆信息查看方面的功能，我们一般可以顺利解决以下问题：
--年老代年轻代大小划分是否合理
--内存泄漏
--垃圾回收算法设置是否合理
线程监控：
监控线程的数量、状态
Dump线程详细信息：查看线程内部运行情况
死锁检查
热点分析：
CPU热点：检查系统哪些方法占用的大量CPU时间
内存热点：检查哪些对象在系统中数量最大（一定时间内存活对象和销毁对象一起统计）
内存泄漏：
内存泄漏一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收），从而导致新的资源分配请求无法完成，引起系统错误。
内存泄漏对系统危害比较大，因为他可以直接导致系统的崩溃。
需要区别一下，内存泄漏和系统超负荷两者是有区别的，虽然可能导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误，而系统超负荷则是系统确实没有那么多资源可以分配了（其他的资源都在使用）。
新生代的GC（Minor GC）：
新生代通常存活时间较短基于Copying算法进行回收，所谓Copying算法就是扫描出存活的对象，并复制到一块新的完全未使用的空间中，对应于新生代，就是在Eden和FromSpace或ToSpace之间copy。新生代采用空闲指针的方式来控制GC触发，指针保持最后一个分配的对象在新生代区间的位置，当有新的对象要分配内存时，用于检查空间是否足够，不够就触发GC。当连续分配对象时，对象会逐渐从Eden到Survivor，最后到老年代。
在执行机制上JVM提供了串行GC(SerialGC)、并行回收GC(ParallelScavenge)和并行GC(ParNew)：
老年代的GC（Major GC/Full GC）：
老年代与新生代不同，老年代对象存活的时间比较长、比较稳定，因此采用标记(Mark)算法来进行回收，所谓标记就是扫描出存活的对象，然后再进行回收未被标记的对象，回收后对用空出的空间要么进行合并、要么标记出来便于下次进行分配，总之目的就是要减少内存碎片带来的效率损耗。
在执行机制上JVM提供了串行GC(Serial MSC)、并行GC(Parallel MSC)和并发GC(CMS)。
Redis是单线程还是多线程？
https://blog.csdn.net/bird73/article/details/79792548
(1) 绝大部分请求是纯粹的内存操作（非常快速）
(2) 采用单线程,避免了不必要的上下文切换和竞争条件
(3) 非阻塞IO - IO多路复用