场景题

典型回答 这个问题，做过对账的一定遇到过，没做过对账的一定不知道怎么回答，甚至都无法理解问题是怎么发生的。甚至你可能连什么叫日切都不知道。 所以，到底真的做没做过对账，这一个问题就能看出来，当然，如果你把我写的看会了，你也就相当于做过对账了。。。。（ＰＳ：就这玩意儿，全网应该只有我会讲吧。。。兄弟们算是学到真东西了。） 科普时间：什么是日切？　在银行、支付、核心系统里，日切（End of Day，EOD） 是个关键点。日切就是金融系统在每天营业结束后，将当天的数据进行结转、汇总、清算，并切换到下一会计日的过程。 主要做以下事情： 结转账户数据 把当天的交易流水（借贷发生额）汇总到账户余额里。 更新账户状态（比如存款计息、贷款结息）。 生成对账/清算数据 输出日终对账文件（和支付清算系统、银联、同业机构做对账）。 生成各种报表：分户账、总账、监管报表等。 批量处理 跑批量任务（批量划扣、代发工资、结算资金）。 清理过期数据，归档日志。 切换会计日 从 T 日切换到 T+1 日，把系统日期推进。 为什么会不一致 最常见的原因就是业务发生时间不一致。 A系统使用业务发生时间（例如，用户发起支付的时间）。 B系统使用系统处理时间（例如，支付渠道处理成功的时间）。 一笔在23:59:59发起的支付，可能在00:00:01才处理成功。A系统会把它算作前一天的数据，B系统则算作后一天。 以上这种是最常见的一种"正常情况"，尤其是和很多外部机构交互的时候，这种问题时有发生。 当然，除了这种，还有很多异常情况，比如真的请求丢了之类的，这个就和非日切处理方式一样了，这里主要讲因为日切导致的问题。 如何解决？ 对于上面说的业务发生时间不一致的问题，有一些解决方案。 如果对业务方有约束性，比如我们是牛逼的大甲方，可以要求他们如何写入数据，那么可以与业务方协商，明确一个统一的对账口径。例如，统一以“业务发生时间”为准，另一方根据这个时间调整自己的数据汇总逻辑。 也就是说，他的接口中开一个字段，类似bizTime这种，我把我的发生时间给他，然后他存下来，后面拉数据的时候，就以这个时间为准。 但是上面的情况过于理想化了，一般都很难搞得定，那么怎么办呢？ 有个常见的做法，那就是针对这批数据识别出来，然后重新核对。比如定义一个时间窗口，比如每天的23:55:00-00:05:00之间，算作是日切窗口，在这个时间段内发生的不一致的数据，我们进行二次核对。 二次核对一般是记录下来（不告警，避免浪费人工排查），第二天再拉出来核对一次，对实时性要求高的话，也可以立刻调接口查一遍。

典型回答 这是一个典型的索引失效的场景题，那么分析下都有可能是哪些原因。 ✅索引失效的问题是如何排查的，有哪些种情况？ **1、**发生了隐式类型转换 索引的字段，如果类型不一致，比如a本来是个字符串类型，但是按照int类型查询，这时候就会出现隐式类型转换，那么也会导致索引失效。 2、数据出现严重倾斜 这是最典型也最重要的情况。假设在 1000 万行数据的表中，有 999 万行的 a 都等于 1，只有 1 万行是其他值。那么当你查询 a = 1 时，使用索引查询需要访问 999 万个索引条目，然后再回表 999 万次，这个成本远高于直接全表扫描（一次顺序 I/O 读完所有数据）。这种情况下也可能不会走索引 3、a这个字段区分度不高 这个和上面的情况有点像，就是如果a这个字段的值只有很少的可能，比如像性别这种，只有男或者女，他也可能会导致索引失效。 但是其实问题本质还是因为1这个值的数据量太大了，而如果1比较少，比如像我在下面给大家讲的情况，也是可以用到索引，并且效果也会很好的。 ✅区分度不高的字段建索引一定没用吗？ 4、表中数据量过小 走不走索引是优化器决定的，而优化器会根据执行的成本来预估要不要走索引，有一种特殊情况，那就是当表中数据量很少，比如只有几十条甚至几百条数据时，查询优化器回去认为通过索引去查找再回表（如果索引不是覆盖索引）的成本，可能高于直接进行全表扫描的成本。因为全表扫描可以将数据一次性加载到内存中，而索引查找涉及随机的 I/O 操作。 5、索引不正确 题目中只给了SQL的情况，但是并没有说索引是怎么建的，如果a这个字段没有索引，或者说是他只是个联合索引并且不在最左边，比如联合索引(b,a)，那么因为不遵循最左前缀匹配，也会导致索引失效 ✅什么是最左前缀匹配？为什么要遵守？ 6、统计信息不准 InnoDB存储引擎依赖统计信息来决定使用哪个索引，如基数性、选择性这些都是统计信息。如果这些统计信息过时或不准确，优化器可能做出错误的决策。 一般在频繁的插入和删除后，还没来得及更新统计信息的情况下，也可能会出现这种情况。这时候也会导致索引失效。 ✅为什么MySQL会选错索引，如何解决？

