存储过程就像我们编程语言中的函数一样，封装了我们的代码(PLSQL、T-SQL)。 上面的文字我们肯定是看不懂的，也不愿意看下去的。接下来我就总结一下： 学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的 第二范式：满足第一范式,表…

例如上述 Employee 表，n = 2 时，应返回第二高的薪水 200。如果不存在第 n 高的薪水，那么查询应返回 null。 编写一个 SQL 查询来实现分数排名。如果两个分数相同，则两个分数排名（Rank）相同。请注意，平分后的下一个名次应该是下一个连续的整数值。换句话…

使用group by的sql语句，select后的字段只能是group by后的字段，如果需要展示其他字段数据，需要给该列使用聚合函数，否则默认展示分组后的第一行数据。 左连接：左表的记录将会全部表示出来，而右表只会显示符合搜索条件的记录。右表记录不足的地方均为NULL（用户信…

SQL（结构化查询语言）是一种设计用于检索和操作数据的数据库。它属于美国国家标准协会（ANSI）的一种标准，可用于执行Select（选择）、Update（更新）、Delete（删除）和Insert（插入）等数据任务。 表是在具有列和行的模型中设计的数据集合。在表中，指定了列数称…

😊：“读题，入职时候的薪水，加上提示一个员工有多次涨薪的情况，所以本质上是求解每个员工的最低薪水，还要按照emp_no降序排列。阿，求每个员工的薪水最小值，用group by就可以实现，要输出的字段在salaries这张表中都有，所以别看他给了2张表，只需要1张表就能算出结果。1...

Sql常用语法下列语句部分是Mssql语句，不可以在access中使用。 SQL分类： DDL—数据定义语言(CREATE，ALTER，DROP，DECLARE) DML—数据操纵语言(SELECT，

1/连续最长登陆天数 2/下一次登陆时间距离上一次登陆时间大于30天时，从1开始计数 3/一张包含全国各城市用户的观看记录表view_info（表中一条数据代表一次观看记录），包含city_name、

MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引。 MySQL官方对索引的定义为：索引（In…

面试官：要不你来讲讲你们对MySQL是怎么调优的？ 候选者：哇，这命题很大阿…我认为，对于开发者而言，对MySQL的调优重点一般是在「开发规范」、「数据库索引」又或者说解决线上慢查询上。 候选者：而对

这天我正在午休呢，公司DBA就把我喊醒了，说某库出现大量慢SQL，很快啊，很快，我还没反应过来，库就挂了，我心想现在的用户不讲武德啊，怎么在我睡觉的时候大量请求呢。 这是很常见的一个场景哈，因为很多业务开始数据量级不大，所以写sql的时候就没注意性能，等量级上去，很多业务就需要…

敖丙：加索引。 敖丙：没了。 哈哈开头这个场景是我臆想的一个面试场景，但是大家是不是觉得很真实，每个人的简历上但凡写到了数据库，都会在后面顺便写一句，会数据库调优。 我觉得调优能回答的点还是很多很多的，我自己看了《MySQL实战》、《高性能MySQL》、《丁奇MySQL47讲》…

一、前言 上一篇我们说了 腾讯一面：说一说 MySQL 中索引的底层原理，相信你对索引有个很清晰的认识了，这一篇我们来说一说慢 SQL 的排查以及调优。为啥面试官要问这个问题，其实跟上一篇的索引底层原

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

大家好，我是 V 哥。SQL调优对于提升数据库查询性能至关重要，特别是当数据量大时。以下是20个详细的SQL调优指南和高级技巧，结合案例说明，帮助优化SQL查询的性能。 1. 选择合适的索引 技巧: 

一次线上慢SQL调优分享 一周前，客户反馈做题页面经常卡顿，加载慢；我们监控比较少，所以根据直觉去MySQL慢查询日志一看，果然是一条慢SQL。废话不多，开整！！！ 业务背景 一个在线做题的代码评测系

作为开发人员，我们免不了与sql打交道。有些sql可能在业务的最开始，执行是毫无问题的。但是随着业务量的提升以及业务复杂度的加深，可能之前的sql就会逐渐展现出疲惫之势了。这时就会面临sql调优。 那么调优到底如何调？不同的人有不同的姿势。可能大部分人首先想到的就是加索引。 没…

order by字段尽量走索引... 其中有些手段也许跟随者MySQL版本的升级过时了。我们真的需要背这些调优手段吗？我觉得是没有必要的，在掌握MySQL存储架构和SQL执行原理的情况下，我们就很自然的明白，为什么要提议这么优化了，甚至能够发现别人提的不太合理的优化手段。 在 …

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第3天，点击查看活动详情 1.写在前面 在昨天的时候，我们就谈到了数据库连接池优化 详情可参考这里：点击查看 经过昨天的分析，我们已

面试官：MySQL如何进行性能调优？ 具体操作我这里整理了慢查询、explain、@@profiling关键字 慢查询 DBA有时候会发现有些语句比较慢，他们怎么发现的呢？ 编辑配置文件打开慢查询 然

在系统运行过程中，总会与数据库的交互，通过数据库端的日志查询执行时间最长与执行次数最多的sql语句，就可以有针对性的进行调优处理。 取执行时间最长的前50条sql语句。

引言 数据库性能优化是每个后端程序猿必备的基础技能之一，而Mysql中的explain堪称Mysql的性能优化分析神器，我们可以通过它来分析SQL语句的对应的执行计划在Mysql底层到底是如何执行的，

这几周系统访问量也是居高不下，不出意外系统又出现瓶颈了，大量用户反馈判题结果响应太慢；经排查，又是关于SQL的问题 业务背景 一个类似于力扣在线做题的代码评测模块，用户提交判题任务后，后台会进行异步判

什么是 SQL 调优？是不是觉得自己知道但又很模糊说不清楚，面试被问没有真实的案例，并不具备说服力。本文以为详细案例给大家解读。

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

Spark SQL是Spark生态系统中非常重要的组件， 能够利用 Spark 进行结构化的存储和操作。本文将围绕Spark内存泄露问题进行排查，并且给出具体的Spark调优方法。

@[TOC](OracleSQL调优系列之SQLMonitorReport)1、SQLMonitor简介SQL调优系列博客链接：SQL调优专栏sqlmonitor是oracle官方提供的自动监控符合特

Hive的架构 Hive元数据默认存储在derby数据库，不支持多客户端访问，所以将元数据存储在MySQl，支持多客户端访问。 2 Hive和e和数据库比较，Hive 和数据库除了拥有类似的查询语言，

1. hive 内部表和外部表的区别？ 未被external修饰的是内部表（managed table），被external修饰的为外部表（external table）； 内部表数据由Hive自身管

Hive SQL基本上适用大数据领域离线数据处理的大部分场景。Hive SQL的优化也是我们必须掌握的技能，而且，面试一定会问。那么，我希望面试者能答出其中的80%优化点，在这个问题上才算过关。 JVM重利用可以使得JOB长时间保留slot,直到作业结束，这在对于有较多任务和较…

第一题 需求 实现 数据准备 查询SQL 第二题 需求 实现 数据准备 查询SQL实现 第三题 需求 实现 数据准备 查询SQL 第四题 需求 实现 数据准备 查询SQL 第五题 需求 实现 数据准备

有用户点击日志记录表 t_click_log_025，包含user_id(用户ID),click_time(点击时间)，请查询出连续点击三次的用户数。

1.Hive的架构 2 Hive和数据库比较 Hive 和数据库除了拥有类似的查询语言，再无类似之处。 1）数据存储位置 Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。 2

📋 数据表：user_orders
+----+---------+---------------------------+
| id | user_id | products                  |
+----+---------+---------------------------+
| 1  | 1001    | ["P01","P02","P03"]       |
| 2  | 1002    | ["P02","P04"]             |
| 3  | 1003    | ["P01","P05","P06","P02"]  |
+----+---------+---------------------------+

🔍 问题
使用 json_each() 将 products 中的JSON数组"炸裂"成多行，每个商品一行。

💡 参考
SELECT u.user_id, je.value AS product_id
FROM user_orders u, json_each(u.products) AS je;

📖 解析
- json_each() 是SQLite的JSON函数，功能类似Hive的explode()
- 返回两列：key(下标) 和 value(元素值)
- FROM 后用逗号连接（隐式JOIN），相当于 LATERAL VIEW
- 这是JSON数组→多行的基础操作

📋 数据表：page_visits
+----+---------+---------------------------------------------+
| id | user_id | pages                                       |
+----+---------+---------------------------------------------+
| 1  | 1001    | ["home","search","detail","cart"]           |
| 2  | 1002    | ["home","detail"]                           |
| 3  | 1003    | ["login","home","profile","settings","logout"] |
+----+---------+---------------------------------------------+

🔍 问题
使用 json_each() 炸裂 pages，保留数组中每个元素的下标(key)和值(value)。

💡 参考
SELECT p.user_id, je.key AS page_idx, je.value AS page_name
FROM page_visits p, json_each(p.pages) AS je;

📖 解析
- json_each() 返回 key(下标) 和 value(值)，下标从0开始
- 相当于Hive的 posexplode() → 同时拿到下标和值
- 适用场景：需要知道元素在数组中的位置

📋 数据表：user_tags_json
+----+---------+---------------------------------------------+
| id | user_id | tags                                        |
+----+---------+---------------------------------------------+
| 1  | 1001    | {"age":"25","city":"SZ","vip":"true"}        |
| 2  | 1002    | {"age":"30","city":"GZ"}                       |
| 3  | 1003    | {"age":"22","city":"BJ","level":"gold"}         |
+----+---------+---------------------------------------------+

🔍 问题
用 json_each() 将JSON对象的 key-value 炸裂成多行。

💡 参考
SELECT u.user_id, je.key AS tag_key, je.value AS tag_value
FROM user_tags_json u, json_each(u.tags) AS je;

📖 解析
- json_each() 对JSON对象同样返回(key, value)两列
- Hive中Map类型用 explode() 效果相同
- 常用场景：标签、配置等属性对→结构化分析

📋 数据表：articles_json
+----+------------+---------------------------+-------------------+
| id | article_id | tags                      | categories        |
+----+------------+---------------------------+-------------------+
| 1  | A01        | ["sql","hive","spark"]     | ["tech","database"] |
| 2  | A02        | ["python"]                 | ["tech"]         |
+----+------------+---------------------------+-------------------+

🔍 问题
同时炸裂 tags 和 categories，得到所有标签×分类的笛卡尔积组合。

💡 参考
SELECT a.article_id, t.value AS tag, c.value AS category
FROM articles_json a
JOIN json_each(a.tags) AS t
JOIN json_each(a.categories) AS c;

📖 解析
- 多个 json_each() 会造成笛卡尔积，数据量 = N1 × N2
- 如不需要笛卡尔积，分别查询再 UNION ALL
- 注意数据量膨胀对性能的影响

📋 数据表：user_orders（同入门1）
products字段含重复值：1001有两个P01，1003有两个P02

🔍 问题
炸裂后统计每个用户购买商品的去重数量和总数。

💡 参考
-- 去重数量
SELECT u.user_id, COUNT(DISTINCT je.value) AS unique_items
FROM user_orders u, json_each(u.products) je
GROUP BY u.user_id;

-- 总数量
SELECT u.user_id, COUNT(je.value) AS total_items
FROM user_orders u, json_each(u.products) je
GROUP BY u.user_id;

📖 解析
- 炸裂后一行变多行 → GROUP BY 原表字段做聚合
- COUNT(DISTINCT) 实现去重计数
- 这是json_each最常用场景：打平→聚合分析

📋 数据表：event_logs
+----+---------+-------------------------------------------------------------+
| id | user_id | events                                                      |
+----+---------+-------------------------------------------------------------+
| 1  | 1001    | [{"type":"pv","ts":"10:00"},{"type":"cart","ts":"10:05"},{"type":"pay","ts":"10:10"}] |
| 2  | 1002    | [{"type":"pv","ts":"11:00"}]                                 |
+----+---------+-------------------------------------------------------------+

🔍 问题
用 json_each() 炸裂对象数组，用 json_extract() 取出每个对象的字段。

💡 参考
SELECT e.user_id,
       json_extract(je.value, '$.type') AS event_type,
       json_extract(je.value, '$.ts') AS event_time
FROM event_logs e, json_each(e.events) AS je;

📖 解析
- json_each() 的value是整个JSON对象
- 再用 json_extract(value, '$.字段') 取出对象内部的字段
- 这相当于Hive中 inline(Array<Struct>) 的功能
- json_extract 使用 JSON path 语法：$.字段名

📋 数据表：user_tags_json + tag_recommendations
user_tags_json: tags是JSON对象 {"sports":"1","music":"1"}
tag_recommendations: 标签→推荐商品映射表

🔍 问题
炸裂用户标签的key，JOIN推荐表，为每个用户推荐商品。

💡 参考
SELECT DISTINCT u.user_id, r.recommend
FROM user_tags_json u
JOIN json_each(u.tags) je  -- 炸裂标签的key
JOIN tag_recommendations r ON je.key = r.tag;

📖 解析
- 先 json_each() 打平JSON → 再 JOIN → 去重
- 这是实际场景中的经典操作
- 注意JOIN顺序：炸裂产生多行后再与其他表关联
- 如果不先炸裂，JSON字段无法直接做等值JOIN

📋 数据表：user_tags_json (tags是JSON对象)

🔍 问题
炸裂JSON对象后用CASE WHEN做行转列，得到每个用户的各属性宽表。

💡 参考
WITH exploded AS (
  SELECT u.user_id, je.key AS attr_key, je.value AS attr_val
  FROM user_tags_json u, json_each(u.tags) je
)
SELECT user_id,
  MAX(CASE WHEN attr_key='age'   THEN attr_val END) AS age,
  MAX(CASE WHEN attr_key='city'  THEN attr_val END) AS city,
  MAX(CASE WHEN attr_key='vip'   THEN attr_val END) AS vip,
  MAX(CASE WHEN attr_key='level' THEN attr_val END) AS level
FROM exploded GROUP BY user_id;

📖 解析
- 经典二步走：json_each打平 → CASE WHEN/MAX行列转换
- 类似Hive的 explode + Pivot 组合
- 适用于：JSON标签/配置 → 结构化宽表，方便后续分析

📋 数据表：user_orders
products字段是JSON数组，含重复值

🔍 问题
1. 先 json_each 炸裂去重
2. 再用 json_group_array(DISTINCT) 重新聚合为去重数组

💡 参考
SELECT user_id,
  json_group_array(DISTINCT je.value) AS unique_products
FROM user_orders, json_each(products) je
GROUP BY user_id;

📖 解析
- json_group_array()：将多行聚合成JSON数组（类似Hive collect_list）
- DISTINCT 在聚合函数内去重（类似Hive collect_set）
- 完整套路：json_each → 处理 → json_group_array 重塑
- 其他聚合：json_group_object(key,value) 生成JSON对象
- 注意：大量数据聚合时注意性能

📋 综合题：分析 user_orders 的用户购买行为

🔍 问题（多个子问题）
1. 统计每个商品被多少用户购买（商品热度）
2. 找出购买商品数最多的用户
3. 计算用户之间的商品共现次数

💡 参考
-- 1. 商品热度
SELECT je.value AS product, COUNT(DISTINCT user_id) AS buyer_cnt
FROM user_orders, json_each(products) je
GROUP BY je.value ORDER BY buyer_cnt DESC;

-- 2. 最多商品用户
SELECT user_id, COUNT(je.value) AS item_cnt
FROM user_orders, json_each(products) je
GROUP BY user_id ORDER BY item_cnt DESC LIMIT 1;

-- 3. 共现分析（自连接）
SELECT a.value AS p1, b.value AS p2, COUNT(*) AS co_cnt
FROM user_orders u,
     json_each(u.products) a,
     json_each(u.products) b
WHERE a.value < b.value
GROUP BY p1, p2;

📖 解析
- 子问题3用了两个json_each做自连接，数据膨胀=Σ(Ni²)
- 大数据量时建议加LIMIT或先过滤再炸裂
- 性能优化原则：减少炸裂前数据量 > 控制炸裂膨胀倍数 > 增加索引

存储过程就像我们编程语言中的函数一样，封装了我们的代码(PLSQL、T-SQL)。 上面的文字我们肯定是看不懂的，也不愿意看下去的。接下来我就总结一下： 学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的 第二范式：满足第一范式,表…

例如上述 Employee 表，n = 2 时，应返回第二高的薪水 200。如果不存在第 n 高的薪水，那么查询应返回 null。 编写一个 SQL 查询来实现分数排名。如果两个分数相同，则两个分数排名（Rank）相同。请注意，平分后的下一个名次应该是下一个连续的整数值。换句话…

使用group by的sql语句，select后的字段只能是group by后的字段，如果需要展示其他字段数据，需要给该列使用聚合函数，否则默认展示分组后的第一行数据。 左连接：左表的记录将会全部表示出来，而右表只会显示符合搜索条件的记录。右表记录不足的地方均为NULL（用户信…

SQL（结构化查询语言）是一种设计用于检索和操作数据的数据库。它属于美国国家标准协会（ANSI）的一种标准，可用于执行Select（选择）、Update（更新）、Delete（删除）和Insert（插入）等数据任务。 表是在具有列和行的模型中设计的数据集合。在表中，指定了列数称…

😊：“读题，入职时候的薪水，加上提示一个员工有多次涨薪的情况，所以本质上是求解每个员工的最低薪水，还要按照emp_no降序排列。阿，求每个员工的薪水最小值，用group by就可以实现，要输出的字段在salaries这张表中都有，所以别看他给了2张表，只需要1张表就能算出结果。1...

Sql常用语法下列语句部分是Mssql语句，不可以在access中使用。 SQL分类： DDL—数据定义语言(CREATE，ALTER，DROP，DECLARE) DML—数据操纵语言(SELECT，

1/连续最长登陆天数 2/下一次登陆时间距离上一次登陆时间大于30天时，从1开始计数 3/一张包含全国各城市用户的观看记录表view_info（表中一条数据代表一次观看记录），包含city_name、

MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引。 MySQL官方对索引的定义为：索引（In…

面试官：要不你来讲讲你们对MySQL是怎么调优的？ 候选者：哇，这命题很大阿…我认为，对于开发者而言，对MySQL的调优重点一般是在「开发规范」、「数据库索引」又或者说解决线上慢查询上。 候选者：而对

这天我正在午休呢，公司DBA就把我喊醒了，说某库出现大量慢SQL，很快啊，很快，我还没反应过来，库就挂了，我心想现在的用户不讲武德啊，怎么在我睡觉的时候大量请求呢。 这是很常见的一个场景哈，因为很多业务开始数据量级不大，所以写sql的时候就没注意性能，等量级上去，很多业务就需要…

敖丙：加索引。 敖丙：没了。 哈哈开头这个场景是我臆想的一个面试场景，但是大家是不是觉得很真实，每个人的简历上但凡写到了数据库，都会在后面顺便写一句，会数据库调优。 我觉得调优能回答的点还是很多很多的，我自己看了《MySQL实战》、《高性能MySQL》、《丁奇MySQL47讲》…

一、前言 上一篇我们说了 腾讯一面：说一说 MySQL 中索引的底层原理，相信你对索引有个很清晰的认识了，这一篇我们来说一说慢 SQL 的排查以及调优。为啥面试官要问这个问题，其实跟上一篇的索引底层原

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

大家好，我是 V 哥。SQL调优对于提升数据库查询性能至关重要，特别是当数据量大时。以下是20个详细的SQL调优指南和高级技巧，结合案例说明，帮助优化SQL查询的性能。 1. 选择合适的索引 技巧: 

一次线上慢SQL调优分享 一周前，客户反馈做题页面经常卡顿，加载慢；我们监控比较少，所以根据直觉去MySQL慢查询日志一看，果然是一条慢SQL。废话不多，开整！！！ 业务背景 一个在线做题的代码评测系

作为开发人员，我们免不了与sql打交道。有些sql可能在业务的最开始，执行是毫无问题的。但是随着业务量的提升以及业务复杂度的加深，可能之前的sql就会逐渐展现出疲惫之势了。这时就会面临sql调优。 那么调优到底如何调？不同的人有不同的姿势。可能大部分人首先想到的就是加索引。 没…

order by字段尽量走索引... 其中有些手段也许跟随者MySQL版本的升级过时了。我们真的需要背这些调优手段吗？我觉得是没有必要的，在掌握MySQL存储架构和SQL执行原理的情况下，我们就很自然的明白，为什么要提议这么优化了，甚至能够发现别人提的不太合理的优化手段。 在 …

背景 基于TPCDS的100G，500G数据进行了99SQL综合调优测试 测试机为物理机5台，1台为管理节点，4台为计算节点 可用内存约1T，核心数（vCore）200大概 重要参数 执行器个数 --

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第3天，点击查看活动详情 1.写在前面 在昨天的时候，我们就谈到了数据库连接池优化 详情可参考这里：点击查看 经过昨天的分析，我们已

面试官：MySQL如何进行性能调优？ 具体操作我这里整理了慢查询、explain、@@profiling关键字 慢查询 DBA有时候会发现有些语句比较慢，他们怎么发现的呢？ 编辑配置文件打开慢查询 然

在系统运行过程中，总会与数据库的交互，通过数据库端的日志查询执行时间最长与执行次数最多的sql语句，就可以有针对性的进行调优处理。 取执行时间最长的前50条sql语句。

引言 数据库性能优化是每个后端程序猿必备的基础技能之一，而Mysql中的explain堪称Mysql的性能优化分析神器，我们可以通过它来分析SQL语句的对应的执行计划在Mysql底层到底是如何执行的，

这几周系统访问量也是居高不下，不出意外系统又出现瓶颈了，大量用户反馈判题结果响应太慢；经排查，又是关于SQL的问题 业务背景 一个类似于力扣在线做题的代码评测模块，用户提交判题任务后，后台会进行异步判

什么是 SQL 调优？是不是觉得自己知道但又很模糊说不清楚，面试被问没有真实的案例，并不具备说服力。本文以为详细案例给大家解读。

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

Spark SQL是Spark生态系统中非常重要的组件， 能够利用 Spark 进行结构化的存储和操作。本文将围绕Spark内存泄露问题进行排查，并且给出具体的Spark调优方法。

Hive的架构 Hive元数据默认存储在derby数据库，不支持多客户端访问，所以将元数据存储在MySQl，支持多客户端访问。 2 Hive和e和数据库比较，Hive 和数据库除了拥有类似的查询语言，

1. hive 内部表和外部表的区别？ 未被external修饰的是内部表（managed table），被external修饰的为外部表（external table）； 内部表数据由Hive自身管

Hive SQL基本上适用大数据领域离线数据处理的大部分场景。Hive SQL的优化也是我们必须掌握的技能，而且，面试一定会问。那么，我希望面试者能答出其中的80%优化点，在这个问题上才算过关。 JVM重利用可以使得JOB长时间保留slot,直到作业结束，这在对于有较多任务和较…

第一题 需求 实现 数据准备 查询SQL 第二题 需求 实现 数据准备 查询SQL实现 第三题 需求 实现 数据准备 查询SQL 第四题 需求 实现 数据准备 查询SQL 第五题 需求 实现 数据准备

有用户点击日志记录表 t_click_log_025，包含user_id(用户ID),click_time(点击时间)，请查询出连续点击三次的用户数。

1.Hive的架构 2 Hive和数据库比较 Hive 和数据库除了拥有类似的查询语言，再无类似之处。 1）数据存储位置 Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。 2

题目：有一张用户点击行为表 user_click_log（user_id, click_time, page_id, event_name），另有一张笔记品类表 note_category（page_id, category_name）。请用SQL找出每个用户点击次数最多的前3个笔记品类，输出用户ID、品类名称、点击次数、排名。

思路：窗口函数 + 多表联查。第一步关联两表按用户和品类聚合算点击次数；第二步用 ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY cnt DESC) 排序；第三步筛选 rk <= 3。

---

🤖 AI解析：
答案/思路：使用 CTE 分步处理，先聚合再排序最后过滤。关键SQL：ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY click_cnt DESC)

