偶遇面试题合集（答案为ChatGPT或网上收集所得）

有哪些导致索引失效的场景？

索引是数据库中的重要组成部分，可以提高查询的效率。但是在一些情况下，索引可能会失效，导致查询变慢。以下是一些可能导致索引失效的场景：

1. 对索引列进行了函数操作：在查询中对索引列进行函数操作，如对日期列使用函数YEAR()或MONTH()，会导致索引失效。
2. 对索引列进行了类型转换：如果查询中将索引列强制转换成其他数据类型，如使用CAST()或CONVERT()函数，也会导致索引失效。
3. 使用了不等于操作符：在查询中使用!=或<>操作符，会导致索引失效。
4. 使用了LIKE操作符：在查询中使用LIKE操作符进行模糊查询，如果模式以通配符%开头，也会导致索引失效。
5. 对多个列进行索引：如果一个查询涉及多个列，但是只有其中部分列被索引，也可能导致索引失效。
6. 数据表中数据分布不均：如果数据表中某些列的值分布不均，导致索引失效的可能性就会增加。
7. 数据库中存在大量重复的索引：如果同一个列上存在多个相同的索引，可能会导致索引失效，并且会增加维护成本和存储空间。

总之，要想保证索引的有效性，应该避免上述情况的发生，并且定期对索引进行优化。

线程池有用过吗？有哪些核心参数？分别什么作用？

是的，线程池是Java多线程编程中非常常用的工具，可以有效地控制并发线程的数量和资源消耗。

线程池的核心参数包括：

1. corePoolSize：线程池中的核心线程数，当提交一个任务到线程池时，如果核心线程数小于corePoolSize，会直接创建一个新的线程来执行该任务，即使有空闲的线程也不会使用。
2. maximumPoolSize：线程池中最大的线程数，当提交的任务数大于corePoolSize时，线程池会继续创建新的线程来处理任务，直到达到maximumPoolSize。
3. keepAliveTime：当线程池中的线程数超过corePoolSize时，多余的空闲线程在keepAliveTime时间内会被销毁。
4. workQueue：用于存储等待执行的任务的队列，当核心线程数已经全部占用且队列已满时，线程池会继续创建新的线程。
5. threadFactory：用于创建新线程的工厂类，可以通过设置ThreadFactory来自定义线程的名称、优先级等属性。
6. rejectedExecutionHandler：当线程池无法处理更多的任务时，会使用RejectedExecutionHandler处理被拒绝的任务，默认的处理方式是抛出RejectedExecutionException异常。

这些参数的作用如下：

1. corePoolSize和maximumPoolSize用于控制线程池中的线程数量，可以根据具体的业务需求来设置线程池的大小，避免资源的浪费和线程数量的过多。
2. keepAliveTime用于控制非核心线程的存活时间，当线程池中的线程数量超过corePoolSize时，多余的线程会在一段时间内被销毁，以避免资源的浪费。
3. workQueue用于存储等待执行的任务，可以通过设置不同的队列来调整线程池的执行策略。
4. threadFactory和rejectedExecutionHandler可以通过自定义实现来控制线程池中线程的创建和任务的处理方式，使得线程池更加适合具体的业务需求。

WebSocket协议和HTTP协议的区别？

WebSocket协议和HTTP协议都是应用层协议，但是它们在通信方式、消息格式和适用场景等方面有很大的不同。

1. 通信方式：

• HTTP协议是基于请求/响应模式的，客户端向服务器发送请求，服务器接收到请求后返回响应，并在响应后立即断开连接。这种方式适用于客户端和服务器之间只需要短暂的交互的情况，如获取静态资源。
• WebSocket协议是一种基于TCP协议的全双工通信协议，客户端和服务器可以在同一个TCP连接上进行实时的双向通信。这种方式适用于需要实时推送数据或频繁交互的应用场景，如在线游戏、股票行情等。

2. 消息格式：

• HTTP协议的消息格式是固定的，请求和响应的格式都是由请求行、请求头和请求体组成，请求体可以是JSON、XML、二进制数据等格式。
• WebSocket协议的消息格式是自定义的，数据可以是纯文本、JSON、二进制数据等格式。

3. 适用场景：

• HTTP协议适用于客户端和服务器之间交互较少、需要请求和响应的场景，如浏览器请求静态资源、发送表单数据等。
• WebSocket协议适用于客户端和服务器之间需要实时通信、频繁交互的场景，如聊天应用、实时推送、在线游戏等。

总之，HTTP协议是一种无状态、请求/响应模式的协议，适用于简单的请求和响应场景，而WebSocket协议则是一种全双工通信协议，适用于需要实时通信的场景。

cookie 和 session 的区别？

Cookie和Session都是Web开发中用于维持状态的机制，但它们在实现方式和使用场景上有所不同。

1. 实现方式：

• Cookie是在客户端（浏览器）中保存一段数据，并在每次请求时都会将这个数据携带到服务器端，通常是在HTTP响应头中设置Set-Cookie字段，浏览器会自动保存这个Cookie，下次请求时会自动携带到服务器端。在服务端，可以通过HTTP请求头中的Cookie字段来获取客户端发送的Cookie值。
• Session是在服务端创建一份数据，并为这份数据生成一个唯一的标识（session id），并将这个标识发送给客户端保存在Cookie中或通过URL传递，客户端下次请求时再将这个标识发送给服务端，服务端可以通过这个标识来获取对应的数据。在服务端，Session数据通常保存在内存或缓存中，也可以保存在数据库中。

2. 使用场景：

• Cookie通常用于客户端的状态维护，例如记录用户的登录状态、购物车信息、网站偏好等，可以在客户端存储一些简单的信息。
• Session通常用于服务端的状态维护，例如记录用户的登录信息、权限验证、保存用户的临时数据等，可以在服务端存储一些较为复杂的数据。

3. 安全性：

• 由于Cookie是保存在客户端的，因此存在一定的安全风险，例如Cookie被窃取、篡改、伪造等问题，容易引发XSS、CSRF等安全问题。
• Session则存在服务端，因此相对安全，但如果Session id被窃取，则也会存在安全风险，容易引发Session劫持等安全问题。

总之，Cookie和Session都是用于维持状态的机制，但它们的实现方式和使用场景有所不同，需要根据具体的业务需求来选择合适的机制。同时，在使用Cookie和Session时需要注意安全性问题，避免出现安全漏洞。