遇到的生产问题：安徽用户看课限制逻辑的调整事件，天气预报预算问题，3D建模，智信诚达代码缺失事件

索引失效的几种情况: 索引是个树，是个目录，失效情况:1联合索引只查右边的列2对查询列做运算或格式化操作3查询条件占比过大（in，不等于，not null等)4like使用左模糊（b+数按顺序来的)

事务操作数据的一致性。
事务隔离级别：脏读（并行事务中，事务a读取到事务b已修改，但还没有提交的单条数据，事务b可能会回滚)，幻读（并行事务中，事务a两次读取到的数据结果集不一致，因为事务b加了数据)，不可重复读（并行事务中，事务a两次读取到的单条数据不一致，因为事务b做了修改）
解决：
悲观锁：做逻辑的时候就锁住，比如用redis，或者查询时forupdate
乐观锁：对数据加时间戳或者版本信息，在更新时做比对

mq的重复消费解决办法（接口幂等）
1.业务逻辑判断，在做逻辑前，先做业务数据的判断
2.利用redis加锁
3.利用数据库唯一索引，提前生成id，多次保存的二次保存就会失败

分布式事务：多个服务节点的数据一致性(spring事务是单节点的，分布式事务是多个节点的数据一致性)，分布式有2pc 3pc tcc mq事务消息(逻辑开始前半消息或者叫预消息，完成后发送commit或者rollback)

锁用来保证共享数据的操作原子性。
分布式锁：分布式中，保证数据原子性，利用redisson库实现，其lock和unlock用于加锁和取消锁，其lock函数自带续期机制，但是需要合理设置锁的续期时间。

缓存击穿(同一时间请求没有缓存好的数据): 热更新，锁，永久有效
缓存击穿(请求数据库中没有的数据，导致不缓存，一直查数据库)：参数检验

一级缓存二级缓存，目的是解决数据库的性能瓶颈
一级缓存是sqlsession同一个事务中，查询同一条数据，第二次就会走缓存
二级缓存是mapper级别的(同一个naspace的mapper)，只要你做过一次查询，就会缓存，后面如果有增删改，则会刷新缓存(频繁更新的数据，就不建议开启二级缓存了)

秒杀：预热数据到redis，预先屏蔽一部分异常用户，mq异步处理，添加服务器节点快速处理数据承接流量洪峰。

在 Elasticsearch (ES) 中进行分页查询主要有三种方式：from + size、search_after 和 scroll。每种方式都有其适用场景和优缺点。

from + size：这是最基本的分页方式，通过指定from（起始位置）和size（每页数量）来获取数据。它简单易用，适用于数据量不大或不需要深度分页的场景。但是，当from值很大时，性能会下降，因为需要合并和排序所有分片返回的结果。ES 默认的max_result_window限制了最大分页数，通常为 10000，这意味着from + size的值不能超过这个限制。如果需要处理大量数据或深度分页，这种方式可能不是最佳选择。
search_after：这种方式适用于需要深度分页的场景，它通过使用上一页的最后一个文档的排序值来获取下一页数据，因此可以有效地避免深度分页的性能问题。这种方式的优点是性能较好，不存在深度分页问题，能够反映数据的实时变更。但是，它需要一个全局唯一的字段来排序，且实现相对复杂，每次查询都需要上次查询的结果。
scroll：scroll API 允许你“游走”或“滚动”通过大量结果，而不需要使用深度分页。它通过维护一个活跃的搜索上下文来实现，这个上下文会在指定的时间内保持开启状态。scroll 适用于需要遍历大量数据的场景，但牺牲了数据的实时性，因为 scroll 查询是基于初始查询时的快照数据。这种方式的优点是查询效率高，尤其适合于数据导出或批量处理，但缺点是需要维护 scroll ID 和历史快照，对服务器资源有一定的消耗。
选择哪种分页方式取决于具体的需求和场景。对于大多数常见的分页需求，from + size可能足够使用。但如果需要处理大量数据或进行深度分页，那么scroll或search_after可能是更好的选择。在实际应用中，需要根据数据量、查询频率、实时性要求等因素综合考虑。