📌 关键知识点：窗口函数（ROW_NUMBER/RANK/DENSE_RANK）、CTE、多表JOIN聚合、分组TopN

⚠️ 易错点：1) 并列排名时ROW_NUMBER会随机分配序号，如需保留并列应改用RANK/DENSE_RANK；2) 大数据量下需要分区表或索引优化；3) 注意LEFT JOIN和INNER JOIN的区别影响结果

题目：有一张用户登录表 user_login（user_id, login_date）。请计算2025年1月的新用户次日留存率、7日留存率和30日留存率。新用户定义为该月首次登录的用户。

思路：先用MIN(login_date)找出1月首次登录用户，然后LEFT JOIN后续登录记录，用CASE WHEN判断是否在N天后再次登录。

---

🤖 AI解析：
答案/思路：留存率 = 仍在活跃的用户数 ÷ 同批次新用户总数。先提取首次登录日期作为基准日，再关联后续登录判断是否回访。

📌 关键知识点：留存率定义、DATE_ADD日期函数、LEFT JOIN保留未回访用户、CASE WHEN条件计数

⚠️ 易错点：1) 留存率的分子必须是同一批次用户，不能混批；2) 注意区分自然日和事件日留存；3) 大数据量下用Hive/Spark分布式计算；4) 老用户换设备重新注册需交叉验证

题目：现有一张订单表order（order_id, user_id, product_id, quantity, pay_time），请查询出每个用户的第一条记录和最后一条记录。

思路：用ROW_NUMBER()按user_id分组、pay_time排序，分别取ASC和DESC的rn=1记录，再UNION合并。

---

🤖 AI解析：
答案/思路：对每个user_id按pay_time升序排列取首条（ROW_NUMBER ASC rn=1），按pay_time降序排列取末条（ROW_NUMBER DESC rn=1），再合并结果。

📌 关键知识点：ROW_NUMBER窗口函数、PARTITION BY分组、ORDER BY排序方向、UNION ALL合并

⚠️ 易错点：1) 同一时间有多条订单时ROW_NUMBER只取一条，如需全部可用RANK；2) 注意pay_time可能为NULL需过滤；3) 大数据量建议用子查询而非全表扫描

题目：Hive面试高频题 - Hive内部表和外部表的区别？

原文要点：未被external修饰的是内部表，被external修饰的是外部表。内部表删除时会同时删除元数据和数据；外部表删除时只删除元数据不删除数据。

---

🤖 AI解析：
答案/思路：内部表（Managed Table）：Hive管理数据生命周期，DROP TABLE删除元数据+数据。外部表（External Table）：Hive只管理元数据，数据路径可外部指定，DROP TABLE只删元数据。生产建议用外部表防止误删数据。

📌 关键知识点：EXTERNAL关键字、数据存储位置控制、DROP行为差异、LOCATION指定路径、MSCK REPAIR TABLE恢复分区

⚠️ 易错点：1) 内部表数据默认在hive.metastore.warehouse.dir下，外部表需指定LOCATION；2) 外部表ALTER TABLE不会移动数据文件；3) 生产环境建议外部表+分区表组合

题目：Hive面试高频题 - Hive的排序方式有哪些？各有什么区别？

---

🤖 AI解析：
答案/思路：4种排序：ORDER BY全局排序（单Reducer，数据量大很慢）；SORT BY局部排序（每个Reducer内排序，不保证全局）；DISTRIBUTE BY按字段分发到Reducer（控制分区）；CLUSTER BY = DISTRIBUTE BY + SORT BY（同字段分发并排序）。

📌 关键知识点：全局排序vs局部排序、Reducer数量影响、DISTRIBUTE BY分区控制、CLUSTER BY等价组合、limit优化ORDER BY

⚠️ 易错点：1) ORDER BY只用一个Reducer，大数据量必须加limit；2) SORT BY不保证全局有序；3) CLUSTER BY的排序字段和分区字段必须相同；4) DISTRIBUTE BY后可接不同的SORT BY字段

题目：小红书大数据面试 - Hive两个大表Join的过程？

---

🤖 AI解析：
答案/思路：大表Join核心是Shuffle Join：Map阶段按Join key分发到Reducer，Reducer端做合并。优化方式：1) MapJoin（小表广播到每个Mapper内存）；2) Bucket MapJoin（分桶表只Join对应桶）；3) Sort Merge Bucket Join（分桶+排序后Merge Join无需Shuffle）。

📌 关键知识点：Common Join（Shuffle Join）、Map Join（广播小表）、SMB Join（分桶排序合并）、大小表策略、mapjoin.auto.convert参数

⚠️ 易错点：1) MapJoin要求小表能放进内存，否则OOM；2) SMB Join需要两表分桶数相同且按Join key排序；3) Hive默认优先尝试MapJoin，小表超阈值才降级为Common Join

存储过程就像我们编程语言中的函数一样，封装了我们的代码(PLSQL、T-SQL)。 上面的文字我们肯定是看不懂的，也不愿意看下去的。接下来我就总结一下： 学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的 第二范式：满足第一范式,表…

例如上述 Employee 表，n = 2 时，应返回第二高的薪水 200。如果不存在第 n 高的薪水，那么查询应返回 null。 编写一个 SQL 查询来实现分数排名。如果两个分数相同，则两个分数排名（Rank）相同。请注意，平分后的下一个名次应该是下一个连续的整数值。换句话…

