面试题解四Session和Cookie的区别？ Session和Cookie的区别可以从以下几个方面进行阐述，结合应用场

1. Session和Cookie的区别？

Session和Cookie的区别可以从以下几个方面进行阐述，结合应用场景和技术实现：

1. 存储位置

Cookie：数据存储在客户端（浏览器），以文本形式保存。
Session：数据存储在服务端（如内存、Redis、数据库等），仅通过Session ID与客户端关联。

2. 安全性

Cookie：
- 可能被客户端篡改或窃取（如XSS攻击），需对敏感数据加密。
- 可通过HttpOnly（禁止JS访问）和Secure（仅HTTPS传输）属性提升安全性。
Session：
- 数据在服务端存储，安全性更高。
- Session ID仍需通过Cookie传递，需防范会话劫持（如使用SSL）。

3. 生命周期

Cookie：
- 可设置过期时间（如max-age），实现长期持久化（如“记住我”功能）。
- 未设置时，生命周期为浏览器会话（关闭即失效）。
Session：
- 默认依赖浏览器的会话Cookie（JSESSIONID），关闭浏览器即失效。
- 服务端可主动设置超时时间（如Tomcat的session-timeout配置）。

4. 存储内容与容量

Cookie：
- 仅支持字符串类型，单Cookie大小通常限制为4KB，同一域名下数量有限（约20-50个）。
Session：
- 可存储任意类型对象（如Java对象），容量取决于服务端内存或存储配置。

5. 性能与扩展性

Cookie：
- 每次请求自动携带，可能增加网络开销。
- 无状态，适合分布式系统。
Session：
- 服务端查询Session数据可能消耗资源（高并发时需优化）。
- 分布式场景需集中存储（如Redis集群），避免粘性会话问题。

6. 跨域支持

Cookie：默认不可跨域，但可通过Domain和Path属性控制作用域。
Session：依赖Session ID传递，默认不支持跨域（需额外处理如OAuth令牌）。

典型应用场景

Cookie：
- 记住用户偏好（如主题、语言）。
- 长期登录态（配合Token）。
Session：
- 短期敏感信息（如用户登录态、购物车）。
- 需服务端控制的数据（如权限校验）。

技术实现（Java示例）

Cookie：

Cookie cookie = new Cookie("username", "john");
cookie.setMaxAge(7 * 24 * 60 * 60); // 7天有效期
response.addCookie(cookie);

Session：

HttpSession session = request.getSession();
session.setAttribute("cart", cartItems);
session.setMaxInactiveInterval(30 * 60); // 30分钟超时

总结

特性	Cookie	Session
存储位置	客户端	服务端
安全性	较低，需防护	较高
数据类型	字符串	任意对象
生命周期	可长期持久化	通常短期有效
网络开销	每次请求携带	仅传递Session ID
分布式支持	无需处理	需集中存储（如Redis）

实际开发中常结合使用：Session ID通过Cookie传递，敏感数据存Session，非敏感配置存Cookie。

2. 服务器宕机了，Cookie还能继续用吗？

这个问题需要从 Cookie 的工作机制 和 服务器状态 两个角度来分析，以下是分点解答：

1. Cookie 的存储位置

Cookie 是由服务器生成并存储在 客户端（浏览器） 的数据，与服务器是否运行无关。
只要 Cookie 未过期（如持久化 Cookie 设置了 Expires 或 Max-Age），浏览器会持续携带 Cookie 发送到服务器，无论服务器是否宕机。

2. 服务器宕机的影响

会话型 Cookie（Session Cookie）：
如果服务器使用内存存储会话（如 Java 的 HttpSession），宕机会导致 会话数据丢失。此时即使浏览器发送了 Cookie，服务器也无法通过 Cookie 中的 Session ID 恢复会话（因为会话数据已丢失）。
持久化 Cookie：
如果 Cookie 中直接存储了用户状态（如 JWT Token），且服务器无需维护会话状态（如无状态服务架构），则 服务器重启后仍能解析 Cookie 中的有效信息（只要密钥未重置）。

3. 恢复能力的核心因素

会话存储方式：
若会话数据存储在 外部持久化存储（如 Redis、数据库）中，服务器重启后仍能通过 Cookie 中的 Session ID 恢复会话。
Cookie 有效期：
如果 Cookie 已过期，浏览器会自动清理，后续请求不再携带该 Cookie。

4. 实际场景示例

// 示例：Java 中设置持久化 Cookie（Max-Age=1天）
Cookie cookie = new Cookie("sessionId", "12345");
cookie.setMaxAge(86400);  // 设置过期时间
response.addCookie(cookie);

服务器宕机重启后：
若会话数据存储在 Redis 中且未过期，浏览器携带的 Cookie 仍有效，服务器可通过 Session ID 恢复会话。
若会话数据仅存储在内存中，则 Cookie 失效。

5. 解决方案建议

无状态架构：
使用 JWT 等方案直接在 Cookie 中存储加密的用户信息，避免依赖服务器会话。
分布式会话存储：
将会话数据保存到 Redis 或数据库，确保服务器重启后会话不丢失。
设置合理的 Cookie 过期时间：
根据业务需求平衡安全性与用户体验。

总结

Cookie 本身可用性：服务器宕机不影响浏览器存储和发送 Cookie。
会话恢复能力：取决于会话存储方式（内存 vs 持久化存储）。
最佳实践：通过 无状态设计 或 分布式会话存储 提升容错性。

3. 不用redis，Java后端有没有什么本地缓存的实现方案？

以下是Java后端在不使用Redis时常见的本地缓存实现方案，结合实际开发场景和技术选型进行说明：

1. 基于内存的缓存框架

(1) Caffeine

特点：
- 高性能本地缓存库（Guava Cache的现代替代品），支持异步刷新、权重控制。
- 提供多种过期策略（基于时间、大小、引用）。
适用场景：高并发读写的本地缓存需求。

代码示例：

Cache<String, Object> cache = Caffeine.newBuilder()
    .expireAfterWrite(10, TimeUnit.MINUTES)  // 写入后10分钟过期
    .maximumSize(1000)                      // 最大缓存条目数
    .build();

// 使用
cache.put("key", value);
Object value = cache.getIfPresent("key");

(2) Guava Cache

特点：
- Google提供的本地缓存，支持弱引用、软引用、过期策略。
- 适合中小规模缓存，功能丰富但性能略逊于Caffeine。

代码示例：

