用户71310690635
获得徽章 0
- 索引创建原则（复合索引）
针对数据量较大，且查询比较频繁的表建立索引。单表超过10W数据（增加用户体验）。
针对于查询条件、排序、分组操作的字段建立索引。
尽量选择区分度高的列做为索引，尽量建立唯一索引，区分度越高，使用索引效率越高。
如果是字符串类型的字段，字段的长度较长，可以针对字段的特点，建立前缀索引。
尽量使用联合索引，减少单列索引，查询时，联合索引很多时候看覆盖索引，节省存储空间，避免回表，提高查询效率。
要控制索引数量，索引并不是多多益善，索引越多，维护索引的结构的代价也就越大，会影响增删改的效率。
如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。展开评论点赞 - MySQL超大分页怎么处理
在数据量比较大的时候，如果使用limit分页查询，在查询时，越往后，分页查询效率越低。
例如select * from table_name limit 0, 10。这时候查询效率较高。
若是select * from table_name limit 9000000, 10，这时候查询效率很低，因为在进行分页查询的时候，如果执行limit 9000000, 10，此时MySQL排序前面9000010记录，仅仅返回9000000 - 9000010的记录，其他记录丢弃，查询排序的代价非常大。
优化思路：一般分页查询时，通过创建覆盖索引能够比较好的地提高性能，可以通过覆盖索引加子查询形式进行优化。
select * from table_name t, (select id from table_name order by id limit 9000000, 10) a where t.id = a.id。展开评论点赞 - 聚簇和非聚簇索引
聚簇索引：将数据与索引存储在一块，索引结构的叶子节点保存了行数据。必须有且仅由一个。
非聚簇索引（二级索引）：将数据存与索引分开存储，索引结构的叶子节点关联的是对于的主键。可以存在多个。
聚簇索引的选举规则：
如果存在主键，主键就是聚簇索引。
不在主键，使用第一个唯一键索引做为聚簇索引。
不存在主键或没有合适的唯一键，则InnoDB会自动生成一个rowid作为隐藏的聚簇索引。展开评论点赞 - 索引
索引就是帮助MySQL高效获取数据的数据结构（有序）。提高数据检索的效率，降低数据库IO的成本（不需要全盘扫描）。通过索引列对数据进行排序，减低数据排序的成本，降低了CPU的消耗。
MySQL的InnoDB引擎采用B+树来存储索引。
阶数更多，路径更短
磁盘读写代价B+树更低，非叶子节点只存key，叶子节点存储数据
B+树便于扫库和区间查询，叶子节点是双向循环链表。展开评论点赞 - 事务具有以下四个特性：
Atomicity，事务内的操作要么全做，要么不做。
Consistency，事务执行前后，数据状态是一致的。
Isolation，可以隔离多个并发事务，避免影响。
Durability，事务一旦提交超过，数据保证持久性。展开评论点赞 - RabbitMQ消息堆积
当生产者发送消息的速度超过消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储的消息达到上限后。之后发送的消息就会成为死信，可能会被丢弃。
解决思路：
添加更多的消费者，提高消费速度。
在消费者内开启线程池加快消息处理速度。
扩大队列容量，提高堆积上限 -> 惰性队列。
惰性队列
特点：
接收消息后直接存储到磁盘，而不是内存。
消费者要消费消息的时候，才会从磁盘读取消息到内存。
支持数百万条的消息存储展开评论点赞 - RabbitMQ高可用机制
使用集群来保证高可用
普通集群
会在集群中各个节点共享交换机，队列元信息（其它节点队列的引用）。不包含队列中的信息。
当访问集群节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回。
队列所在节点宕机，队列中的消息就会消失。
镜像集群
本质是主从模式，特点如下：
交换机，队列，消息会在各个MQ的镜像节点之间同步备份。
创建队列的节点被称为该队列的主节点，备份到的其他节点叫做该队列的镜像节点。
一个队列的主节点可能是另外一个队列的镜像节点。
所有操作都是主节点完成，然后同步给镜像节点。（如果在主从完成前，主节点已经宕机，可能出现数据丢失）
主节点宕机后，镜像节点会替代成新的主节点。
仲裁队列
仲裁队列是3.8以后才有的新功能，用来代替镜像队列，特征如下：
与镜像队列一样，都是主从模式，支持主从数据同步
主从同步基于Raft协议，保证了强一致性。展开评论点赞 - 消息重复消费
RabbitMQ
消费者处理完成后，还没来得及给MQ发送确认消息，消费者就挂了，这样MQ会认为该消息还没被处理。当消费者重启后，又会去MQ中获取消息，导致消息的重复消费。
解决
每条消息设置一个业务唯一ID，当消费的时候去校验业务ID是否存在。
幂等：【分布式锁、数据库锁（悲观锁、乐观锁）】。展开评论点赞 - Redis淘汰策略
当Redis内存不够用时，此时再向Redis添加新的key，那么Redis就会按照某一种策略和规则将内存中的数据删掉，这种数据删除规则称之为淘汰策略。
有八种不同的策略，
noeviction：不淘汰任何key，但是当内存不够用时不允许写入新的数据。默认
volatile-ttl：对进行设置了TTL的key，比较key的剩余TTL值，越小越先被淘汰。
allkeys-random：全体key，随机淘汰。
volatile-random：对设置了TTL的key，随机淘汰。
allkeys-lru：全体key，基于LRU算法进行淘汰。
volatile-lru：对设置了TTL的key，基于LRU算法进行淘汰
allkeys-LFU：全体key，基于LFU算法进行淘汰
volatile-LFU：对设置了TTL的key，基于LFU算法进行淘汰
LRU（Least Recently Used）：最近最少使用。当前时间减去最后一次访问时间，这个值越大淘汰优先级越高
LFU（Least Frequency Used）：最少频率使用。统计每个key的访问频率，值越小越淘汰优先级越高。
使用建议
如果业务中有明显的冷热数据区分，建议使用allkeys-lru。充分利用LRU算法的优势，把最近常访问的数据留在缓存中。通常使用该策略
如果业务中数据访问频率差别不大，没有明显的冷热数据区分，建议使用allkeys-random。
如果业务中有置顶需求，可以使用volatile-lru，同时置顶数据不设置过期时间。
如果业务中有短时高频访问数据，可以使用allkeys-lfu或者volatile-lfu。展开评论点赞