使用group by的sql语句，select后的字段只能是group by后的字段，如果需要展示其他字段数据，需要给该列使用聚合函数，否则默认展示分组后的第一行数据。 左连接：左表的记录将会全部表示出来，而右表只会显示符合搜索条件的记录。右表记录不足的地方均为NULL（用户信…

SQL（结构化查询语言）是一种设计用于检索和操作数据的数据库。它属于美国国家标准协会（ANSI）的一种标准，可用于执行Select（选择）、Update（更新）、Delete（删除）和Insert（插入）等数据任务。 表是在具有列和行的模型中设计的数据集合。在表中，指定了列数称…

😊：“读题，入职时候的薪水，加上提示一个员工有多次涨薪的情况，所以本质上是求解每个员工的最低薪水，还要按照emp_no降序排列。阿，求每个员工的薪水最小值，用group by就可以实现，要输出的字段在salaries这张表中都有，所以别看他给了2张表，只需要1张表就能算出结果。1...

Sql常用语法下列语句部分是Mssql语句，不可以在access中使用。 SQL分类： DDL—数据定义语言(CREATE，ALTER，DROP，DECLARE) DML—数据操纵语言(SELECT，

1/连续最长登陆天数 2/下一次登陆时间距离上一次登陆时间大于30天时，从1开始计数 3/一张包含全国各城市用户的观看记录表view_info（表中一条数据代表一次观看记录），包含city_name、

MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引。 MySQL官方对索引的定义为：索引（In…

面试官：要不你来讲讲你们对MySQL是怎么调优的？ 候选者：哇，这命题很大阿…我认为，对于开发者而言，对MySQL的调优重点一般是在「开发规范」、「数据库索引」又或者说解决线上慢查询上。 候选者：而对

这天我正在午休呢，公司DBA就把我喊醒了，说某库出现大量慢SQL，很快啊，很快，我还没反应过来，库就挂了，我心想现在的用户不讲武德啊，怎么在我睡觉的时候大量请求呢。 这是很常见的一个场景哈，因为很多业务开始数据量级不大，所以写sql的时候就没注意性能，等量级上去，很多业务就需要…

敖丙：加索引。 敖丙：没了。 哈哈开头这个场景是我臆想的一个面试场景，但是大家是不是觉得很真实，每个人的简历上但凡写到了数据库，都会在后面顺便写一句，会数据库调优。 我觉得调优能回答的点还是很多很多的，我自己看了《MySQL实战》、《高性能MySQL》、《丁奇MySQL47讲》…

一、前言 上一篇我们说了 腾讯一面：说一说 MySQL 中索引的底层原理，相信你对索引有个很清晰的认识了，这一篇我们来说一说慢 SQL 的排查以及调优。为啥面试官要问这个问题，其实跟上一篇的索引底层原

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

大家好，我是 V 哥。SQL调优对于提升数据库查询性能至关重要，特别是当数据量大时。以下是20个详细的SQL调优指南和高级技巧，结合案例说明，帮助优化SQL查询的性能。 1. 选择合适的索引 技巧: 

一次线上慢SQL调优分享 一周前，客户反馈做题页面经常卡顿，加载慢；我们监控比较少，所以根据直觉去MySQL慢查询日志一看，果然是一条慢SQL。废话不多，开整！！！ 业务背景 一个在线做题的代码评测系

作为开发人员，我们免不了与sql打交道。有些sql可能在业务的最开始，执行是毫无问题的。但是随着业务量的提升以及业务复杂度的加深，可能之前的sql就会逐渐展现出疲惫之势了。这时就会面临sql调优。 那么调优到底如何调？不同的人有不同的姿势。可能大部分人首先想到的就是加索引。 没…

order by字段尽量走索引... 其中有些手段也许跟随者MySQL版本的升级过时了。我们真的需要背这些调优手段吗？我觉得是没有必要的，在掌握MySQL存储架构和SQL执行原理的情况下，我们就很自然的明白，为什么要提议这么优化了，甚至能够发现别人提的不太合理的优化手段。 在 …

背景 基于TPCDS的100G，500G数据进行了99SQL综合调优测试 测试机为物理机5台，1台为管理节点，4台为计算节点 可用内存约1T，核心数（vCore）200大概 重要参数 执行器个数 --

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第3天，点击查看活动详情 1.写在前面 在昨天的时候，我们就谈到了数据库连接池优化 详情可参考这里：点击查看 经过昨天的分析，我们已

面试官：MySQL如何进行性能调优？ 具体操作我这里整理了慢查询、explain、@@profiling关键字 慢查询 DBA有时候会发现有些语句比较慢，他们怎么发现的呢？ 编辑配置文件打开慢查询 然

在系统运行过程中，总会与数据库的交互，通过数据库端的日志查询执行时间最长与执行次数最多的sql语句，就可以有针对性的进行调优处理。 取执行时间最长的前50条sql语句。

引言 数据库性能优化是每个后端程序猿必备的基础技能之一，而Mysql中的explain堪称Mysql的性能优化分析神器，我们可以通过它来分析SQL语句的对应的执行计划在Mysql底层到底是如何执行的，

这几周系统访问量也是居高不下，不出意外系统又出现瓶颈了，大量用户反馈判题结果响应太慢；经排查，又是关于SQL的问题 业务背景 一个类似于力扣在线做题的代码评测模块，用户提交判题任务后，后台会进行异步判

什么是 SQL 调优？是不是觉得自己知道但又很模糊说不清楚，面试被问没有真实的案例，并不具备说服力。本文以为详细案例给大家解读。

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

Spark SQL是Spark生态系统中非常重要的组件， 能够利用 Spark 进行结构化的存储和操作。本文将围绕Spark内存泄露问题进行排查，并且给出具体的Spark调优方法。

Hive的架构 Hive元数据默认存储在derby数据库，不支持多客户端访问，所以将元数据存储在MySQl，支持多客户端访问。 2 Hive和e和数据库比较，Hive 和数据库除了拥有类似的查询语言，

1. hive 内部表和外部表的区别？ 未被external修饰的是内部表（managed table），被external修饰的为外部表（external table）； 内部表数据由Hive自身管

Hive SQL基本上适用大数据领域离线数据处理的大部分场景。Hive SQL的优化也是我们必须掌握的技能，而且，面试一定会问。那么，我希望面试者能答出其中的80%优化点，在这个问题上才算过关。 JVM重利用可以使得JOB长时间保留slot,直到作业结束，这在对于有较多任务和较…

第一题 需求 实现 数据准备 查询SQL 第二题 需求 实现 数据准备 查询SQL实现 第三题 需求 实现 数据准备 查询SQL 第四题 需求 实现 数据准备 查询SQL 第五题 需求 实现 数据准备

有用户点击日志记录表 t_click_log_025，包含user_id(用户ID),click_time(点击时间)，请查询出连续点击三次的用户数。

1.Hive的架构 2 Hive和数据库比较 Hive 和数据库除了拥有类似的查询语言，再无类似之处。 1）数据存储位置 Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。 2

如何设计一个支持秒级延迟的流批一体数仓架构？字节跳动2026年大数据架构师面试必考题，要求端到端数据延迟<10秒，同时支持T+0实时报表和T+1离线分析。

---

🤖 AI解析：
架构设计：四层架构——①数据接入层：Flink CDC同步业务DB，Filebeat采集日志；②统一消息层：Kafka多集群架构，原始Topic保留7天，清洗Topic保留3天；③统一计算层：Flink流批一体引擎，实时用DataStream/Batch Mode，离线用Flink Batch Mode；④统一存储层：Apache Paimon湖仓存储(ODS/DWD/DWS/DIM)。服务层用StarRocks做实时OLAP，Trino做离线OLAP。

关键技术点：Flink+Paimon是流批一体最佳实践——Flink提供流批统一计算引擎，Paimon的LSM-Tree结构适合高吞吐实时写入且支持秒级更新；增量Checkpoint间隔1-2秒保证秒级延迟；两阶段提交(2PC)保证数据一致性。

📌 关键知识点：Flink+Paimon流批一体架构；Paimon的LSM-Tree结构实现高吞吐写入+批量查询；2PC+Exactly-Once保证端到端一致性
⚠️ 易错点：不要以为Kappa架构就是流批一体——Kappa只是用一套代码，流批一体要求存储层也统一；Paimon小文件合并策略必须配置，否则查询性能急剧下降

对比Delta Lake、Iceberg、Hudi、Paimon四大开放表格式的原理差异和选型依据，什么业务场景选择哪种格式？2026年大数据面试最热门考点。

---

🤖 AI解析：
四大格式对比：①Delta Lake(Databricks)——与Spark深度集成，查询性能高，实时性分钟级，市场份额35%；②Iceberg(Netflix)——开放表格式标准，多引擎支持最好，实时性分钟级，份额30%；③Hudi(Uber)——面向更新优化，写入性能高，实时性分钟级，份额15%；④Paimon(阿里)——流批统一存储，与Flink深度集成，实时性秒级，份额20%。

选型依据：主用Spark→Delta Lake；主用Flink+需秒级实时→Paimon；多引擎兼容→Iceberg；大量更新删除→Hudi/Paimon。

📌 关键知识点：Paimon是唯一支持秒级实时的格式；Iceberg生态兼容性最强；Delta Lake与Spark绑定最深；选型需看计算引擎、实时性要求和生态需求
⚠️ 易错点：不要只看市场份额选型——实时性要求是决定性因素；Paimon虽然实时性最好但生态不如Iceberg成熟；Delta Lake不是'开源'的，社区版和商业版功能差异大

设计一个电商实时数仓架构，从数据接入到数据服务全链路设计。要求支持实时大屏、实时报表、实时风控、实时推荐四大应用场景。

---

🤖 AI解析：
全链路架构：①数据接入：Flink CDC同步MySQL/PostgreSQL，Filebeat采集用户日志，API同步第三方数据，统一写入Kafka；②ODS层：Kafka存储原始数据保留3-7天；③DWD层：Flink清洗去噪+维度退化+统一口径，写入Kafka和Paimon；④DWS层：Flink按主题轻度聚合，写入Paimon和ClickHouse；⑤DIM层：Flink CDC同步维度表存Paimon；⑥ADS层：StarRocks/ClickHouse提供高性能查询。

应用场景：实时大屏(GMV/订单/用户)、实时报表(多维分析)、实时风控(欺诈检测)、实时推荐(行为驱动)。

📌 关键知识点：实时数仓分层与离线数仓的核心差异——实时用Kafka+Paimon替代HDFS+Hive；DIM层必须实时同步否则维度关联延迟；ClickHouse/StarRocks做OLAP加速
⚠️ 易错点：实时数仓不是把离线数仓搬一遍到实时——ODS层用Kafka而非HDFS是关键差异；维度表如果用T+1同步，实时指标会因维度缺失而不准确

大数据处理中数据倾斜是最常见的问题，请给出完整的识别和解决方案。包括Spark和Flink两种引擎下的不同处理策略。

---

🤖 AI解析：
识别方法：①Spark UI/Flink UI查看Task执行时间，找特别长的；②查看数据分布，找数据量特别大的Key；③查看Shuffle数据量，找Reducer数据量特别大的。

六大解决方案：①过滤空值/异常值——倾斜由大量空值引起时直接过滤；②随机前缀法(Salting)——给倾斜Key加随机前缀分散到多Reducer，再全局聚合；③分阶段聚合——先局部聚合减数据量再全局聚合；④广播小表——Join倾斜时小表broadcast避免Shuffle；⑤动态分区——根据数据分布动态调整分区数；⑥引擎内置优化——Spark的skew join hint和AQE，Flink的倾斜Join优化。

Spark特有：reduceByKey替代groupByKey(Map端预聚合)；Flink特有：Local-Global聚合模式。

📌 关键知识点：先识别再解决——不同原因对应不同方案；Salting是最通用方案但需两步Join；AQE(Spark3.0+)可自动检测并拆分倾斜分区
⚠️ 易错点：不要一上来就说'加随机前缀'——要先定位是哪个Key倾斜、倾斜原因是什么；Salting后Join需两步(先加盐Join再去盐聚合)；AQE需spark.sql.adaptive.enabled=true

数据仓库为什么要分层？分层过多有什么问题？如何根据业务需求调整分层架构？2026年面试不再问'五层架构是什么'，而是问'你为什么这样分层'。

---

🤖 AI解析：
分层哲学：分层的本质是'关注点分离'——每层解决一个核心问题：ODS(原始数据保真)、DWD(明细数据清洗标准化)、DWS(汇总数据复用)、ADS(应用数据服务化)、DIM(公共维度统一)。过度分层的代价：①ETL链路变长延迟增大；②中间表暴增存储成本翻倍；③开发维护成本高、数据溯源难。

实时数仓分层差异：ODS→Kafka(而非HDFS)，DWD→Flink清洗+Paimon，DWS→Flink聚合+ClickHouse。什么情况可合并：DWD+DWS合并(数据量小、业务简单时)；ODS+DWD合并(数据源本身已清洗)。

📌 关键知识点：分层不是教条而是成本-收益权衡；实时数仓分层与离线的核心差异在存储层(Kafka vs HDFS)；过度分层比不分层更危险
⚠️ 易错点：不要背五层架构——面试官想知道的是你的分层决策逻辑；合并层级不等于偷懒——简单业务强套五层反而增加维护成本；实时数仓的ODS层不能省——原始数据是溯源的唯一保障

请详细阐述SCD1/SCD2/SCD3的定义、适用场景，以及在实时数仓中如何实现SCD2？SCD2的性能问题如何优化？

---

🤖 AI解析：
SCD类型：①SCD1(覆盖)——直接覆盖旧值，不保留历史，适用于数据修正、无需追溯变化的场景；②SCD2(新增行)——新增一行记录新值，用start_date/end_date标记有效期，保留完整历史，是最常用的方式；③SCD3(新增列)——增加一列存旧值，只保留前一次变化，适用于只需比较前后两次的场景。

实时数仓SCD2实现：Flink CDC捕获变更→双流JOIN+状态管理维护有效记录→写入Paimon的UPSERT表(主键+有效期)。性能优化：①Paimon的LSM-Tree天然支持高效UPSERT；②增量Checkpoint减少状态持久化开销；③分区剪枝按日期分区加速查询。

📌 关键知识点：SCD2是最常用但也是性能问题最多的方式；实时数仓用Paimon的UPSERT能力替代传统Hive的INSERT+OVERWRITE；end_date='9999-12-31'表示当前有效记录
⚠️ 易错点：SCD2在实时环境中的关键挑战是UPDATE性能——传统Hive不支持UPDATE必须全表覆盖；实时数仓中SCD2的版本链可能很长需定期归档历史版本

什么是数据契约？为什么说它是数据治理的新范式？数据契约包含哪些内容？如何在组织中推行数据契约？2026年大数据面试热点考点。

---

🤖 AI解析：
数据契约定义：数据生产者和消费者之间的正式协议，定义数据的结构、格式、质量标准和SLA。包含内容：①Schema定义(结构和字段类型)；②语义定义(业务含义和计算口径)；③质量标准(准确性/完整性/一致性要求)；④SLA(更新频率和延迟要求)；⑤所有权(生产者和负责人)。

实现方式：①代码生成——根据契约自动生成代码；②运行时检查——数据生产/消费时检查是否符合契约；③监控告警——违反契约自动告警；④版本管理——管理契约的版本变化。

推行策略：先从小范围试点→证明价值→管理层支持→全组织推广→建立激励机制。

📌 关键知识点：数据契约是数据治理从'事后补救'到'事前预防'的关键转变；契约的核心是'协议'而非'文档'——必须有自动化检查和告警；推行数据契约是组织问题而非纯技术问题
⚠️ 易错点：数据契约≠文档——没有自动化检查的契约只是纸上谈兵；推行不能一步到位——先从最痛的数据质量问题入手；契约版本管理经常被忽略但它是避免breaking change的关键

Flink SQL支持Append-only、Retract、Upsert三种流类型，它们的区别是什么？各自适用于什么场景？Retract流和Upsert流在实现聚合时有什么差异？

---

🤖 AI解析：
三种流类型：①Append-only流——只有INSERT操作，没有UPDATE/DELETE，适用于日志/事件等不可变数据，最简单性能最好；②Retract流——包含INSERT和撤回(DELETE+INSERT)，当聚合结果更新时先撤回旧结果再插入新结果，适用于无主键的聚合场景(如GROUP BY无唯一键)；③Upsert流——包含INSERT和UPDATE，基于主键判断：有则UPDATE，无则INSERT，适用于CDC数据/有主键维度表等场景，性能优于Retract(一条UPDATE vs 一条DELETE+INSERT)。

聚合实现差异：Retract流——聚合结果变化时发送[DELETE旧值, INSERT新值]两条消息；Upsert流——聚合结果变化时只发送一条UPDATE消息(基于主键)。Upsert性能更优但必须有主键。

📌 关键知识点：Upsert流是Flink SQL中最常用的流类型(有主键场景)；Retract流的撤回机制会导致下游收到两条消息需特殊处理；CDC数据天然是Upsert流
⚠️ 易错点：Retract流的撤回消息不能忽略——下游必须正确处理+I/-D消息对；Upsert流必须有主键否则退化为Retract流；聚合结果频繁更新时Retract流的消息量是Upsert的两倍

Flink的Checkpoint和Savepoint有什么核心区别？90%的候选人无法精准说清。它们在触发方式、用途、生命周期、格式和增量支持上有什么不同？

---

🤖 AI解析：
五大维度对比：①触发方式——Checkpoint=引擎自动按预设间隔触发，Savepoint=用户手动执行命令触发；②核心用途——Checkpoint=故障自动恢复保证运行可靠性，Savepoint=作业升级/版本迁移/集群重启/暂停恢复；③生命周期——Checkpoint=与作业绑定，作业停止后默认删除，Savepoint=用户管理，永久保存在分布式文件系统除非手动删除；④格式——Checkpoint=针对快速恢复优化，格式紧凑与状态后端绑定，Savepoint=标准化格式，不绑定状态后端，支持跨版本/跨集群恢复；⑤增量支持——Checkpoint=支持增量Checkpoint(只持久化差异)，Savepoint=仅支持全量持久化。

生产实践：Checkpoint间隔不宜太短(影响吞吐)也不宜太长(影响恢复速度)，通常30s-3min。版本升级必须先做Savepoint再停作业。

📌 关键知识点：Checkpoint=自动故障恢复(轻量+增量)，Savepoint=人工版本管理(全量+标准格式)；Savepoint是唯一支持跨版本恢复的机制；生产环境必须两者结合使用
⚠️ 易错点：作业停止后Checkpoint默认删除——重要状态变更前必须手动Savepoint；Savepoint是全量的做一次很慢不能频繁执行；从Savepoint恢复时如果改了算子拓扑可能不兼容需检查

数据仓库中三种事实表(事务型/周期型快照/累积型快照)的区别与适用场景？重点讲解累积型快照事实表的设计技巧和回退/异常处理。

---

🤖 AI解析：
三种事实表：①事务型事实表——记录每次业务事件(如下单/支付)，一行=一个事件，适用于业务过程分析、漏斗转化；②周期型快照事实表——按固定周期记录状态(如每日余额/每日库存)，一行=一个实体一个周期，适用于趋势分析、同环比；③累积型快照事实表——记录业务全生命周期的关键节点(如订单从创建→支付→发货→签收)，一行=一个完整流程，适用于流程分析、SLA监控、瓶颈定位。

累积型快照设计：字段包含所有关键节点时间(order_time/pay_time/ship_time/receive_time)，中间状态用NULL填充。回退/异常处理：①逆向流程(退货)用额外字段或独立事实表；②超时未完成的流程设置告警阈值；③事实表支持UPDATE(实时数仓用Paimon UPSERT)。

📌 关键知识点：累积型快照事实表是业务生命周期分析的核心——也是面试中最容易暴露薄弱环节的考点；实时数仓用Paimon的UPSERT能力替代传统Hive的全表覆盖
⚠️ 易错点：累积型快照事实表不适合高频变更场景——每次变更都需UPDATE全行；业务回退(退货/取消)不能简单删除记录——需保留历史轨迹；事实表粒度选择错误会导致分析结果完全错误

## 题目描述
记录直播平台主播上播及下播时间，计算出平台最高峰同时直播人数。

## 表结构
live_broadcast(anchor_id INT, start_time DATETIME, end_time DATETIME)

## 字段说明
- anchor_id: 主播ID
- start_time: 上播时间
- end_time: 下播时间

## 示例
anchor_id=1: 08:00-10:00, id=2: 09:00-12:00, id=3: 09:30-11:00
09:30-10:00 同时有3人直播，峰值为3

## 解题思路
1. 上播事件标记+1，下播事件标记-1
2. UNION ALL 展开为事件流
3. 按时间排序，SUM() OVER 累计在线人数
4. 取 MAX 即为峰值

## 参考答案
WITH events AS (
   SELECT start_time AS ts, 1 AS cnt FROM live_broadcast
   UNION ALL
   SELECT end_time, -1 FROM live_broadcast
),
ordered AS (
   SELECT ts, SUM(cnt) OVER (ORDER BY ts, cnt DESC) as online_cnt
   FROM events
)
SELECT MAX(online_cnt) as peak_concurrent FROM ordered;

存储过程就像我们编程语言中的函数一样，封装了我们的代码(PLSQL、T-SQL)。 上面的文字我们肯定是看不懂的，也不愿意看下去的。接下来我就总结一下： 学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的 第二范式：满足第一范式,表…

例如上述 Employee 表，n = 2 时，应返回第二高的薪水 200。如果不存在第 n 高的薪水，那么查询应返回 null。 编写一个 SQL 查询来实现分数排名。如果两个分数相同，则两个分数排名（Rank）相同。请注意，平分后的下一个名次应该是下一个连续的整数值。换句话…

使用group by的sql语句，select后的字段只能是group by后的字段，如果需要展示其他字段数据，需要给该列使用聚合函数，否则默认展示分组后的第一行数据。 左连接：左表的记录将会全部表示出来，而右表只会显示符合搜索条件的记录。右表记录不足的地方均为NULL（用户信…

SQL（结构化查询语言）是一种设计用于检索和操作数据的数据库。它属于美国国家标准协会（ANSI）的一种标准，可用于执行Select（选择）、Update（更新）、Delete（删除）和Insert（插入）等数据任务。 表是在具有列和行的模型中设计的数据集合。在表中，指定了列数称…

😊：“读题，入职时候的薪水，加上提示一个员工有多次涨薪的情况，所以本质上是求解每个员工的最低薪水，还要按照emp_no降序排列。阿，求每个员工的薪水最小值，用group by就可以实现，要输出的字段在salaries这张表中都有，所以别看他给了2张表，只需要1张表就能算出结果。1...

Sql常用语法下列语句部分是Mssql语句，不可以在access中使用。 SQL分类： DDL—数据定义语言(CREATE，ALTER，DROP，DECLARE) DML—数据操纵语言(SELECT，

1/连续最长登陆天数 2/下一次登陆时间距离上一次登陆时间大于30天时，从1开始计数 3/一张包含全国各城市用户的观看记录表view_info（表中一条数据代表一次观看记录），包含city_name、

MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引。 MySQL官方对索引的定义为：索引（In…

面试官：要不你来讲讲你们对MySQL是怎么调优的？ 候选者：哇，这命题很大阿…我认为，对于开发者而言，对MySQL的调优重点一般是在「开发规范」、「数据库索引」又或者说解决线上慢查询上。 候选者：而对

这天我正在午休呢，公司DBA就把我喊醒了，说某库出现大量慢SQL，很快啊，很快，我还没反应过来，库就挂了，我心想现在的用户不讲武德啊，怎么在我睡觉的时候大量请求呢。 这是很常见的一个场景哈，因为很多业务开始数据量级不大，所以写sql的时候就没注意性能，等量级上去，很多业务就需要…

敖丙：加索引。 敖丙：没了。 哈哈开头这个场景是我臆想的一个面试场景，但是大家是不是觉得很真实，每个人的简历上但凡写到了数据库，都会在后面顺便写一句，会数据库调优。 我觉得调优能回答的点还是很多很多的，我自己看了《MySQL实战》、《高性能MySQL》、《丁奇MySQL47讲》…

一、前言 上一篇我们说了 腾讯一面：说一说 MySQL 中索引的底层原理，相信你对索引有个很清晰的认识了，这一篇我们来说一说慢 SQL 的排查以及调优。为啥面试官要问这个问题，其实跟上一篇的索引底层原

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

大家好，我是 V 哥。SQL调优对于提升数据库查询性能至关重要，特别是当数据量大时。以下是20个详细的SQL调优指南和高级技巧，结合案例说明，帮助优化SQL查询的性能。 1. 选择合适的索引 技巧: 

一次线上慢SQL调优分享 一周前，客户反馈做题页面经常卡顿，加载慢；我们监控比较少，所以根据直觉去MySQL慢查询日志一看，果然是一条慢SQL。废话不多，开整！！！ 业务背景 一个在线做题的代码评测系

作为开发人员，我们免不了与sql打交道。有些sql可能在业务的最开始，执行是毫无问题的。但是随着业务量的提升以及业务复杂度的加深，可能之前的sql就会逐渐展现出疲惫之势了。这时就会面临sql调优。 那么调优到底如何调？不同的人有不同的姿势。可能大部分人首先想到的就是加索引。 没…

order by字段尽量走索引... 其中有些手段也许跟随者MySQL版本的升级过时了。我们真的需要背这些调优手段吗？我觉得是没有必要的，在掌握MySQL存储架构和SQL执行原理的情况下，我们就很自然的明白，为什么要提议这么优化了，甚至能够发现别人提的不太合理的优化手段。 在 …

背景 基于TPCDS的100G，500G数据进行了99SQL综合调优测试 测试机为物理机5台，1台为管理节点，4台为计算节点 可用内存约1T，核心数（vCore）200大概 重要参数 执行器个数 --

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第3天，点击查看活动详情 1.写在前面 在昨天的时候，我们就谈到了数据库连接池优化 详情可参考这里：点击查看 经过昨天的分析，我们已

面试官：MySQL如何进行性能调优？ 具体操作我这里整理了慢查询、explain、@@profiling关键字 慢查询 DBA有时候会发现有些语句比较慢，他们怎么发现的呢？ 编辑配置文件打开慢查询 然

在系统运行过程中，总会与数据库的交互，通过数据库端的日志查询执行时间最长与执行次数最多的sql语句，就可以有针对性的进行调优处理。 取执行时间最长的前50条sql语句。

引言 数据库性能优化是每个后端程序猿必备的基础技能之一，而Mysql中的explain堪称Mysql的性能优化分析神器，我们可以通过它来分析SQL语句的对应的执行计划在Mysql底层到底是如何执行的，

这几周系统访问量也是居高不下，不出意外系统又出现瓶颈了，大量用户反馈判题结果响应太慢；经排查，又是关于SQL的问题 业务背景 一个类似于力扣在线做题的代码评测模块，用户提交判题任务后，后台会进行异步判

什么是 SQL 调优？是不是觉得自己知道但又很模糊说不清楚，面试被问没有真实的案例，并不具备说服力。本文以为详细案例给大家解读。

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

Spark SQL是Spark生态系统中非常重要的组件， 能够利用 Spark 进行结构化的存储和操作。本文将围绕Spark内存泄露问题进行排查，并且给出具体的Spark调优方法。

Hive的架构 Hive元数据默认存储在derby数据库，不支持多客户端访问，所以将元数据存储在MySQl，支持多客户端访问。 2 Hive和e和数据库比较，Hive 和数据库除了拥有类似的查询语言，

1. hive 内部表和外部表的区别？ 未被external修饰的是内部表（managed table），被external修饰的为外部表（external table）； 内部表数据由Hive自身管

Hive SQL基本上适用大数据领域离线数据处理的大部分场景。Hive SQL的优化也是我们必须掌握的技能，而且，面试一定会问。那么，我希望面试者能答出其中的80%优化点，在这个问题上才算过关。 JVM重利用可以使得JOB长时间保留slot,直到作业结束，这在对于有较多任务和较…

第一题 需求 实现 数据准备 查询SQL 第二题 需求 实现 数据准备 查询SQL实现 第三题 需求 实现 数据准备 查询SQL 第四题 需求 实现 数据准备 查询SQL 第五题 需求 实现 数据准备

有用户点击日志记录表 t_click_log_025，包含user_id(用户ID),click_time(点击时间)，请查询出连续点击三次的用户数。

1.Hive的架构 2 Hive和数据库比较 Hive 和数据库除了拥有类似的查询语言，再无类似之处。 1）数据存储位置 Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。 2

有如下数据，记录每天每只股票的收盘价格，请查出每只股票的波峰和波谷的日期和价格；
波峰：股票价格高于前一天和后一天价格时为波峰；
波谷：股票价格低于前一天和后一天价格时为波谷。

---

🤖 AI解析：
思路：使用LEAD/LAG窗口函数获取前一天和后一天价格，再比较。
1. LAG(closing_price,1) OVER(PARTITION BY stock_code ORDER BY trade_date) 获取前日价格
2. LEAD(closing_price,1) OVER(...) 获取后日价格
3. WHERE当前价>前日价 AND 当前价>后日价 → 波峰；当前价<前日价 AND 当前价<后日价 → 波谷

📌 关键知识点：LAG/LEAD窗口函数、PARTITION BY按股票分组、边界处理（首尾无前/后日数据）
⚠️ 易错点：首尾交易日无法判断波峰波谷需排除；注意等价情况不算波峰/波谷

已知有表记录了每个大厅的活动开始日期和结束日期，每个大厅可以有多个活动。
请编写一个SQL查询合并在同一个大厅举行的所有重叠的活动，如果两个活动至少有一天相同，那他们就是重叠的。

---

🤖 AI解析：
思路：使用窗口函数标记重叠区间，然后合并。
1. 按hall_id和start_date排序
2. 如果当前行的start_date <= 上一行的end_date，则重叠，合并
3. 使用LAG获取上一行end_date，判断是否重叠
4. 对非重叠的行标记为新组，GROUP BY组合并取MIN(start_date)和MAX(end_date)

📌 关键知识点：区间合并、LAG窗口函数、分组标记技巧
⚠️ 易错点：注意活动可能多次重叠形成长区间；日期是否含边界需确认

现有订单表t_order，包含订单ID，订单时间，下单用户，当前订单是否有效。
查询每个用户最近一笔有效订单。

---

🤖 AI解析：
思路：过滤有效订单后按用户分组取最新一条。
1. WHERE is_valid = 1 过滤有效订单
2. ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_time DESC) = 1
取每个用户最近一条

📌 关键知识点：ROW_NUMBER窗口函数、PARTITION BY用户分组、过滤条件优先于排序
⚠️ 易错点：注意先过滤有效再排序；如果同一时间有多笔需定义二级排序规则

现有用户登录日志表，记录了每个用户登录的IP地址，请查询共同使用过3个及以上IP的用户对。

---

🤖 AI解析：
思路：先找共用IP的用户对，再筛选>=3个IP的对。
1. 自连接登录表找同一IP的不同用户对(user_a < user_b)
2. GROUP BY用户对COUNT(DISTINCT ip)
3. HAVING COUNT(DISTINCT ip) >= 3

📌 关键知识点：自连接找用户对、COUNT DISTINCT去重、HAVING过滤
⚠️ 易错点：自连接时避免重复组合(a,b)和(b,a)；用户对要用较小id+较大id组合去重

现有各省地级市的gdp数据,求从高到底累加刚好超过各省GDP40%的地市名称，临界地市也需要。
例如:浙江省的杭州24% 宁波20%,杭州+宁波=44%大于40%,取出杭州、宁波。

---

🤖 AI解析：
思路：计算累计占比，找出刚好超过40%的临界点。
1. 按省份分组，地市按GDP降序排列
2. SUM(gdp) OVER(PARTITION BY province ORDER BY gdp DESC) 计算累计GDP
3. SUM(gdp) OVER(PARTITION BY province) 计算省总GDP
4. 累计GDP/省总GDP <= 0.4 的全部取，加上第一个超过0.4的地市

📌 关键知识点：窗口函数累计求和、百分比计算、临界值处理
⚠️ 易错点：临界地市必须包含（刚好超过的那一条）；注意浮点数精度问题

有一张表t_id记录了id，id不重复，但是会存在间断，求出连续段的起始位置和结束位置。

---

🤖 AI解析：
思路：用id减去行号得到分组标识，连续id的差值相同。
1. ROW_NUMBER() OVER(ORDER BY id) 生成行号rn
2. group_key = id - rn，连续的id会得到相同group_key
3. GROUP BY group_key，取MIN(id)和MAX(id)即为连续段的起止位置

📌 关键知识点：id减行号的经典技巧、连续区间检测、分组聚合
⚠️ 易错点：确保id无重复（题意已说明）；行号从1开始，id和rn的差值要一致

有一张表t_id记录了id，id不重复，但是会存在间断，求出连续段的最后一个数及每个连续段的个数。

---

🤖 AI解析：
思路：同上用id-rn分组，再聚合。
1. id - ROW_NUMBER() OVER(ORDER BY id) 作为group_key
2. GROUP BY group_key
3. MAX(id)为连续段最后一个数，COUNT(*)为连续段个数

📌 关键知识点：连续区间分组技巧、GROUP BY聚合
⚠️ 易错点：注意连续段个数的定义是包含的id数量

有营销活动记录表，记录了每个品牌每次营销活动的开始日期和结束日期，现需要统计出每个品牌的总营销天数。
注意：重叠的日期要去重计算；不连续的日期不统计。

---

🤖 AI解析：
思路：先合并重叠日期区间，再计算每个区间的天数求和。
1. 按品牌分组，活动按开始日期排序
2. 如果当前行start_date <= 上一行end_date，则重叠，合并
3. 对合并后的区间计算(end_date - start_date + 1)天数
4. SUM各区间天数

📌 关键知识点：区间合并、日期差计算、重叠去重
⚠️ 易错点：重叠部分只算一次；不连续的区间之间不算天数（如9月7日和9月8日中间不算）

已知有购买记录表t_order和用户收藏记录表t_collect_log，请用一句sql语句得出所有用户的商品行为特征：
是否已购买、购买未收藏、收藏未购买、收藏且购买。

---

🤖 AI解析：
思路：全外连接购买表和收藏表，根据是否有购买/收藏记录判断行为特征。
1. FULL OUTER JOIN t_order和t_collect_log ON user_id, goods_id
2. CASE WHEN判断：有购买有收藏→收藏且购买；有购买无收藏→购买未收藏；无购买有收藏→收藏未购买；无购买无收藏→不可能（不会出现在JOIN结果中）

📌 关键知识点：FULL OUTER JOIN、CASE WHEN多条件判断、行为特征分类
⚠️ 易错点：注意用FULL OUTER JOIN而非LEFT/RIGHT JOIN；需要处理NULL值判断

现有一张订单表t_order有订单ID、用户ID、商品ID、购买商品数量、购买时间，请查询出每个用户的第一条记录和最后一条记录。

---

🤖 AI解析：
思路：使用ROW_NUMBER窗口函数分别按时间升序和降序排序。
1. ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY purchase_time ASC) rn_asc
2. ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY purchase_time DESC) rn_desc
3. WHERE rn_asc = 1 OR rn_desc = 1