LoadingCache<String, Object> cache = CacheBuilder.newBuilder()
    .expireAfterAccess(30, TimeUnit.MINUTES)
    .maximumSize(500)
    .build(new CacheLoader<String, Object>() {
        @Override
        public Object load(String key) {
            return loadFromDB(key); // 自动加载逻辑
        }
    });

2. 基于Java集合的简易缓存

(1) ConcurrentHashMap + 手动管理

特点：
- 使用线程安全的ConcurrentHashMap存储数据。
- 需自行实现过期清理（如定时任务或LRU淘汰）。
适用场景：轻量级、临时缓存需求。

代码示例：

ConcurrentHashMap<String, CacheEntry> cache = new ConcurrentHashMap<>();
// 封装缓存条目（含过期时间）
class CacheEntry {
    Object value;
    long expireTime;
}

// 手动清理过期条目（可通过ScheduledExecutorService定时触发）
cache.entrySet().removeIf(entry -> 
    System.currentTimeMillis() > entry.getValue().expireTime
);

(2) LinkedHashMap实现LRU缓存

特点：
- 通过重写removeEldestEntry方法实现LRU淘汰策略。
- 非线程安全，需结合同步机制使用。

代码示例：

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int maxSize;
    
    public LRUCache(int maxSize) {
        super(maxSize, 0.75f, true);
        this.maxSize = maxSize;
    }
    
    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > maxSize;
    }
}

3. 集成框架的缓存抽象

(1) Spring Framework Cache

特点：
- 通过@Cacheable、@CacheEvict等注解简化缓存操作。
- 默认使用ConcurrentMapCacheManager（基于ConcurrentHashMap）。
- 可无缝切换为其他缓存实现（如Caffeine、Ehcache）。

配置示例：

@Configuration
@EnableCaching
public class CacheConfig {
    @Bean
    public CacheManager cacheManager() {
        return new ConcurrentMapCacheManager("users", "products");
    }
}

// 使用注解
@Cacheable(value = "users", key = "#userId")
public User getUserById(String userId) { ... }

(2) Ehcache（本地模式）

特点：
- 支持内存+磁盘二级缓存，可配置持久化策略。
- 提供细粒度的缓存配置（TTL、TTI、堆外内存等）。

XML配置示例（ehcache.xml）：

<ehcache>
    <cache name="myCache"
           maxEntriesLocalHeap="1000"
           timeToLiveSeconds="3600"
           memoryStoreEvictionPolicy="LRU"/>
</ehcache>

Spring集成：

@Bean
public CacheManager ehcacheManager() {
    return new EhCacheCacheManager(ehCacheManager().getObject());
}

4. 自研缓存方案

方案特点：
- 结合WeakReference/SoftReference实现内存敏感缓存。
- 使用定时任务（如ScheduledThreadPoolExecutor）清理过期数据。
- 适合高度定制化场景，但维护成本较高。

技术选型建议

场景	推荐方案
高性能、高并发	Caffeine
Spring项目快速集成	Spring Cache + ConcurrentMapCache
需要LRU淘汰策略	LinkedHashMap或Caffeine/Guava Cache
复杂缓存策略（如磁盘持久化）	Ehcache
简单临时缓存	ConcurrentHashMap + 手动管理

注意事项

内存管理：本地缓存需关注JVM堆内存压力，避免OOM。
缓存穿透/雪崩：
- 对空值缓存（如Guava的Optional包装）。
- 使用互斥锁或Caffeine的refreshAfterWrite防止雪崩。
分布式一致性：本地缓存不适用于多节点数据同步场景。

通过合理选择本地缓存方案，可以在不依赖Redis的情况下，有效提升系统性能并减少数据库压力。

4. 多人聊天室这种实时通信如何实现？

以下是针对多人聊天室实时通信的实现方案，结合 Java 后端技术栈 的分点解析：

1. 核心技术选型

WebSocket 协议

全双工通信：与 HTTP 不同，WebSocket 支持服务端主动推送消息，适合实时场景。
低延迟：建立连接后无需重复握手，通信效率高。
Java 实现：
- 原生 API：javax.websocket（需容器支持，如 Tomcat）。
- Spring 生态：Spring WebSocket + STOMP 协议简化开发。
- 高性能框架：Netty 处理高并发连接。

备选方案

长轮询（Long Polling）：通过 HTTP 不断轮询服务器，实现“伪实时”（如 Comet 技术）。
Server-Sent Events (SSE)：单向服务器推送（适合通知类场景）。

2. 实现步骤（以 Spring WebSocket + STOMP 为例）

(1) 添加依赖

<!-- Spring WebSocket -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
</dependency>

(2) 配置 WebSocket

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/chat")  // WebSocket 连接端点
                .setAllowedOrigins("*")
                .withSockJS();        // 支持 SockJS 回退
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        registry.enableSimpleBroker("/topic"); // 消息代理前缀（广播）
        registry.setApplicationDestinationPrefixes("/app"); // 客户端发送消息前缀
    }
}

(3) 消息处理与广播

@Controller
public class ChatController {

    @MessageMapping("/sendMessage")  // 处理客户端发送的消息（路径：/app/sendMessage）
    @SendTo("/topic/messages")       // 广播到所有订阅 /topic/messages 的客户端
    public ChatMessage broadcastMessage(ChatMessage message) {
        return message;
    }
}

(4) 前端连接（JavaScript）

const stompClient = new StompJs.Client({
    brokerURL: 'ws://localhost:8080/chat'
});

stompClient.onConnect = () => {
    stompClient.subscribe('/topic/messages', (msg) => {
        console.log('收到消息:', JSON.parse(msg.body));
    });
};

stompClient.activate();

3. 关键优化点

消息广播效率

单机场景：使用 SimpMessagingTemplate 直接广播。

集群场景：集成 Redis 或 RabbitMQ 作为消息代理，跨节点同步消息。

// 配置 RabbitMQ 作为消息代理（替代 enableSimpleBroker）
@Override
public void configureMessageBroker(MessageBrokerRegistry registry) {
    registry.enableStompBrokerRelay("/topic")
            .setRelayHost("rabbitmq-host");
    registry.setApplicationDestinationPrefixes("/app");
}

高并发处理

Netty 优化：使用 Netty 替代 Tomcat 的 WebSocket 实现，支持更高并发连接。
异步非阻塞：避免在消息处理线程中执行阻塞操作（如数据库查询），使用 @Async 异步处理。