典型回答 这是一个典型的索引相关的问题，这个问题其实不算难。 这个SQL中可能和索引有关的内容有以下三个方面： where a = 1 and b >2：a = 1是等值匹配（高效），b > 2是范围匹配（次高效）。可以建立(a,b)联合索引，并且把a放前面。 order by c,d,f： 排序字段是 (c, d, f)，如果能被索引覆盖，就能避免 filesort。 （因为索引天然有序） **select * **： 查询所有字段，索引无法完全覆盖查询，仍需回表读取数据。 综上所述，建索引肯定是有必要的。 建议建立如下索引： 1 CREATE INDEX idx_a_b_c_d_f ON table(a, b, c, d, f); a 在最前面，因为是等值匹配； b 在第二个位置，因为它是范围过滤；即使 b 是范围条件，MySQL 仍可利用 (a,b) 部分来过滤； (c,d,f) 排序部分在某些情况下仍能部分利用索引顺序（取决于优化器和数据分布） 不过需要注意，如果 b > 2 的选择性很差（即很多行符合条件），MySQL 可能仍需 filesort；可以考虑不要b或者把他放到最后去。 1 2 3 CREATE INDEX idx_a_c_d_f ON table(a, c, d, f, b); CREATE INDEX idx_a_c_d_f ON table(a, c, d, f);

典型回答 这几种是目前比较常见的一些存储，但是他们其实差别还挺大的。 MySQL、pgsql、oracle等等都是关系型数据库，主要用于数据持久化存储，因为他们都支持事务，有ACID的保障，并且支持各种复杂的查询，包括join、in、子查询等。一般适合于存储如订单、支付、账户等需要强一致性和完整性的场景。 Redis是一种非关系型数据库，存储的是key-value，它是基于内存的，所以有高性能的特性，他也支持一些高性能的数据结构，比如zset、hash等等的，虽然它支持RDB/AOF这样的持久化机制，但是还是不建议使用Redis作为持久化数据库，一方面他不支持ACID这样的事务，还有就是内存空间本来也是比较有限的。所以建议还是用来做缓存，或者半缓存半持久化比较合适。 Elasticsearch其实是一种搜索引擎，因为他里面的数据多数都是通过binlog同步的方式从数据库同步过来的，所以他提供的是准实时查询，即非实时查询，有一点点的数据延迟。但是因为他支持全文索引、倒排索引，所以他对文档查询，关键词匹配查询等等很友好，查询效率会比较高。并且在海量数据的处理上，他也比mysql要更适合一些。 HBase， 构建在 HDFS 之上，而 HDFS 是 Hadoop 的核心组件，主要用于离线批处理（如 MapReduce、Spark）。所以很多时候，使用HBase的时候，以作为离线数据库为主， 可以实现海量数据的离线存储、离线计算、数据同步与分析。一般是用于做数据对账、数据统计、数据存档、数据报表等需求用的比较多。 如何选择？ 要事务、强一致、复杂查询？ → PostgreSQL 要全文搜索、日志分析、聚合？ → Elasticsearch 高并发热点访问？ → Redis 要存 PB 级数据，离线场景 → HBase 但是，很多业务架构中，都是混着用的，比如数据库存一份，Redis存一份，ES存一份，HBase也存一份。 数据库做事务，来保障持久化。 Redis存热点数据，做缓存，提升查询性能。 ES做搜索引擎，用于文档检索或者模糊查询。 HBase做离线核对，离线报表的生成。 扩展知识 Redis\MySQL\MongoDB区别？ ✅Redis、MySQL和MongoDB的区别是什么，各自适用场景呢？