📌 关键知识点：ROW_NUMBER窗口函数、PARTITION BY分组、双向排序
⚠️ 易错点：如果只有一条记录则第一条和最后一条相同，用UNION或OR去重

现有三张表：用户关注表t_follow(user_id,follower_id)，请给用户1推荐他关注的用户喜欢的音乐名称。

---

🤖 AI解析：
思路：找用户1关注的人喜欢的音乐，排除用户1已经喜欢的。
1. 从t_follow找用户1关注的人(follower_id)
2. 从t_music_likes找这些人喜欢的音乐
3. NOT IN排除用户1已喜欢的音乐

📌 关键知识点：多表JOIN、NOT IN/NOT EXISTS排除已存在记录、好友推荐逻辑
⚠️ 易错点：注意去重（多个好友可能喜欢同一首歌）；排除用户已喜欢的歌

有两个表，朋友关系表user_friend，用户步数表user_steps。查询占据多少个好友的封面（在好友的列表中排行第一，且必须超过好友的步数）。

---

🤖 AI解析：
思路：计算用户步数在好友步数中排第一的数量。
1. JOIN朋友关系表和步数表两次（自己和好友的步数）
2. WHERE自己的步数 > 好友的步数，且自己在好友好友列表中排第一
3. COUNT

📌 关键知识点：自关联JOIN、排名比较、子查询
⚠️ 易错点：好友关系是双向的需考虑；排第一必须超过好友步数而非等于