安全性

鉴权：在 WebSocket 握手阶段验证 Token（如 JWT）。

@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
    registry.addEndpoint("/chat")
            .setHandshakeHandler(new JwtHandshakeHandler()); // 自定义握手鉴权
}

限制连接数：防止资源耗尽。

4. 架构示意图

客户端（浏览器） 
  ↑↓ WebSocket 连接
Java 服务器（Spring WebSocket）
  ↑↓ 消息代理（Redis/RabbitMQ） → 集群节点同步
数据库（可选，存储聊天记录）

5. 方案对比

方案	优点	缺点	适用场景
Spring WebSocket	开发简单，集成 Spring 生态	单机性能有限	中小型聊天室
Netty	高性能，支持百万级并发	代码复杂度高	大型实时系统（如IM）
长轮询	兼容性高（支持旧浏览器）	延迟高，资源消耗大	降级方案

6. 面试回答要点

核心协议：优先选择 WebSocket，解释其全双工特性。
Java 实现：熟悉 Spring WebSocket 或 Netty 的实践。
扩展性：强调集群下消息代理（如 Redis）的作用。
安全与性能：提及鉴权、异步处理和连接数管理。

通过此方案，你可以高效实现多人聊天室，并根据业务规模灵活扩展！ 🚀

5. WebSocket的理解，什么时候需要用WebSocket？

WebSocket的理解

1. 基本概念
WebSocket是一种基于TCP的全双工通信协议，通过一次HTTP握手升级连接后，客户端与服务器间建立持久连接，允许双方实时、双向传输数据。相较于传统的HTTP请求-响应模式，WebSocket避免了频繁建立连接的开销，适合需要实时交互的场景。

2. 核心特点

全双工通信：客户端和服务端可同时发送数据。
低延迟：连接持久化，无需重复握手，减少通信延迟。
轻量级协议：数据帧头部开销小（仅2~10字节）。
基于TCP：确保数据传输的可靠性。

3. 握手过程

客户端发送HTTP请求，携带Upgrade: websocket和Sec-WebSocket-Key。
服务端返回101 Switching Protocols响应，包含Sec-WebSocket-Accept。
协议升级完成，后续数据通过WebSocket帧传输。

WebSocket与HTTP对比

特性	WebSocket	HTTP
通信模式	双向实时通信（全双工）	单向请求-响应（半双工）
连接生命周期	持久化连接（手动关闭）	短连接（请求后立即关闭）
数据格式	二进制帧或文本帧	纯文本（Header + Body）
适用场景	实时交互需求（如聊天、推送）	静态资源加载、表单提交等

何时需要使用WebSocket？

1. 典型应用场景

实时消息推送：如在线聊天、即时通讯（IM）、弹幕系统。
实时数据监控：股票行情、IoT设备状态、物流追踪。
多玩家在线游戏：实时同步玩家动作与游戏状态。
协同编辑工具：多人同时编辑文档，实时同步内容。
在线客服系统：客服与用户实时双向沟通。

2. 替代方案对比

短轮询（Polling）：客户端定时请求服务器，效率低且延迟高。
长轮询（Long Polling）：服务器保持请求直到有数据返回，仍依赖HTTP，处理复杂。
SSE（Server-Sent Events）：仅支持服务端到客户端的单向推送。
WebSocket：双向实时通信，性能最优，适合高频交互场景。

Java后端实现WebSocket

1. 使用Spring框架（推荐）

依赖：添加spring-boot-starter-websocket。
配置：实现WebSocketConfigurer，注册端点与拦截器。

示例代码：

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(myHandler(), "/ws")
                .setAllowedOrigins("*");
    }

    @Bean
    public WebSocketHandler myHandler() {
        return new MyWebSocketHandler();
    }
}

public class MyWebSocketHandler extends TextWebSocketHandler {
    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message) {
        // 处理客户端消息
        session.sendMessage(new TextMessage("Received: " + message.getPayload()));
    }
}

2. 使用Java原生API（javax.websocket）

注解驱动：通过@ServerEndpoint定义端点。

代码示例：

@ServerEndpoint("/chat")
public class ChatEndpoint {
    @OnOpen
    public void onOpen(Session session) {
        System.out.println("Client connected: " + session.getId());
    }

    @OnMessage
    public void onMessage(String message, Session session) {
        session.getAsyncRemote().sendText("Echo: " + message);
    }
}

注意事项与优化

连接管理
- 维护在线会话列表（如ConcurrentHashMap存储Session）。
- 处理异常断开（@OnClose中清理资源）。
心跳机制
- 定期发送Ping/Pong帧检测连接存活，避免假死。
负载均衡问题
- 分布式场景下需同步会话状态（如通过Redis广播消息）。
安全性
- 使用wss://加密通信。
- 校验Origin防止跨站攻击。

总结

使用WebSocket的场景：

需要服务端主动推送数据（如通知、实时更新）。
客户端与服务端需高频双向交互（如聊天、游戏）。
传统轮询方案无法满足性能或实时性要求。

不适用场景：

简单数据查询（如静态页面加载）。
低频或无实时性要求的操作（如文件上传）。

技术选型：优先选择成熟的框架（如Spring WebSocket），结合业务需求设计合理的消息协议（如JSON/Protobuf），并考虑扩展性与容错机制。

6. MySQL聚合函数有哪些？

以下是MySQL聚合函数的详细分点解析，结合示例与应用场景：

1. 基础聚合函数

(1) `COUNT()`

作用：统计行数或非NULL值的数量。

用法：

SELECT COUNT(*) FROM employees;           -- 统计总行数（包括NULL）
SELECT COUNT(department_id) FROM employees; -- 统计非NULL的部门ID数量
SELECT COUNT(DISTINCT department_id) FROM employees; -- 统计唯一部门数量

(2) `SUM()`

作用：计算数值列的总和，忽略NULL。

示例：

SELECT SUM(salary) FROM employees; -- 计算薪资总和
SELECT SUM(bonus) FROM sales WHERE bonus > 1000; -- 条件求和

(3) `AVG()`

作用：计算数值列的平均值，忽略NULL。

示例：

SELECT AVG(score) FROM exams; -- 平均分
SELECT AVG(DISTINCT age) FROM users; -- 去重后平均年龄

(4) `MAX()` / `MIN()`

作用：返回列中的最大/最小值，支持数值、日期、字符串。

示例：