现有一张用户支付表t_user_pay包含字段订单ID,用户ID,商户ID,支付时间,支付金额。
如果同一用户在同一商户存在多笔订单，且中间该用户没有其他商户的支付记录，则认为是连续订单，
请把连续订单进行合并，时间取最早支付时间，金额求和。

---

🤖 AI解析：
思路：标记同一商户的连续订单，再分组聚合。
1. 按用户ID、支付时间排序
2. 检测商户ID是否变化：LAG(merchant_id) != 当前merchant_id时标记为新组
3. 累计标记形成组ID
4. GROUP BY用户ID、组ID，取MIN(支付时间)和SUM(支付金额)

📌 关键知识点：LAG检测变化、累计标记分组、连续区间识别
⚠️ 易错点：连续是指同一商户中间没有其他商户；非连续的同商户订单不合并

现有一张股票价格表stock_data有3个字段：股票代码(stock_code),日期(trade_date)，收盘价格(closing_price)，
请找出满足连续5天以上（含）每天上涨超过5%的股票,并给出连续满足天数及开始和结束日期。

---

🤖 AI解析：
思路：计算每日涨幅，标记是否>5%，然后检测连续满足条件的天数。
1. 计算涨幅：(closing_price - LAG(closing_price)) / LAG(closing_price)
2. 标记涨幅>5%为1否则为0
3. 用经典连续区间技巧（行号-分组行号）找连续为1的段
4. HAVING COUNT(*) >= 5

📌 关键知识点：涨幅计算、连续区间检测、条件标记+分组
⚠️ 易错点：涨幅=(今-昨)/昨；连续5天含第5天；注意停牌等特殊情况题意已说明不考虑

现有用户登录日志表t_login_log,包含用户ID(user_id),登录日期(login_date)。
数据已经按照用户日期去重，请查出连续登录超过4天的用户ID。

---

🤖 AI解析：
思路：经典连续区间问题，用login_date减行号分组。
1. ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) rn
2. group_key = login_date - rn（用DATE_SUB或整数天数差）
3. GROUP BY user_id, group_key HAVING COUNT(*) > 4
4. DISTINCT user_id

📌 关键知识点：日期减行号的连续区间技巧、DATE_SUB处理日期、HAVING过滤
⚠️ 易错点：login_date是日期类型不能直接减整数，需先转天数；题目说已去重不需再DISTINCT日期

有某城市网吧上网记录表，包含网吧id、访客id、上线时间、下线时间。
规则1：两个用户在同一个网吧上线或下线时间间隔10分钟以内，则可能认识；
规则2：在三家以上网吧出现规则1情况，则一定认识。计算两人一定认识的组合数。

---

🤖 AI解析：
此题考察大数据/SQL核心知识点，需结合业务场景分析。建议从原理→实现→优化三步作答。

📌 关键知识点：原理理解、实现方案、优化策略
⚠️ 易错点：注意边界条件和性能影响

有一份用户访问记录表，记录用户id和访问时间，如果用户访问时间间隔小于60s则认为是一次浏览，请合并用户的浏览行为。

---

🤖 AI解析：
此题考察大数据/SQL核心知识点，需结合业务场景分析。建议从原理→实现→优化三步作答。

📌 关键知识点：原理理解、实现方案、优化策略
⚠️ 易错点：注意边界条件和性能影响

已知有表t_cost_detail包含id和money两列，id为自增，请累加计算money值，并求出累加值与1000差值最小的记录。

---

🤖 AI解析：
此题考察大数据/SQL核心知识点，需结合业务场景分析。建议从原理→实现→优化三步作答。

📌 关键知识点：原理理解、实现方案、优化策略
⚠️ 易错点：注意边界条件和性能影响

已知有表记录了每个大厅的活动开始日期和结束日期，每个大厅可以有多个活动。请编写SQL查询合并同一大厅的所有重叠活动。

---

🤖 AI解析：
思路：使用窗口函数标记重叠区间，然后合并。
1. 按hall_id和start_date排序
2. 如果当前行的start_date <= 上一行的end_date，则重叠，合并
3. 使用LAG获取上一行end_date，判断是否重叠
4. 对非重叠的行标记为新组，GROUP BY组合并取MIN(start_date)和MAX(end_date)

📌 关键知识点：区间合并、LAG窗口函数、分组标记技巧
⚠️ 易错点：注意活动可能多次重叠形成长区间；日期是否含边界需确认

## 题目描述

用户登录日志表，记录用户每天的登录日期。请查出连续登录超过4天的用户ID及起止日期。

## 表结构

```sql
CREATE TABLE t_login_log (
  user_id    INT,
  login_date DATE
);
```

## 示例数据

| user_id | login_date  |
|---------|-------------|
| 1       | 2024-01-01  |
| 1       | 2024-01-02  |
| 1       | 2024-01-03  |
| 1       | 2024-01-04  |
| 1       | 2024-01-05  |
| 2       | 2024-01-01  |
| 2       | 2024-01-03  |
| 2       | 2024-01-04  |
| 2       | 2024-01-05  |
| 3       | 2024-01-01  |
| 3       | 2024-01-02  |
| 3       | 2024-01-03  |
| 3       | 2024-01-04  |
| 3       | 2024-01-05  |
| 3       | 2024-01-06  |

## 期望输出

| user_id | start_date | end_date   | days |
|---------|------------|------------|------|
| 1       | 2024-01-01 | 2024-01-05 | 5    |
| 3       | 2024-01-01 | 2024-01-06 | 6    |

## 参考SQL

```sql
SELECT user_id,
       MIN(login_date) AS start_date,
       MAX(login_date) AS end_date,
       COUNT(*) AS days
FROM (
  SELECT user_id, login_date,
         DATE_SUB(login_date, INTERVAL ROW_NUMBER()
           OVER(PARTITION BY user_id ORDER BY login_date) DAY) AS grp
  FROM (SELECT DISTINCT user_id, login_date FROM t_login_log) t
) t2
GROUP BY user_id, grp
HAVING COUNT(*) > 4;
```

**核心思路**：login_date - ROW_NUMBER() 相同的行属于同一段连续登录

## 题目描述

用户登录记录表，以用户最早登录日期为注册日，计算次日留存率和7日留存率。

## 表结构

```sql
CREATE TABLE t_user_login (
  user_id    INT,
  login_date DATE
);
```

## 示例数据

| user_id | login_date  |
|---------|-------------|
| 1       | 2024-01-01  |
| 1       | 2024-01-02  |
| 1       | 2024-01-08  |
| 2       | 2024-01-01  |
| 3       | 2024-01-01  |
| 3       | 2024-01-02  |
| 3       | 2024-01-09  |
| 4       | 2024-01-01  |
| 4       | 2024-01-02  |

## 期望输出

| reg_date   | new_users | d1_retained | d1_rate | d7_retained | d7_rate |
|------------|-----------|-------------|---------|-------------|---------|
| 2024-01-01 | 4         | 3           | 75.00%  | 2           | 50.00%  |

## 参考SQL