SELECT MAX(hire_date) FROM employees; -- 最近入职日期
SELECT MIN(price) FROM products WHERE category = 'Electronics'; -- 最低价

2. 高级聚合函数

(5) `GROUP_CONCAT()`

作用：将分组内的多个值合并为字符串，支持排序和分隔符。

示例：

-- 合并同一部门的员工姓名，按字母排序，用逗号分隔
SELECT department_id, 
       GROUP_CONCAT(first_name ORDER BY first_name SEPARATOR ', ') 
FROM employees 
GROUP BY department_id;

(6) `STDDEV()` / `STDDEV_POP()`

作用：计算总体标准差。

示例：

SELECT STDDEV(salary) FROM employees; -- 薪资标准差

(7) `VAR_POP()` / `VARIANCE()`

作用：计算总体方差。

示例：

SELECT VARIANCE(score) FROM exams; -- 成绩方差

(8) `BIT_AND()` / `BIT_OR()`

作用：对二进制位进行按位与/或运算。

示例：

-- 统计权限字段的公共位（如权限掩码）
SELECT BIT_AND(permissions) FROM user_roles WHERE role = 'admin';

3. JSON聚合函数（MySQL 5.7+）

(9) `JSON_ARRAYAGG()`

作用：将结果集合并为JSON数组。

示例：

SELECT department_id, JSON_ARRAYAGG(email) 
FROM employees 
GROUP BY department_id;

(10) `JSON_OBJECTAGG()`

作用：将键值对合并为JSON对象。

示例：

SELECT JSON_OBJECTAGG(product_id, price) 
FROM products WHERE category = 'Books';

4. 聚合函数与分组

`GROUP BY` 与 `HAVING`

GROUP BY：按列分组后聚合。
HAVING：过滤聚合结果。

示例：

-- 统计部门平均薪资高于5000的部门
SELECT department_id, AVG(salary) AS avg_salary
FROM employees
GROUP BY department_id
HAVING avg_salary > 5000;

5. 注意事项

NULL处理：
- COUNT(column) 忽略NULL，COUNT(*) 包含NULL。
- SUM()、AVG() 忽略NULL，可能导致分母为0错误（需用 IFNULL 处理）。
```
SELECT AVG(IFNULL(salary, 0)) FROM employees; -- 将NULL转为0计算
```
性能优化：
- 在大型数据集上，避免对非索引列使用聚合（如 MAX(text_column)）。
- 使用覆盖索引加速 COUNT(*)。

6. 面试回答示例

问题：请列举MySQL的聚合函数并说明其用途。
回答：
MySQL的聚合函数主要用于对数据集进行统计计算，常见的包括：

COUNT()：统计行数或非NULL值数量。
SUM()：计算数值列总和。
AVG()：求平均值，忽略NULL。
MAX()/MIN()：获取最大/最小值。
GROUP_CONCAT()：将分组值合并为字符串。
STDDEV()/VARIANCE()：计算标准差和方差。
BIT_AND()/BIT_OR()：位运算聚合。
JSON_ARRAYAGG()/JSON_OBJECTAGG()（MySQL 5.7+）：生成JSON结构。

例如，统计部门平均薪资并过滤：

SELECT department_id, AVG(salary) 
FROM employees 
GROUP BY department_id 
HAVING AVG(salary) > 5000;

通过以上分点解析，可系统展示对MySQL聚合函数的全面理解，适用于面试中的技术考察。

7. MySQL几种联表查询。

MySQL联表查询类型详解

MySQL中常见的联表查询（JOIN）主要包括以下几种类型，每种类型适用于不同的数据查询需求：

1. 内连接（INNER JOIN）

作用：返回两个表中满足连接条件的记录。

语法：

SELECT * 
FROM table1 
INNER JOIN table2 ON table1.column = table2.column;

示例：
查询所有用户及其对应的订单（仅包含有订单的用户）：

SELECT users.user_id, users.username, orders.order_id, orders.amount
FROM users
INNER JOIN orders ON users.user_id = orders.user_id;

适用场景：需要精确匹配两表数据的场景（如关联用户与订单）。

2. 左连接（LEFT JOIN / LEFT OUTER JOIN）

作用：返回左表全部记录，右表无匹配时填充NULL。

语法：

SELECT * 
FROM table1 
LEFT JOIN table2 ON table1.column = table2.column;

示例：
查询所有用户及其订单（包含没有订单的用户）：

SELECT users.user_id, users.username, orders.order_id, orders.amount
FROM users
LEFT JOIN orders ON users.user_id = orders.user_id;

适用场景：需保留左表全部数据，即使右表无匹配（如统计用户活跃度）。

3. 右连接（RIGHT JOIN / RIGHT OUTER JOIN）

作用：返回右表全部记录，左表无匹配时填充NULL。

语法：

SELECT * 
FROM table1 
RIGHT JOIN table2 ON table1.column = table2.column;

示例：
查询所有订单及其用户（包含未关联到有效用户的订单）：

SELECT users.user_id, orders.order_id, orders.amount
FROM users
RIGHT JOIN orders ON users.user_id = orders.user_id;

注意：实际开发中较少使用，可通过调换表顺序改用LEFT JOIN。

4. 全外连接（FULL OUTER JOIN）

作用：返回两表所有记录，无匹配部分填充NULL。

语法（MySQL需用UNION模拟）：

SELECT * FROM table1 LEFT JOIN table2 ON condition
UNION
SELECT * FROM table1 RIGHT JOIN table2 ON condition;

示例：
获取所有用户和订单的组合（包含无订单的用户和无用户的订单）：

SELECT users.user_id, users.username, orders.order_id, orders.amount
FROM users
LEFT JOIN orders ON users.user_id = orders.user_id
UNION
SELECT users.user_id, users.username, orders.order_id, orders.amount
FROM users
RIGHT JOIN orders ON users.user_id = orders.user_id;

适用场景：需同时保留两表全部数据的场景（如数据完整性检查）。

5. 交叉连接（CROSS JOIN）

作用：返回两表的笛卡尔积（所有可能的组合）。

语法：

SELECT * 
FROM table1 
CROSS JOIN table2;
-- 等效于：
SELECT * FROM table1, table2;

示例：
生成用户与产品的所有组合（如测试数据）：

SELECT users.username, products.product_name
FROM users
CROSS JOIN products;

注意：数据量大时性能极差，谨慎使用。

6. 自连接（SELF JOIN）

作用：同一表内通过别名进行连接，常用于层级数据。

示例：
查询员工及其经理名称：

SELECT e.employee_name AS employee, m.employee_name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.employee_id;

适用场景：处理树形结构数据（如组织架构、分类层级）。

对比与选型建议

连接类型	关键字	返回结果	典型场景
内连接	`INNER JOIN`	两表匹配的记录	精确关联数据（如订单-用户）
左连接	`LEFT JOIN`	左表全部 + 右表匹配部分	保留左表完整数据（如用户统计）
右连接	`RIGHT JOIN`	右表全部 + 左表匹配部分	保留右表完整数据（较少使用）
全外连接	`UNION`模拟	两表全部数据	数据完整性检查
交叉连接	`CROSS JOIN`	两表的笛卡尔积	生成组合数据（慎用）
自连接	别名 + `JOIN`	同一表内的层级关系	树形结构查询（如员工-经理）

注意事项

性能优化：
- 确保连接字段（如user_id）有索引，避免全表扫描。
- 避免不必要的CROSS JOIN，数据量大时会导致性能问题。
NULL处理：
- 使用LEFT JOIN或RIGHT JOIN时，注意处理右表/左表字段可能的NULL值。
语义清晰：
- 优先使用INNER JOIN和LEFT JOIN，代码可读性更高。

总结

根据业务需求选择合适的联表类型：

需要精确匹配 → INNER JOIN
保留左表完整数据 → LEFT JOIN
处理层级关系 → SELF JOIN
全量数据合并 → UNION模拟FULL OUTER JOIN

合理使用联表查询可高效处理复杂数据关联，但需结合索引和业务逻辑优化性能。

8. MySQL数据库层面的优化？

MySQL数据库层面优化策略

作为Java后端开发人员，理解MySQL优化是核心技能之一。以下从多个维度系统阐述数据库层面的优化方案，结合代码示例与场景分析：

1. 索引优化

(1) 合理创建索引

选择高选择性列：在WHERE、JOIN、ORDER BY的列上创建索引。

-- 示例：用户表按手机号查询
CREATE INDEX idx_phone ON users(phone);

联合索引最左前缀原则：

-- 索引(a,b,c) 可优化 WHERE a=? AND b=?，但无法优化 WHERE b=? AND c=?
CREATE INDEX idx_multi ON orders(user_id, status, create_time);

覆盖索引：减少回表查询。

-- 索引包含查询所需字段
CREATE INDEX idx_covering ON products(category_id, price, name);

(2) 避免索引失效

隐式类型转换：

-- phone字段为VARCHAR，以下会导致索引失效
SELECT * FROM users WHERE phone = 13800138000; -- 错误示例

避免函数操作：

-- 索引失效示例
SELECT * FROM logs WHERE YEAR(create_time) = 2023;
-- 优化为范围查询
SELECT * FROM logs WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31';

2. SQL查询优化

(1) 避免低效查询模式

禁止SELECT *：减少数据传输与内存消耗。

-- 不推荐
SELECT * FROM orders WHERE user_id = 100;
-- 推荐
SELECT order_id, amount, status FROM orders WHERE user_id = 100;

分页优化：避免大偏移量。

-- 低效写法（偏移量越大越慢）
SELECT * FROM products LIMIT 100000, 20;
-- 优化：使用索引覆盖+延迟关联
SELECT * FROM products 
WHERE id >= (SELECT id FROM products ORDER BY id LIMIT 100000, 1)
LIMIT 20;

(2) 利用执行计划分析

EXPLAIN命令：分析SQL执行路径。
```
EXPLAIN SELECT * FROM users WHERE age > 30 AND city = 'Beijing';
```
- 关注type（访问类型，至少达到ref或range）、key（使用的索引）、rows（扫描行数）。

3. 表结构设计优化

(1) 合理的数据类型

小而精：如用INT存储IP而非VARCHAR。

-- IP地址存储优化
INSERT INTO servers (ip) VALUES (INET_ATON('192.168.1.1'));
SELECT INET_NTOA(ip) FROM servers;

时间类型：优先DATETIME或TIMESTAMP，避免字符串存储。

(2) 范式与反范式平衡

适当冗余：减少JOIN次数。

-- 订单表冗余用户名（反范式设计）
CREATE TABLE orders (
  order_id INT,
  user_id INT,
  user_name VARCHAR(50),  -- 冗余字段
  ...
);

(3) 分区与分表

分区表：按时间或范围拆分数据。

-- 按年分区（MySQL 5.7+）
CREATE TABLE logs (
  id INT,
  content TEXT,
  create_time DATETIME
) PARTITION BY RANGE (YEAR(create_time)) (
  PARTITION p2020 VALUES LESS THAN (2021),
  PARTITION p2021 VALUES LESS THAN (2022)
);

4. 配置与存储优化

(1) InnoDB引擎调优

缓冲池配置：

# my.cnf
innodb_buffer_pool_size = 系统内存的70%-80%
innodb_buffer_pool_instances = 8  # 减少锁竞争

事务优化：

-- 避免长事务，合理设置隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

(2) 主从复制与读写分离

读写分离架构：Java代码中通过数据源路由（如Sharding-JDBC）。

// Spring Boot配置多数据源
@Bean
@ConfigurationProperties("spring.datasource.master")
public DataSource masterDataSource() { ... }

@Bean
@ConfigurationProperties("spring.datasource.slave")
public DataSource slaveDataSource() { ... }

5. 缓存与批量操作

(1) 应用层缓存

Redis缓存热点数据：

// Java代码示例：查询前先查缓存
public Product getProductById(int id) {
    Product product = redis.get("product:" + id);
    if (product == null) {
        product = productDao.findById(id);
        redis.setex("product:" + id, 3600, product);
    }
    return product;
}

(2) 批量操作减少IO

批量插入优化：

// JDBC批量插入
PreparedStatement ps = conn.prepareStatement("INSERT INTO logs (content) VALUES (?)");
for (Log log : logs) {
    ps.setString(1, log.getContent());
    ps.addBatch();
    if (i % 1000 == 0) ps.executeBatch(); // 每1000条提交一次
}
ps.executeBatch();

6. 监控与维护

(1) 慢查询日志

启用慢查询分析：

# my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1  # 超过1秒的查询记录

工具分析：使用pt-query-digest分析慢日志。

(2) 定期维护

表碎片整理：

OPTIMIZE TABLE orders;  -- 重建表，减少碎片