```sql
WITH first_login AS (
  SELECT user_id, MIN(login_date) AS reg_date
  FROM t_user_login GROUP BY user_id
)
SELECT f.reg_date,
       COUNT(DISTINCT f.user_id) AS new_users,
       COUNT(DISTINCT CASE WHEN l.login_date = DATE_ADD(f.reg_date, INTERVAL 1 DAY) THEN f.user_id END) AS d1_retained,
       COUNT(DISTINCT CASE WHEN l.login_date = DATE_ADD(f.reg_date, INTERVAL 7 DAY) THEN f.user_id END) AS d7_retained
FROM first_login f
LEFT JOIN t_user_login l ON f.user_id = l.user_id
GROUP BY f.reg_date;
```

**核心思路**：找首次登录=注册日 → LEFT JOIN所有登录 → CASE WHEN判断N日后是否回访

## 题目描述

每个大厅有多个活动，起止日期可能重叠。合并同一大厅所有重叠的活动区间。

## 表结构

```sql
CREATE TABLE t_hall_activity (
  hall_id     INT,
  activity_id INT,
  start_date  DATE,
  end_date    DATE
);
```

## 示例数据

| hall_id | activity_id | start_date | end_date   |
|---------|-------------|------------|------------|
| 1       | 101         | 2024-01-01 | 2024-01-05 |
| 1       | 102         | 2024-01-04 | 2024-01-10 |
| 1       | 103         | 2024-01-15 | 2024-01-20 |
| 2       | 201         | 2024-01-01 | 2024-01-03 |

## 期望输出

| hall_id | merged_start | merged_end |
|---------|-------------|------------|
| 1       | 2024-01-01  | 2024-01-10 |
| 1       | 2024-01-15  | 2024-01-20 |
| 2       | 2024-01-01  | 2024-01-03 |

## 参考SQL

```sql
SELECT hall_id,
       MIN(start_date) AS merged_start,
       MAX(end_date)   AS merged_end
FROM (
  SELECT *,
    SUM(CASE WHEN start_date <= prev_end THEN 0 ELSE 1 END)
      OVER(PARTITION BY hall_id ORDER BY start_date) AS grp
  FROM (
    SELECT *,
      MAX(end_date) OVER(PARTITION BY hall_id ORDER BY start_date
        ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS prev_end
    FROM t_hall_activity
  ) t1
) t2
GROUP BY hall_id, grp;
```

**核心思路**：排序→判断当前开始<=前一结束→标记新分组→分组取MIN/MAX

## 题目描述

记录每天每只股票收盘价格，查出波峰(高于前后两天)和波谷(低于前后两天)。

## 表结构

```sql
CREATE TABLE t_stock_price (
  stock_code    VARCHAR(10),
  trade_date    DATE,
  closing_price DECIMAL(10,2)
);
```

## 示例数据

| stock_code | trade_date  | closing_price |
|------------|-------------|---------------|
| A          | 2024-01-01  | 10.00         |
| A          | 2024-01-02  | 15.00         |
| A          | 2024-01-03  | 12.00         |
| A          | 2024-01-04  | 8.00          |
| A          | 2024-01-05  | 11.00         |

## 期望输出

| stock_code | trade_date  | closing_price | type |
|------------|-------------|---------------|------|
| A          | 2024-01-02  | 15.00         | peak |
| A          | 2024-01-04  | 8.00          | valley |

## 参考SQL

```sql
SELECT stock_code, trade_date, closing_price,
       CASE WHEN closing_price > prev AND closing_price > nxt THEN 'peak'
            WHEN closing_price < prev AND closing_price < nxt THEN 'valley' END AS type
FROM (
  SELECT *, LAG(closing_price) OVER(PARTITION BY stock_code ORDER BY trade_date) AS prev,
           LEAD(closing_price) OVER(PARTITION BY stock_code ORDER BY trade_date) AS nxt
  FROM t_stock_price
) t
WHERE (closing_price > prev AND closing_price > nxt)
   OR (closing_price < prev AND closing_price < nxt);
```

**核心思路**：LAG/LEAD取前后价格，比较判断波峰/波谷

## 题目描述

表t_cost_detail包含id和money，按id顺序累加money，求累加值与1000差值最小的记录。

## 表结构

```sql
CREATE TABLE t_cost_detail (
  id    INT PRIMARY KEY,
  money DECIMAL(10,2)
);
```

## 示例数据

| id | money |
|----|-------|
| 1  | 200   |
| 2  | 300   |
| 3  | 400   |
| 4  | 150   |
| 5  | 100   |

## 期望输出

| id | money | cumulative | diff |
|----|-------|------------|------|
| 4  | 150   | 1050       | 50   |

## 参考SQL

```sql
SELECT id, money, cumulative, ABS(cumulative - 1000) AS diff
FROM (
  SELECT id, money, SUM(money) OVER(ORDER BY id) AS cumulative
  FROM t_cost_detail
) t
ORDER BY diff LIMIT 1;
```

**核心思路**：窗口SUM累计求和→ABS差值→排序取最小

## 题目描述

表t_id记录id，id不重复但存在间断，求连续段的起始、结束位置及每段个数。

## 表结构

```sql
CREATE TABLE t_id (
  id INT PRIMARY KEY
);
```

## 示例数据

| id |
|----|
| 1  |
| 2  |
| 3  |
| 5  |
| 6  |
| 8  |
| 9  |
| 10 |

## 期望输出

| start_id | end_id | count |
|----------|--------|-------|
| 1        | 3      | 3     |
| 5        | 6      | 2     |
| 8        | 10     | 3     |

## 参考SQL

```sql
SELECT MIN(id) AS start_id, MAX(id) AS end_id, COUNT(*) AS count
FROM (
  SELECT id, id - ROW_NUMBER() OVER(ORDER BY id) AS grp
  FROM t_id
) t
GROUP BY grp
ORDER BY start_id;
```

**核心思路**：id - ROW_NUMBER() 相同的行属于同一段连续区间

## 题目描述

用户操作行为表，统计A操作后紧接B操作的用户数。

## 表结构

```sql
CREATE TABLE t_act_log (
  user_id  INT,
  op_id    VARCHAR(10),
  op_time  DATETIME
);
```

## 示例数据

| user_id | op_id | op_time             |
|---------|-------|---------------------|
| 1       | A     | 2024-01-01 10:00:00 |
| 1       | B     | 2024-01-01 10:01:00 |
| 1       | D     | 2024-01-01 10:02:00 |
| 2       | A     | 2024-01-01 11:00:00 |
| 2       | C     | 2024-01-01 11:01:00 |
| 3       | A     | 2024-01-01 12:00:00 |
| 3       | B     | 2024-01-01 12:01:00 |

## 期望输出

| metric   | user_count |
|----------|------------|
| A紧接B   | 2          |

## 参考SQL

```sql
SELECT 'A紧接B' AS metric, COUNT(DISTINCT user_id) AS user_count
FROM (
  SELECT user_id, LEAD(op_id) OVER(PARTITION BY user_id ORDER BY op_time) AS next_op
  FROM t_act_log WHERE op_id = 'A'
) t WHERE next_op = 'B';
```

**核心思路**：LEAD取下一步操作，判断是否紧接B

## 题目描述

将学生成绩表从行格式(A,语文,90)转为列格式(A,语文=90,数学=85)，以及反向操作。

## 表结构

```sql
CREATE TABLE t_row_col (
  student VARCHAR(20),
  subject VARCHAR(20),
  score   INT
);
```

## 示例数据

| student | subject | score |
|---------|---------|-------|
| 张三    | 语文    | 90    |
| 张三    | 数学    | 85    |
| 李四    | 语文    | 88    |
| 李四    | 数学    | 92    |

## 期望输出（行转列）

| student | 语文 | 数学 |
|---------|------|------|
| 张三    | 90   | 85   |
| 李四    | 88   | 92   |

## 参考SQL（行转列）

```sql
SELECT student,
  MAX(CASE WHEN subject='语文' THEN score END) AS 语文,
  MAX(CASE WHEN subject='数学' THEN score END) AS 数学
FROM t_row_col GROUP BY student;
```

## 参考SQL（列转行）

```sql
SELECT student, '语文' AS subject, 语文 AS score FROM t_col_row WHERE 语文 IS NOT NULL
UNION ALL
SELECT student, '数学' AS subject, 数学 AS score FROM t_col_row WHERE 数学 IS NOT NULL;
```

**核心思路**：行转列用CASE WHEN+聚合；列转行用UNION ALL

## 题目描述

订单表，查询过去至少存在3天销售额连续增长的商户。

## 表结构

```sql
CREATE TABLE t_order (
  order_id   INT,
  shop_id    INT,
  order_time DATETIME,
  order_amt  DECIMAL(10,2)
);
```

## 示例数据（聚合后）

| shop_id | dt         | daily_sales |
|---------|------------|-------------|
| 1       | 2024-01-01 | 100         |
| 1       | 2024-01-02 | 120         |
| 1       | 2024-01-03 | 150         |
| 1       | 2024-01-04 | 130         |
| 2       | 2024-01-01 | 200         |
| 2       | 2024-01-02 | 180         |

## 期望输出

| shop_id | start_date | end_date   | days |
|---------|------------|------------|------|
| 1       | 2024-01-01 | 2024-01-03 | 3    |

## 参考SQL

```sql
WITH daily AS (
  SELECT shop_id, DATE(order_time) dt, SUM(order_amt) sales
  FROM t_order GROUP BY shop_id, DATE(order_time)
),
growth AS (
  SELECT *, CASE WHEN sales > LAG(sales) OVER(PARTITION BY shop_id ORDER BY dt) THEN 0 ELSE 1 END AS brk
  FROM daily
),
grp AS (
  SELECT *, SUM(brk) OVER(PARTITION BY shop_id ORDER BY dt) AS gid
  FROM growth
)
SELECT shop_id, MIN(dt) AS start_date, MAX(dt) AS end_date, COUNT(*) AS days
FROM grp GROUP BY shop_id, gid HAVING COUNT(*) >= 3;
```

**核心思路**：日聚合→LAG标记增长中断→累计分组→HAVING过滤

## 题目描述

员工薪资表，去除最高和最低薪资后计算平均薪水（部门人数>=3人才计算）。

## 表结构

```sql
CREATE TABLE t_salary (
  emp_id    INT,
  depart_id INT,
  salary    DECIMAL(10,2)
);
```

## 示例数据

| emp_id | depart_id | salary |
|--------|-----------|--------|
| 1      | 10        | 6000   |
| 2      | 10        | 8000   |
| 3      | 10        | 10000  |
| 4      | 10        | 12000  |
| 5      | 20        | 9000   |

## 期望输出

| depart_id | avg_salary |
|-----------|------------|
| 10        | 9000.00    |

**去掉6000和12000，剩余(8000+10000)/2=9000**

## 参考SQL

```sql
SELECT depart_id, ROUND(AVG(salary), 2) AS avg_salary
FROM (
  SELECT *,
    ROW_NUMBER() OVER(PARTITION BY depart_id ORDER BY salary) AS rn_asc,
    ROW_NUMBER() OVER(PARTITION BY depart_id ORDER BY salary DESC) AS rn_desc,
    COUNT(*) OVER(PARTITION BY depart_id) AS cnt
  FROM t_salary
) t
WHERE cnt >= 3 AND rn_asc > 1 AND rn_desc > 1
GROUP BY depart_id;
```

**核心思路**：正反ROW_NUMBER→排除rn=1的最高最低→剩余求平均

## 题目描述

同一用户同一商户的连续订单（中间无其他商户）合并，时间取最早，金额求和。

## 表结构

```sql
CREATE TABLE t_user_pay (
  order_id    INT,
  user_id     INT,
  merchant_id INT,
  pay_time    DATETIME,
  pay_amt     DECIMAL(10,2)
);
```

## 示例数据

| order_id | user_id | merchant_id | pay_time            | pay_amt |
|----------|---------|-------------|---------------------|---------|
| 1        | 100     | M1          | 2024-01-01 10:00:00 | 50      |
| 2        | 100     | M1          | 2024-01-01 10:05:00 | 30      |
| 3        | 100     | M2          | 2024-01-01 11:00:00 | 80      |
| 4        | 100     | M1          | 2024-01-01 12:00:00 | 60      |

## 期望输出

| user_id | merchant_id | start_time          | total_amt |
|---------|-------------|---------------------|-----------|
| 100     | M1          | 2024-01-01 10:00:00 | 80.00     |
| 100     | M2          | 2024-01-01 11:00:00 | 80.00     |
| 100     | M1          | 2024-01-01 12:00:00 | 60.00     |

## 参考SQL

```sql
SELECT user_id, merchant_id,
       MIN(pay_time) AS start_time,
       SUM(pay_amt) AS total_amt
FROM (
  SELECT *, SUM(CASE WHEN merchant_id = prev_m THEN 0 ELSE 1 END)
    OVER(PARTITION BY user_id ORDER BY pay_time) AS grp
  FROM (
    SELECT *, LAG(merchant_id) OVER(PARTITION BY user_id ORDER BY pay_time) AS prev_m
    FROM t_user_pay
  ) t1
) t2
GROUP BY user_id, grp, merchant_id;
```

**核心思路**：LAG判断是否与上一条同商户→标记分组→分组聚合

## 题目描述

各省地级市GDP数据，从高到低累加，找出刚好超过各省GDP 40%的地市（含临界城市）。

## 表结构

```sql
CREATE TABLE t_city_gdp (
  province VARCHAR(20),
  city     VARCHAR(20),
  gdp      DECIMAL(12,2)
);
```

## 示例数据

| province | city | gdp   |
|----------|------|-------|
| 浙江     | 杭州 | 2400  |
| 浙江     | 宁波 | 2000  |
| 浙江     | 温州 | 1000  |
| 江苏     | 苏州 | 1900  |
| 江苏     | 南京 | 1400  |
| 江苏     | 无锡 | 1200  |

## 期望输出

| province | city | gdp  | cumulative_pct |
|----------|------|------|----------------|
| 浙江     | 杭州 | 2400 | 44.4%          |
| 浙江     | 宁波 | 2000 | 81.5%          |
| 江苏     | 苏州 | 1900 | 42.2%          |
| 江苏     | 南京 | 1400 | 73.3%          |
| 江苏     | 无锡 | 1200 | 100.0%         |

**浙江GDP=5400，40%=2160，杭州2400已超→杭州入选**
**江苏GDP=4500，40%=1800，苏州1900已超→苏州入选，后续全部入选**

## 参考SQL