统计信息更新：

ANALYZE TABLE users;  -- 更新索引统计信息

面试回答示例

问题：MySQL数据库层面有哪些优化手段？
回答：
MySQL优化可从多个维度展开：

索引优化：创建高选择性索引，避免索引失效，利用覆盖索引减少回表。
SQL调优：避免SELECT *，优化分页查询，使用EXPLAIN分析执行计划。
表结构设计：选择合适数据类型，平衡范式与反范式，分区表提升查询效率。
配置调整：设置InnoDB缓冲池大小，主从分离降低负载。
缓存策略：结合Redis缓存热点数据，减少数据库访问。
批量处理与监控：批量操作减少事务提交，启用慢查询日志定期优化。

例如，在项目中通过EXPLAIN发现某查询未走索引，添加联合索引后响应时间从2秒降至50毫秒。此外，通过分库分表解决了单表数据过亿的性能瓶颈。

通过以上结构化回答，可系统展示对MySQL优化的全面理解，适用于技术面试中的深度探讨。 🚀

9. 角色和用户多对多关系表设计

多对多关系表设计步骤

在数据库设计中，用户（User）和角色（Role）的多对多关系通常需要三个表来实现。以下是详细设计步骤及最佳实践：

1. 基础表设计

用户表（user）：存储用户基本信息。

CREATE TABLE user (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) NOT NULL UNIQUE,
    password VARCHAR(100) NOT NULL,
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

角色表（role）：存储角色定义。

CREATE TABLE role (
    id INT PRIMARY KEY AUTO_INCREMENT,
    role_name VARCHAR(50) NOT NULL UNIQUE,
    description VARCHAR(200)
);

关联表（user_role）：建立用户与角色的多对多关系。

CREATE TABLE user_role (
    user_id INT NOT NULL,
    role_id INT NOT NULL,
    assigned_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (user_id, role_id),  -- 复合主键防止重复
    FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE CASCADE,
    FOREIGN KEY (role_id) REFERENCES role(id) ON DELETE CASCADE
);

2. 核心设计点

复合主键：
user_role 表使用 (user_id, role_id) 作为复合主键，确保同一用户不能重复分配相同角色。
外键约束：
- ON DELETE CASCADE：删除用户或角色时，自动清理关联表中的记录。
- 若担心外键性能问题（如高并发场景），可在应用层通过事务保证一致性。
索引优化：
- 为关联字段单独建立索引，加速查询：
```
CREATE INDEX idx_user_id ON user_role(user_id);
CREATE INDEX idx_role_id ON user_role(role_id);
```
- 复合主键天然支持按 (user_id, role_id) 查询的覆盖索引。
扩展字段：
若需记录角色分配的附加信息（如分配人、过期时间），可在 user_role 表中添加字段：
```
ALTER TABLE user_role 
    ADD assigned_by INT,
    ADD expires_at DATETIME;
```

3. Java实体映射（JPA/Hibernate）

用户实体（User）：

@Entity
@Table(name = "user")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String username;
    private String password;
    
    @ManyToMany
    @JoinTable(
        name = "user_role",
        joinColumns = @JoinColumn(name = "user_id"),
        inverseJoinColumns = @JoinColumn(name = "role_id")
    )
    private Set<Role> roles = new HashSet<>();
}

角色实体（Role）：

@Entity
@Table(name = "role")
public class Role {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String roleName;
    private String description;
    
    @ManyToMany(mappedBy = "roles")
    private Set<User> users = new HashSet<>();
}

自定义关联实体（可选）：
若 user_role 表有额外字段（如 assigned_at），需创建独立实体类：

@Entity
@Table(name = "user_role")
public class UserRole {
    @EmbeddedId
    private UserRoleId id;  // 复合主键类（包含user_id和role_id）
    
    @ManyToOne
    @MapsId("userId")
    @JoinColumn(name = "user_id")
    private User user;
    
    @ManyToOne
    @MapsId("roleId")
    @JoinColumn(name = "role_id")
    private Role role;
    
    private LocalDateTime assignedAt;
}

@Embeddable
public class UserRoleId implements Serializable {
    private Long userId;
    private Long roleId;
}

4. 查询示例

查询用户的所有角色：

SELECT r.role_name 
FROM user u
JOIN user_role ur ON u.id = ur.user_id
JOIN role r ON ur.role_id = r.id
WHERE u.username = 'john';

查询拥有某角色的所有用户：

SELECT u.username 
FROM role r
JOIN user_role ur ON r.id = ur.role_id
JOIN user u ON ur.user_id = u.id
WHERE r.role_name = 'ADMIN';

5. 设计优化建议

避免循环依赖：
确保应用层逻辑不产生循环角色分配（如角色A依赖角色B，角色B又依赖角色A）。
权限缓存：
频繁查询用户角色时，使用本地缓存（如Caffeine）或Redis缓存角色数据，减少数据库压力。
分库分表：
数据量极大时，可按用户ID对 user_role 表分片，提升查询性能。

总结

表结构：3张表（user、role、user_role），关联表使用复合主键和外键约束。
实体映射：JPA中通过 @ManyToMany 或自定义实体实现。
性能优化：合理使用索引、缓存和分片策略。
扩展性：通过关联表附加字段满足业务扩展需求。

此设计确保了数据一致性、查询效率，并支持常见权限管理场景（如RBAC）。

10. 查一个角色下的所有用户数量的SQL怎么查？

分步解答与SQL示例

假设存在以下三张表：

用户表（users）：存储用户基本信息。

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    username VARCHAR(50)
);

角色表（roles）：存储角色定义。

CREATE TABLE roles (
    role_id INT PRIMARY KEY,
    role_name VARCHAR(50)
);

用户角色关联表（user_roles）：记录用户与角色的多对多关系。

CREATE TABLE user_roles (
    user_id INT,
    role_id INT,
    PRIMARY KEY (user_id, role_id)
);

场景1：已知角色ID，直接统计用户数量

SELECT COUNT(DISTINCT user_id) AS user_count 
FROM user_roles 
WHERE role_id = 1;  -- 假设角色ID为1

说明：

COUNT(DISTINCT user_id)：确保每个用户只计数一次，避免重复关联导致的多余统计。
WHERE role_id = 1：筛选指定角色的用户关联记录。
性能优化：如果 user_roles.role_id 字段有索引，查询速度更快。

场景2：通过角色名称查询用户数量