```sql
WITH total AS (
  SELECT province, SUM(gdp) AS tot FROM t_city_gdp GROUP BY province
),
cum AS (
  SELECT c.province, c.city, c.gdp,
    SUM(c.gdp) OVER(PARTITION BY c.province ORDER BY c.gdp DESC) AS cum_gdp,
    t.tot
  FROM t_city_gdp c JOIN total t USING(province)
)
SELECT province, city, gdp,
  ROUND(cum_gdp / tot * 100, 1) AS cumulative_pct
FROM cum
WHERE cum_gdp - gdp < tot * 0.4;
```

**核心思路**：窗口SUM累计，cum_gdp - gdp < 40% 表示加上本行后首次超过40%

## 题目描述

用户登录日志表记录每个用户登录的IP地址，查询共同使用过3个及以上IP的用户对。

## 表结构

```sql
CREATE TABLE t_user_ip (
  user_id   INT,
  ip_addr   VARCHAR(20),
  login_time DATETIME
);
```

## 示例数据

| user_id | ip_addr     | login_time          |
|---------|-------------|---------------------|
| 1       | 192.168.1.1 | 2024-01-01 08:00:00 |
| 1       | 192.168.1.2 | 2024-01-01 09:00:00 |
| 1       | 192.168.1.3 | 2024-01-01 10:00:00 |
| 2       | 192.168.1.1 | 2024-01-01 08:30:00 |
| 2       | 192.168.1.2 | 2024-01-01 09:30:00 |
| 2       | 192.168.1.3 | 2024-01-01 10:30:00 |
| 3       | 192.168.1.1 | 2024-01-01 11:00:00 |

## 期望输出

| user_a | user_b | shared_ips |
|--------|--------|------------|
| 1      | 2      | 3          |

## 参考SQL

```sql
SELECT a.user_id AS user_a, b.user_id AS user_b, COUNT(DISTINCT a.ip_addr) AS shared_ips
FROM t_user_ip a
JOIN t_user_ip b ON a.ip_addr = b.ip_addr AND a.user_id < b.user_id
GROUP BY a.user_id, b.user_id
HAVING COUNT(DISTINCT a.ip_addr) >= 3;
```

**核心思路**：自连接同一IP的不同用户 → GROUP BY用户对 → HAVING过滤共享IP数>=3

## 题目描述

营销活动记录表，统计每个品牌的总营销天数。重叠日期只算一次，不连续日期不补。

## 表结构

```sql
CREATE TABLE t_brand_campaign (
  brand_id   INT,
  campaign_id INT,
  start_date DATE,
  end_date   DATE
);
```

## 示例数据

| brand_id | campaign_id | start_date | end_date   |
|----------|-------------|------------|------------|
| 1        | 101         | 2024-01-01 | 2024-01-05 |
| 1        | 102         | 2024-01-04 | 2024-01-08 |
| 1        | 103         | 2024-01-15 | 2024-01-20 |
| 2        | 201         | 2024-01-01 | 2024-01-03 |

## 期望输出

| brand_id | total_days |
|----------|------------|
| 1        | 13         |
| 2        | 3          |

**品牌1：01-01~01-08共8天 + 01-15~01-20共6天 = 14天。去重后01-01~01-08(8)+01-15~01-20(6)=14? 不，01-01到01-08是8天，01-15到01-20是6天，共14天**

## 参考SQL

```sql
SELECT brand_id, SUM(DATEDIFF(merged_end, merged_start) + 1) AS total_days
FROM (
  SELECT brand_id,
    MIN(start_date) AS merged_start,
    MAX(end_date) AS merged_end
  FROM (
    SELECT *,
      SUM(CASE WHEN start_date <= prev_end THEN 0 ELSE 1 END)
        OVER(PARTITION BY brand_id ORDER BY start_date) AS grp
    FROM (
      SELECT *,
        MAX(end_date) OVER(PARTITION BY brand_id ORDER BY start_date
          ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS prev_end
      FROM t_brand_campaign
    ) t1
  ) t2
  GROUP BY brand_id, grp
) t3
GROUP BY brand_id;
```

**核心思路**：先合并重叠区间→DATEDIFF计算每段天数→SUM求总

## 题目描述

购买表和收藏表，分类用户商品行为：购买未收藏、收藏未购买、购买且收藏。

## 表结构

```sql
CREATE TABLE t_order (
  user_id  INT,
  goods_id INT,
  order_time DATETIME
);
CREATE TABLE t_collect (
  user_id    INT,
  goods_id   INT,
  collect_time DATETIME
);
```

## 示例数据

**t_order:**

| user_id | goods_id | order_time          |
|---------|----------|---------------------|
| 1       | 100      | 2024-01-01 10:00:00 |
| 1       | 200      | 2024-01-02 10:00:00 |
| 2       | 100      | 2024-01-01 11:00:00 |

**t_collect:**

| user_id | goods_id | collect_time        |
|---------|----------|---------------------|
| 1       | 100      | 2024-01-01 09:00:00 |
| 1       | 300      | 2024-01-03 09:00:00 |
| 2       | 200      | 2024-01-01 09:00:00 |

## 期望输出

| user_id | goods_id | behavior |
|---------|----------|----------|
| 1       | 100      | 购买且收藏 |
| 1       | 200      | 购买未收藏 |
| 1       | 300      | 收藏未购买 |
| 2       | 100      | 购买未收藏 |
| 2       | 200      | 收藏未购买 |

## 参考SQL

```sql
SELECT user_id, goods_id,
  CASE WHEN has_order = 1 AND has_collect = 1 THEN '购买且收藏'
       WHEN has_order = 1 THEN '购买未收藏'
       WHEN has_collect = 1 THEN '收藏未购买'
  END AS behavior
FROM (
  SELECT COALESCE(o.user_id, c.user_id) AS user_id,
    COALESCE(o.goods_id, c.goods_id) AS goods_id,
    CASE WHEN o.user_id IS NOT NULL THEN 1 ELSE 0 END AS has_order,
    CASE WHEN c.user_id IS NOT NULL THEN 1 ELSE 0 END AS has_collect
  FROM (SELECT DISTINCT user_id, goods_id FROM t_order) o
  FULL OUTER JOIN (SELECT DISTINCT user_id, goods_id FROM t_collect) c
    ON o.user_id = c.user_id AND o.goods_id = c.goods_id
) t;
```

**核心思路**：FULL OUTER JOIN两表 → CASE WHEN分类

## 题目描述

用户访问记录表，访问间隔<60秒视为同一次浏览，合并用户浏览会话。

## 表结构

```sql
CREATE TABLE t_page_view (
  user_id    INT,
  view_time  DATETIME,
  page_url   VARCHAR(200)
);
```

## 示例数据

| user_id | view_time           | page_url |
|---------|---------------------|----------|
| 1       | 2024-01-01 10:00:00 | /home    |
| 1       | 2024-01-01 10:00:30 | /product |
| 1       | 2024-01-01 10:01:00 | /cart    |
| 1       | 2024-01-01 10:05:00 | /home    |
| 2       | 2024-01-01 11:00:00 | /home    |

## 期望输出

| user_id | session_id | session_start       | session_end         | pages |
|---------|------------|---------------------|---------------------|-------|
| 1       | 1          | 2024-01-01 10:00:00 | 2024-01-01 10:01:00 | 3     |
| 1       | 2          | 2024-01-01 10:05:00 | 2024-01-01 10:05:00 | 1     |
| 2       | 1          | 2024-01-01 11:00:00 | 2024-01-01 11:00:00 | 1     |

## 参考SQL

```sql
SELECT user_id, grp AS session_id,
  MIN(view_time) AS session_start,
  MAX(view_time) AS session_end,
  COUNT(*) AS pages
FROM (
  SELECT *, SUM(is_new) OVER(PARTITION BY user_id ORDER BY view_time) AS grp
  FROM (
    SELECT *, CASE WHEN TIMESTAMPDIFF(SECOND, prev_time, view_time) >= 60 OR prev_time IS NULL THEN 1 ELSE 0 END AS is_new
    FROM (
      SELECT *, LAG(view_time) OVER(PARTITION BY user_id ORDER BY view_time) AS prev_time
      FROM t_page_view
    ) t1
  ) t2
) t3
GROUP BY user_id, grp
ORDER BY user_id, session_id;
```

**核心思路**：LAG算时间差→标记新会话起点→累计求和生成session_id→分组聚合

## 题目描述

股票价格表，找出连续5天以上每天涨幅>5%的股票，给出连续天数及起止日期。

## 表结构

```sql
CREATE TABLE t_stock (
  stock_code    VARCHAR(10),
  trade_date    DATE,
  closing_price DECIMAL(10,2)
);
```

## 示例数据

| stock_code | trade_date  | closing_price |
|------------|-------------|---------------|
| A          | 2024-01-01  | 100.00        |
| A          | 2024-01-02  | 108.00        |
| A          | 2024-01-03  | 116.00        |
| A          | 2024-01-04  | 125.00        |
| A          | 2024-01-05  | 135.00        |
| A          | 2024-01-06  | 140.00        |
| B          | 2024-01-01  | 50.00         |
| B          | 2024-01-02  | 53.00         |
| B          | 2024-01-03  | 49.00         |

## 期望输出

| stock_code | start_date | end_date   | days |
|------------|------------|------------|------|
| A          | 2024-01-02 | 2024-01-06 | 5    |

## 参考SQL

```sql
WITH daily_chg AS (
  SELECT *, CASE WHEN closing_price / LAG(closing_price) OVER(PARTITION BY stock_code ORDER BY trade_date) > 1.05 THEN 1 ELSE 0 END AS is_up
  FROM t_stock
),
grp AS (
  SELECT *, SUM(CASE WHEN is_up = 1 THEN 0 ELSE 1 END) OVER(PARTITION BY stock_code ORDER BY trade_date) AS gid
  FROM daily_chg
)
SELECT stock_code, MIN(trade_date) AS start_date, MAX(trade_date) AS end_date, COUNT(*) AS days
FROM grp WHERE is_up = 1
GROUP BY stock_code, gid
HAVING COUNT(*) >= 5;
```

**核心思路**：计算日涨幅→标记是否>5%→连续分组→HAVING过滤

存储过程就像我们编程语言中的函数一样，封装了我们的代码(PLSQL、T-SQL)。 上面的文字我们肯定是看不懂的，也不愿意看下去的。接下来我就总结一下： 学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的 第二范式：满足第一范式,表…

例如上述 Employee 表，n = 2 时，应返回第二高的薪水 200。如果不存在第 n 高的薪水，那么查询应返回 null。 编写一个 SQL 查询来实现分数排名。如果两个分数相同，则两个分数排名（Rank）相同。请注意，平分后的下一个名次应该是下一个连续的整数值。换句话…

使用group by的sql语句，select后的字段只能是group by后的字段，如果需要展示其他字段数据，需要给该列使用聚合函数，否则默认展示分组后的第一行数据。 左连接：左表的记录将会全部表示出来，而右表只会显示符合搜索条件的记录。右表记录不足的地方均为NULL（用户信…

SQL（结构化查询语言）是一种设计用于检索和操作数据的数据库。它属于美国国家标准协会（ANSI）的一种标准，可用于执行Select（选择）、Update（更新）、Delete（删除）和Insert（插入）等数据任务。 表是在具有列和行的模型中设计的数据集合。在表中，指定了列数称…

😊：“读题，入职时候的薪水，加上提示一个员工有多次涨薪的情况，所以本质上是求解每个员工的最低薪水，还要按照emp_no降序排列。阿，求每个员工的薪水最小值，用group by就可以实现，要输出的字段在salaries这张表中都有，所以别看他给了2张表，只需要1张表就能算出结果。1...

Sql常用语法下列语句部分是Mssql语句，不可以在access中使用。 SQL分类： DDL—数据定义语言(CREATE，ALTER，DROP，DECLARE) DML—数据操纵语言(SELECT，

1/连续最长登陆天数 2/下一次登陆时间距离上一次登陆时间大于30天时，从1开始计数 3/一张包含全国各城市用户的观看记录表view_info（表中一条数据代表一次观看记录），包含city_name、

MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引。 MySQL官方对索引的定义为：索引（In…

面试官：要不你来讲讲你们对MySQL是怎么调优的？ 候选者：哇，这命题很大阿…我认为，对于开发者而言，对MySQL的调优重点一般是在「开发规范」、「数据库索引」又或者说解决线上慢查询上。 候选者：而对

这天我正在午休呢，公司DBA就把我喊醒了，说某库出现大量慢SQL，很快啊，很快，我还没反应过来，库就挂了，我心想现在的用户不讲武德啊，怎么在我睡觉的时候大量请求呢。 这是很常见的一个场景哈，因为很多业务开始数据量级不大，所以写sql的时候就没注意性能，等量级上去，很多业务就需要…

敖丙：加索引。 敖丙：没了。 哈哈开头这个场景是我臆想的一个面试场景，但是大家是不是觉得很真实，每个人的简历上但凡写到了数据库，都会在后面顺便写一句，会数据库调优。 我觉得调优能回答的点还是很多很多的，我自己看了《MySQL实战》、《高性能MySQL》、《丁奇MySQL47讲》…

一、前言 上一篇我们说了 腾讯一面：说一说 MySQL 中索引的底层原理，相信你对索引有个很清晰的认识了，这一篇我们来说一说慢 SQL 的排查以及调优。为啥面试官要问这个问题，其实跟上一篇的索引底层原

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

大家好，我是 V 哥。SQL调优对于提升数据库查询性能至关重要，特别是当数据量大时。以下是20个详细的SQL调优指南和高级技巧，结合案例说明，帮助优化SQL查询的性能。 1. 选择合适的索引 技巧: 

一次线上慢SQL调优分享 一周前，客户反馈做题页面经常卡顿，加载慢；我们监控比较少，所以根据直觉去MySQL慢查询日志一看，果然是一条慢SQL。废话不多，开整！！！ 业务背景 一个在线做题的代码评测系

作为开发人员，我们免不了与sql打交道。有些sql可能在业务的最开始，执行是毫无问题的。但是随着业务量的提升以及业务复杂度的加深，可能之前的sql就会逐渐展现出疲惫之势了。这时就会面临sql调优。 那么调优到底如何调？不同的人有不同的姿势。可能大部分人首先想到的就是加索引。 没…

order by字段尽量走索引... 其中有些手段也许跟随者MySQL版本的升级过时了。我们真的需要背这些调优手段吗？我觉得是没有必要的，在掌握MySQL存储架构和SQL执行原理的情况下，我们就很自然的明白，为什么要提议这么优化了，甚至能够发现别人提的不太合理的优化手段。 在 …

背景 基于TPCDS的100G，500G数据进行了99SQL综合调优测试 测试机为物理机5台，1台为管理节点，4台为计算节点 可用内存约1T，核心数（vCore）200大概 重要参数 执行器个数 --

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第3天，点击查看活动详情 1.写在前面 在昨天的时候，我们就谈到了数据库连接池优化 详情可参考这里：点击查看 经过昨天的分析，我们已

面试官：MySQL如何进行性能调优？ 具体操作我这里整理了慢查询、explain、@@profiling关键字 慢查询 DBA有时候会发现有些语句比较慢，他们怎么发现的呢？ 编辑配置文件打开慢查询 然

在系统运行过程中，总会与数据库的交互，通过数据库端的日志查询执行时间最长与执行次数最多的sql语句，就可以有针对性的进行调优处理。 取执行时间最长的前50条sql语句。

引言 数据库性能优化是每个后端程序猿必备的基础技能之一，而Mysql中的explain堪称Mysql的性能优化分析神器，我们可以通过它来分析SQL语句的对应的执行计划在Mysql底层到底是如何执行的，

这几周系统访问量也是居高不下，不出意外系统又出现瓶颈了，大量用户反馈判题结果响应太慢；经排查，又是关于SQL的问题 业务背景 一个类似于力扣在线做题的代码评测模块，用户提交判题任务后，后台会进行异步判

什么是 SQL 调优？是不是觉得自己知道但又很模糊说不清楚，面试被问没有真实的案例，并不具备说服力。本文以为详细案例给大家解读。

之前曾经拜读过《收获，不止sql调优》一书，此书是国内DBA写的一本很不错的调优类型的书，是一些很不错的调优经验的分享。虽然读了一遍，做了下读书笔记，觉得很有所收获，但是到实际的实践中觉得还是很缺实践。刚好最近又有一次sql调优培训活动，去参加后，重新复习Oracle执行计划，…

Spark SQL是Spark生态系统中非常重要的组件， 能够利用 Spark 进行结构化的存储和操作。本文将围绕Spark内存泄露问题进行排查，并且给出具体的Spark调优方法。

Hive的架构 Hive元数据默认存储在derby数据库，不支持多客户端访问，所以将元数据存储在MySQl，支持多客户端访问。 2 Hive和e和数据库比较，Hive 和数据库除了拥有类似的查询语言，

1. hive 内部表和外部表的区别？ 未被external修饰的是内部表（managed table），被external修饰的为外部表（external table）； 内部表数据由Hive自身管

Hive SQL基本上适用大数据领域离线数据处理的大部分场景。Hive SQL的优化也是我们必须掌握的技能，而且，面试一定会问。那么，我希望面试者能答出其中的80%优化点，在这个问题上才算过关。 JVM重利用可以使得JOB长时间保留slot,直到作业结束，这在对于有较多任务和较…

第一题 需求 实现 数据准备 查询SQL 第二题 需求 实现 数据准备 查询SQL实现 第三题 需求 实现 数据准备 查询SQL 第四题 需求 实现 数据准备 查询SQL 第五题 需求 实现 数据准备

有用户点击日志记录表 t_click_log_025，包含user_id(用户ID),click_time(点击时间)，请查询出连续点击三次的用户数。

1.Hive的架构 2 Hive和数据库比较 Hive 和数据库除了拥有类似的查询语言，再无类似之处。 1）数据存储位置 Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。 2

有一张用户点击行为表 user_click_log(user_id, click_time, page_id, event_name)和笔记品类表 note_category(page_id, category_name)。请用SQL找出每个用户点击次数最多的前3个笔记品类，输出用户ID、品类名称、点击次数、排名。

---

🤖 AI解析：
思路：三步走——①两表JOIN按用户+品类聚合算点击次数；②用ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY cnt DESC)排名；③筛选rk<=3。如果品类点击次数相同需保留，用DENSE_RANK()替代ROW_NUMBER()。

📌 关键知识点：窗口函数ROW_NUMBER/DENSE_RANK/RANK的区别；多表JOIN+聚合组合；分组TopN的标准解法
⚠️ 易错点：ROW_NUMBER遇到并列会随机取一个丢弃其他，若需保留并列应用RANK/DENSE_RANK；数据量大时需考虑分区优化和索引

有用户登录表 user_login(user_id, login_date)，计算2025年1月新用户的次日留存率、7日留存率和30日留存率。新用户定义为该月首次登录的用户。

---

🤖 AI解析：
思路：①MIN(login_date)按user_id聚合，筛选首次登录在1月的用户作为first_login；②LEFT JOIN登录表，用CASE WHEN计算day1/day7/day30是否有回访；③COUNT总数作分母，SUM回访数作分子算留存率。

📌 关键知识点：留存率的'同批次用户'概念；LEFT JOIN保证不丢失未回访用户；DATE_ADD计算回访日期偏移
⚠️ 易错点：不能用INNER JOIN，否则分母变小导致留存率虚高；需区分'真实新用户'vs'老用户换设备重注册'——可结合设备ID交叉验证

给定用户登录表 user_login(user_id, login_date)，求每个用户的最大连续登录天数。隔天登录也算连续（日期差不超过2天）。

---

🤖 AI解析：
思路：'断点重分组'法。①按user_id排序日期，用LAG()算相邻日期差；②差值>2时标记为新段开始（new_group=1）；③累加SUM(new_group)生成分组ID；④按分组算日期跨度得连续天数；⑤取每个用户最大值。

📌 关键知识点：LAG窗口函数；累加SUM生成分组标识的经典技巧；连续性问题的标准解法
⚠️ 易错点：需先去重日期再排序；LAG缺失值(首行)返回NULL需COALESCE处理；大数据量时可用增量计算缓存已算好的连续天数

给定user_info(user_id, reg_date)和user_act_log(user_id, act_date, act_type)，计算某一天新增用户的次日留存率和7日留存率。

---

🤖 AI解析：
思路：①筛选指定日期注册用户；②LEFT JOIN活动日志，限定act_date = reg_date+1(次日)或reg_date+7(7日)；③COUNT(有回访的用户)/总注册数算留存率。关键是用LEFT JOIN而非INNER JOIN。

📌 关键知识点：LEFT JOIN保留未回访用户；JOIN条件不仅ON user_id还要限定日期范围；留存定义需与业务方对齐
⚠️ 易错点：INNER JOIN会漏掉未回访用户导致分母变小；大数据量时JOIN性能差——可用子查询预聚合、分桶、或数据倾斜加盐处理

报表SQL跑1小时无结果：SELECT user_id, count(*) FROM orders WHERE create_time>'2025-01-01' GROUP BY user_id HAVING count(*)>5 ORDER BY count(*) DESC。怎么排查优化？

---

🤖 AI解析：
思路：①EXPLAIN看执行计划，查是否全表扫描；②排查create_time有无索引；③排查user_id数据分布是否倾斜(大V用户占90%数据导致单reduce扛不住)；④优化方向：建索引、亿级数据改用Hive/Spark、数据倾斜用哈希分桶或加盐打散。

📌 关键知识点：EXPLAIN分析执行计划是第一步；数据倾斜是GROUP BY慢的常见原因；优化需先定位瓶颈再对症下药
⚠️ 易错点：不要一上来就说'加索引'——需结合执行计划判断；HAVING过滤在聚合后执行，不能减少GROUP BY的计算量

请描述Hive的架构，包括各个组件的功能和交互关系。

---

🤖 AI解析：
Hive架构核心组件：①Driver：接收SQL→解析→优化→执行的全流程控制器；②MetaStore：元数据存储(表结构/分区/位置信息)，默认MySQL；③Compiler：将HQL编译为MapReduce/Tez/Spark物理执行计划；④Execution Engine：实际执行引擎(MR/Tez/Spark)；⑤HDFS：数据存储底层；⑥CLI/JDBC/ODBC：客户端接口。

📌 关键知识点：Hive本质=SQL→MR/Tez任务转换引擎；MetaStore是Hive的核心依赖(元数据丢了数据就找不到)；Compiler的CBO优化器选择最优执行路径
⚠️ 易错点：Hive不是数据库而是数据仓库工具——查询延迟高不适合实时场景；MetaStore默认Derby仅支持单会话，生产必须换MySQL

HiveSQL面试题：查询每科成绩都大于80分的学生信息。

---

🤖 AI解析：
思路：①按学生分组，用MIN(score)筛选最低分>80的学生(若最低分>80则所有科目>80)；②或用COUNT(CASE WHEN score<=80) = 0过滤。标准SQL：SELECT name FROM student_score GROUP BY name HAVING MIN(score) > 80。

📌 关键知识点：MIN聚合+HAVING是判断'所有值满足条件'的简洁写法；避免用NOT IN子查询(Hive对子查询支持有限)
⚠️ 易错点：不要用WHERE score>80再GROUP BY——这只会过滤掉<80的记录而非确保所有科目>80；Hive子查询性能差应优先用聚合函数

短视频业务需实时统计每秒视频播放量(VV)和播放用户数(UV)，数据写入延迟要求5秒以内，选择什么引擎怎么设计表结构？

---

🤖 AI解析：
引擎选择：ReplicatedAggregatingMergeTree(保证高可用+预聚合)。表结构设计：分区键按时间toMinute(event_time)，排序键(video_id, toStartOfSecond(event_time))走索引。方案：①建物化视图预聚合每秒VV/UV；②或用SummingMergeTree+状态表做累计指标；③进阶：Flink做实时ETTL→ClickHouse做OLAP查询，这是字节数据团队的标准架构。

📌 关键知识点：AggregatingMergeTree适合预聚合场景；物化视图自动触发聚合避免手动；Flink+ClickHouse是实时数仓经典组合
⚠️ 易错点：ClickHouse写入是追加式不能频繁UPDATE——需用聚合引擎而非直接修改；物化视图过多影响写入性能需权衡

## 题目描述
从 user_login 表中找出连续登录>=3天的所有用户。

## 表结构
user_login(user_id INT, login_date DATE)

## 示例数据
user 1: 06-10~12 (3天连续)
user 2: 06-09~12 (4天连续)
user 3: 06-12~14 (3天连续)
user 4: 06-08~09 (2天，不连续)
user 5: 06-01~05 (5天连续)

## 解题思路
核心技巧：连续日期的 date - ROW_NUMBER() 结果相同（组号相同）。
按用户+组号分组，COUNT>=3即可。

### 参考答案
WITH daily AS (
    SELECT DISTINCT user_id, login_date FROM user_login
),
ranked AS (
    SELECT user_id, login_date,
        DATE_SUB(login_date, INTERVAL
            ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)
        DAY) as grp
    FROM daily
)
SELECT DISTINCT user_id
FROM ranked GROUP BY user_id, grp
HAVING COUNT(*) >= 3;

## 题目描述
ad_plan 表记录广告计划的消耗金额。找出最少需要几个计划，
它们的累计消耗能达到总消耗的90%。

## 表结构
ad_plan(plan_id INT, plan_name TEXT, cost REAL)

## 示例数据
12个计划，总消耗约726000
按消耗降序累加:
150000+120000+95000+88000+72000+65000=592000(81.5%)
+45000=637000(87.7%) +32000=669000(92.1%)>90%
答案: 8个计划

## 解题思路
贪心策略：按消耗降序排列，累计求和，
找到累计占比>=90%的临界点。

### 参考答案
WITH total AS (
    SELECT SUM(cost) as total_cost FROM ad_plan
),
sorted AS (
    SELECT plan_id, plan_name, cost,
        SUM(cost) OVER (ORDER BY cost DESC) as cum_cost,
        ROUND(SUM(cost) OVER(ORDER BY cost DESC)*100.0/
            (SELECT total_cost FROM total),2) as cum_pct
    FROM ad_plan
)
SELECT COUNT(*) as min_plans
FROM sorted WHERE cum_pct <= 90;

## 题目1：上月末尾10%商家总成交额

### 表结构
merchant_tag(dt TEXT, merchant_id INT, pay_amount REAL, l1_industry_name TEXT)

### 字段说明
- dt: 日期分区（格式YYYYMMDD，如20251027）
- merchant_id: 商家ID
- pay_amount: 当日成交金额（单位：分）
- l1_industry_name: 商家行业

### 题目要求
求上月（2025年10月）商家成交金额**末尾10%**（金额最小的10%商家）的**总成交额**（单位：元）。

### 解题思路
1. 筛选dt以'202510'开头的记录（10月数据）
2. 按merchant_id分组，SUM(pay_amount)得到上月总成交额
3. 按成交额升序排序，用NTILE(10)或ROW_NUMBER取末尾10%商家
4. 对这些商家再SUM，结果除以100转为元

### 参考答案
WITH merchant_oct AS (
    SELECT merchant_id, SUM(pay_amount) as total_amount
    FROM merchant_tag
    WHERE dt LIKE '202510%'
    GROUP BY merchant_id
),
ranked AS (
    SELECT merchant_id, total_amount,
        NTILE(10) OVER (ORDER BY total_amount) as percentile
    FROM merchant_oct
)
SELECT ROUND(SUM(total_amount) / 100, 2) as total_yuan
FROM ranked WHERE percentile = 1;

## 题目2（加分题）：跨月跃迁商家数

### 题目要求
求上月（2025年10月）各行业商家成交金额**末尾10%**的商家，
在本月（2025年11月1日-15日）累计至今**跃迁到前50%（中位数以上）**的每日商家数。

### 解题思路
1. 10月各行业用 NTILE(10) 找末尾10%商家
2. 11月用 SUM() OVER 算每天累计成交额
3. 每天用 NTILE(2) 找前50%商家（中位数以上）
4. 交集 = 上月末尾10% && 本月前50% = 跃迁商家

### 参考答案
-- Step1: 10月各行业末尾10%商家
WITH bottom10_oct AS (
    SELECT merchant_id, l1_industry_name
    FROM (
        SELECT merchant_id, l1_industry_name,
            NTILE(10) OVER (PARTITION BY l1_industry_name ORDER BY SUM(pay_amount)) as pct
        FROM merchant_tag
        WHERE dt LIKE '202510%'
        GROUP BY merchant_id, l1_industry_name
    ) WHERE pct = 1
),
-- Step2: 11月每天累计成交额（先算好）
nov_cum AS (
    SELECT merchant_id, dt,
        SUM(pay_amount) OVER (PARTITION BY merchant_id ORDER BY dt) as cum_amount
    FROM merchant_tag
    WHERE dt LIKE '202511%'
),
-- Step3: 每天 NTILE(2) 标记前50%
nov_rank AS (
    SELECT merchant_id, dt, cum_amount,
        NTILE(2) OVER (PARTITION BY dt ORDER BY cum_amount) as half
    FROM nov_cum
),
-- Step4: 跃迁商家（底部10% -> 前50%）= 交集 + half=2
SELECT n.dt, COUNT(DISTINCT n.merchant_id) as up_count
FROM nov_rank n
JOIN bottom10_oct b ON n.merchant_id = b.merchant_id
WHERE n.half = 2
GROUP BY n.dt
ORDER BY n.dt;