SELECT COUNT(DISTINCT ur.user_id) AS user_count 
FROM user_roles ur
JOIN roles r ON ur.role_id = r.role_id 
WHERE r.role_name = '管理员';  -- 假设角色名称为'管理员'

说明：

多表连接：通过 JOIN 关联 user_roles 和 roles 表，将角色名称转换为角色ID。
索引建议：在 roles.role_name 和 user_roles.role_id 上创建索引以加速查询。

场景3：返回角色名称和对应的用户数量（扩展需求）

SELECT 
    r.role_name,
    COUNT(DISTINCT ur.user_id) AS user_count 
FROM roles r
LEFT JOIN user_roles ur ON r.role_id = ur.role_id 
GROUP BY r.role_name;

说明：

LEFT JOIN：确保即使某个角色没有关联用户，也能显示数量为0。
GROUP BY：按角色分组统计用户数量。

注意事项

去重必要性：
- 如果业务规则允许一个用户在同一角色下有多条记录（如历史记录），必须使用 DISTINCT。
- 如果关联表设计为唯一约束（如 PRIMARY KEY(user_id, role_id)），可省略 DISTINCT，直接使用 COUNT(user_id)。

索引优化：

-- 在 user_roles.role_id 上添加索引
CREATE INDEX idx_role_id ON user_roles(role_id);

空值处理：
- 使用 LEFT JOIN 时，未分配用户的角色会返回 user_count = 0。
- 若需排除无用户的角色，改用 INNER JOIN。

Java代码中的SQL调用示例

在Java应用中，可通过JDBC或ORM框架（如MyBatis）执行SQL：

// MyBatis Mapper接口
@Select("SELECT COUNT(DISTINCT user_id) FROM user_roles WHERE role_id = #{roleId}")
int countUsersByRoleId(@Param("roleId") int roleId);

// 调用方法
int adminCount = userMapper.countUsersByRoleId(1);

总结

核心SQL：通过 COUNT 聚合函数结合 WHERE 条件过滤角色。
扩展场景：支持通过角色名称查询或批量统计所有角色的用户数。
优化关键：索引设计、去重逻辑、表连接方式选择。

11. count(``)里面的的理解？

**关于 `COUNT()` 中 `` 的理解**

在 SQL 中，COUNT(*) 用于统计表中的行数，其核心含义与使用场景如下：

**1. `*` 的本质含义**

不代表具体列：COUNT(*) 中的 * 并非指所有列，而是表示统计所有行的数量，无论这些行的列是否包含 NULL 值。
忽略列的具体值：数据库引擎不会检查任何列的值，直接统计表中存在的行数。

2. 与其他 `COUNT` 用法的区别

表达式	行为	示例场景
`COUNT(*)`	统计所有行的数量（含 `NULL` 行）。	获取分页查询的总记录数。
`COUNT(列名)`	统计该列非 `NULL` 值的行数。	统计某字段有效数据的数量。
`COUNT(1)`	与 `COUNT(*)` 等价，统计所有行数。	写法简化，结果与 `COUNT(*)` 一致。

3. 性能优化

索引利用：如果表有主键或二级索引，数据库引擎（如 MySQL InnoDB）会优先通过索引统计行数，避免全表扫描。
```
-- 示例：使用主键索引优化 COUNT(*)
EXPLAIN SELECT COUNT(*) FROM users; -- 观察是否使用索引（如 PRIMARY）
```
大表优化：对于海量数据，直接使用 COUNT(*) 可能较慢，可考虑以下方案：
- 缓存总数（如通过 Redis 维护计数）。
- 使用近似值（如 MySQL 的 SHOW TABLE STATUS 中的 Rows 字段）。

4. 常见误区

误区 1：认为 COUNT(*) 需要读取所有列的数据，效率低下。
事实：数据库引擎会优化，仅统计行元信息（如 InnoDB 通过 B+树叶子节点计数）。
误区 2：认为 COUNT(1) 比 COUNT(*) 更快。
事实：两者性能完全一致，1 是常量占位符，不参与计算。

5. 实际应用场景

分页查询：

SELECT COUNT(*) FROM orders WHERE user_id = 100; -- 总记录数
SELECT * FROM orders WHERE user_id = 100 LIMIT 10 OFFSET 0; -- 分页数据

数据完整性校验：

-- 检查某字段的填充率
SELECT 
  COUNT(*) AS total_rows,
  COUNT(email) AS non_null_emails,
  (COUNT(email) / COUNT(*)) * 100 AS fill_rate
FROM users;

总结

COUNT(*)：统计所有行的数量，不关心列值，推荐用于行数统计。
COUNT(列名)：统计特定列的非 NULL 值数量，用于字段有效性分析。
性能：优先依赖数据库优化，避免手动全表扫描。
设计建议：在需要频繁统计总数的场景（如分页），结合缓存或预计算提升性能。

12. 查询创建时间最大的那一条用户数据怎么查询？查询创建时间最大的2条用户数据怎么查询？top和limit的区别？

以下是针对问题的分步解答：

1. 查询创建时间最大的用户数据

方法1：使用 `ORDER BY` 和 `LIMIT`（适用于MySQL、PostgreSQL等）

SELECT * FROM users 
ORDER BY create_time DESC 
LIMIT 1;

说明：
- ORDER BY create_time DESC：按创建时间降序排列，最新记录排在最前。
- LIMIT 1：仅返回第一条记录。
注意：若存在多条相同最大时间的记录，仅返回其中一条。

方法2：使用子查询（通用SQL，返回所有时间最大的记录）

SELECT * FROM users 
WHERE create_time = (SELECT MAX(create_time) FROM users);

说明：
- 子查询 SELECT MAX(create_time) 找到最大时间。
- 主查询匹配所有等于该时间的记录，返回全部满足条件的行。
适用场景：需要返回所有创建时间最大的记录（如时间允许重复）。

2. 查询创建时间最大的两条用户数据

使用 `ORDER BY` 和 `LIMIT`

SELECT * FROM users 
ORDER BY create_time DESC 
LIMIT 2;

说明：
- LIMIT 2：返回前两条记录。
- 若存在时间相同的记录，可能只返回部分结果（如第2名并列时不全部展示）。

使用窗口函数（返回并列记录的精确结果，需数据库支持如MySQL 8.0+）

WITH ranked_users AS (
    SELECT *, 
           DENSE_RANK() OVER (ORDER BY create_time DESC) AS rank 
    FROM users
)
SELECT * FROM ranked_users 
WHERE rank <= 2;

说明：
- DENSE_RANK()：按时间降序排名，允许并列。
- 筛选排名前2的记录，包含所有并列情况（如第1名有多个）。

3. `TOP` 与 `LIMIT` 的区别

语法差异

关键字	数据库支持	语法示例	分页支持
`TOP`	SQL Server、MS Access	`SELECT TOP 5 * FROM users;`	不支持直接分页
`LIMIT`	MySQL、PostgreSQL、SQLite	`SELECT * FROM users LIMIT 5;`	支持分页（`LIMIT m, n`）

功能对比

位置不同：
- TOP 位于 SELECT 子句中，紧接列名。
- LIMIT 位于查询末尾，与其他子句（如 ORDER BY）配合使用。
分页能力：
- LIMIT 支持分页：LIMIT 5, 10 表示跳过前5条，返回后续10条。
- TOP 不支持分页，需结合 OFFSET FETCH（SQL Server 2012+）：
```
SELECT * FROM users 
ORDER BY create_time DESC 
OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY;
```
标准兼容性：
- TOP 和 LIMIT 均非 SQL 标准，属于数据库方言。
- SQL 标准分页语法为 FETCH FIRST n ROWS ONLY（如Oracle 12c+）。

面试回答示例

问题1：如何查询创建时间最大的用户数据？
答：
两种方法：

直接排序取第一条：

SELECT * FROM users ORDER BY create_time DESC LIMIT 1; -- MySQL
SELECT TOP 1 * FROM users ORDER BY create_time DESC;   -- SQL Server

子查询精确匹配（返回所有最大时间的记录）：

SELECT * FROM users 
WHERE create_time = (SELECT MAX(create_time) FROM users);

问题2：如何查询创建时间最大的两条用户数据？
答：

简单场景：

SELECT * FROM users ORDER BY create_time DESC LIMIT 2; -- MySQL
SELECT TOP 2 * FROM users ORDER BY create_time DESC;  -- SQL Server

处理并列数据（如第2名有多个相同时间）：

WITH ranked_users AS (
    SELECT *, DENSE_RANK() OVER (ORDER BY create_time DESC) AS rank 
    FROM users
)
SELECT * FROM ranked_users WHERE rank <= 2; -- MySQL 8.0+ 或 PostgreSQL

问题3：TOP 和 LIMIT 的区别？
答：

语法差异：
- TOP 用于 SQL Server，写在 SELECT 后（如 SELECT TOP 5 *）。
- LIMIT 用于 MySQL，写在查询末尾（如 LIMIT 5）。
功能差异：
- LIMIT 支持分页（LIMIT m, n），TOP 需配合 OFFSET FETCH。
适用场景：
- 根据数据库类型选择，LIMIT 更灵活分页，TOP 适用于简单取前N条。

通过以上分步解析，可清晰展示对SQL查询及关键字的深入理解，适用于技术面试中的多维考察。

面试题解四

1. Session和Cookie的区别？

1. 存储位置

2. 安全性

3. 生命周期

4. 存储内容与容量

5. 性能与扩展性

6. 跨域支持

典型应用场景

技术实现（Java示例）

总结

2. 服务器宕机了，Cookie还能继续用吗？

1. Cookie 的存储位置

2. 服务器宕机的影响

3. 恢复能力的核心因素

4. 实际场景示例

5. 解决方案建议

总结

3. 不用redis，Java后端有没有什么本地缓存的实现方案？

1. 基于内存的缓存框架

(1) Caffeine

(2) Guava Cache

2. 基于Java集合的简易缓存

(1) ConcurrentHashMap + 手动管理

(2) LinkedHashMap实现LRU缓存

3. 集成框架的缓存抽象

(1) Spring Framework Cache

(2) Ehcache（本地模式）

4. 自研缓存方案

技术选型建议

注意事项

4. 多人聊天室这种实时通信如何实现？

1. 核心技术选型

WebSocket 协议

备选方案

2. 实现步骤（以 Spring WebSocket + STOMP 为例）

(1) 添加依赖

(2) 配置 WebSocket

(3) 消息处理与广播

(4) 前端连接（JavaScript）

3. 关键优化点

消息广播效率

高并发处理

安全性

4. 架构示意图

5. 方案对比

6. 面试回答要点

5. WebSocket的理解，什么时候需要用WebSocket？

WebSocket的理解

WebSocket与HTTP对比

何时需要使用WebSocket？

Java后端实现WebSocket

注意事项与优化

总结

6. MySQL聚合函数有哪些？

1. 基础聚合函数

(1) COUNT()

(2) SUM()

(3) AVG()

(4) MAX() / MIN()

2. 高级聚合函数

(5) GROUP_CONCAT()

(6) STDDEV() / STDDEV_POP()

(7) VAR_POP() / VARIANCE()

(8) BIT_AND() / BIT_OR()

3. JSON聚合函数（MySQL 5.7+）

(9) JSON_ARRAYAGG()

(10) JSON_OBJECTAGG()

4. 聚合函数与分组

GROUP BY 与 HAVING

5. 注意事项

6. 面试回答示例

7. MySQL几种联表查询。

MySQL联表查询类型详解

1. 内连接（INNER JOIN）

2. 左连接（LEFT JOIN / LEFT OUTER JOIN）

3. 右连接（RIGHT JOIN / RIGHT OUTER JOIN）

4. 全外连接（FULL OUTER JOIN）

5. 交叉连接（CROSS JOIN）

6. 自连接（SELF JOIN）

(1) `COUNT()`

(2) `SUM()`

(3) `AVG()`

(4) `MAX()` / `MIN()`

(5) `GROUP_CONCAT()`

(6) `STDDEV()` / `STDDEV_POP()`

(7) `VAR_POP()` / `VARIANCE()`

(8) `BIT_AND()` / `BIT_OR()`

(9) `JSON_ARRAYAGG()`

(10) `JSON_OBJECTAGG()`

`GROUP BY` 与 `HAVING`

11. count(``)里面的的理解？

**关于 `COUNT()` 中 `` 的理解**

**1. `*` 的本质含义**

2. 与其他 `COUNT` 用法的区别

方法1：使用 `ORDER BY` 和 `LIMIT`（适用于MySQL、PostgreSQL等）

使用 `ORDER BY` 和 `LIMIT`

3. `TOP` 与 `LIMIT` 的区别