【备战春招】第9天+统计上班时间

6-2 【案例】统计上班时间
ps: 最近面试，MySQL问的最多的问题就是索引。文章最后会补充这块内容。

表结构：

表说明：
emp_id:员工编号
event_day:此事件发生的日期
in_time:员工进入办公室的时间
out_time:员工离开办公室的时间

编程目标：编写SQL，计算每位员工每天在办公室的总时间
编程思路：
办公室的总时间===>out_time - in_time
结果集：

编程代码：

select emp_id,event_day,(out_time - in_time)
from employees;

编程结果：

代码解读：
employees 表 表示员工表，
包含 emp_id（员工编号）、event_day（日期）、in_time（进入办公室时间）和 out_time（离开办公室时间）四个字段。
out_time - in_time 计算时间差，计算员工每天在办公室的总时间。
===============================================
说下索引相关的知识。
什么是索引？
索引（Index）是一种数据结构，
用于快速定位和访问数据库表中的数据。

它类似于书的目录，可以帮助数据库引擎更快地找到需要查询的数据，提高查询效率。
索引通常包含一个或多个列的值，每个值都对应着一个或多个行的物理位置。

在 MySQL 中，可以使用 CREATE INDEX 语句创建索引。（MongoDB中使用create_index）
索引的类型包括 B-tree 索引、哈希索引、全文索引等。

B-tree 索引是最常用的一种索引类型，它通过建立一棵树来存储索引，可以快速定位需要查询的数据。

哈希索引则是将索引值通过哈希算法转换为哈希码，再通过哈希表进行存储和访问，适用于等值查询。

全文索引则可以用于全文搜索，它将文本数据拆分为单词并建立索引，可以快速查找包含特定单词的文本。

使用索引可以提高查询效率，但也会带来一些额外的开销，如索引占用的磁盘空间、索引维护的开销等。因此，在创建索引时需要权衡索引的使用场景和对数据库性能的影响。

说下聚簇索引和非聚簇索引？
聚簇索引（Clustered Index）
是一种特殊的索引类型，它决定了表中数据行的物理存储顺序，并且每个表只能有一个聚簇索引。在聚簇索引中，数据行被存储在索引中，而不是存储在另一个位置。

当创建聚簇索引时，数据库会根据索引列的值对表中的数据行进行排序，并将数据行存储在磁盘上。当查询使用聚簇索引列时，数据库可以直接使用聚簇索引进行查找，从而提高查询效率。

聚簇索引的好处是可以提高查询效率，因为数据行被存储在索引中，查询时不需要访问磁盘上的其他位置。此外，由于数据行被存储在聚簇索引中，所以在对索引列进行聚集操作（如 COUNT、SUM、AVG 等）时，可以更快地完成计算。

但聚簇索引也有一些限制和缺点。由于聚簇索引决定了数据行的物理存储顺序，因此在插入和删除数据行时可能需要重新组织数据，导致开销较大。另外，由于每个表只能有一个聚簇索引，因此在需要使用多个索引进行查询的情况下，可能需要使用辅助索引来提高查询效率。

非聚簇索引（Non-Clustered Index）
是另一种常见的索引类型，与聚簇索引不同的是，它并不决定表中数据行的物理存储顺序。非聚簇索引是通过创建一个独立的数据结构来存储索引列的值，并将每个索引项指向存储数据行的物理位置。

当使用非聚簇索引进行查询时，数据库需要先在索引中查找满足条件的行，然后再根据行指针找到对应的数据行。由于数据行并不存储在索引中，因此非聚簇索引相对于聚簇索引来说更节省磁盘空间。

非聚簇索引也可以包含多个列，通常使用最左匹配规则（leftmost prefix rule），即从索引列的左侧开始匹配查询条件，直到找到第一个不匹配的列为止。另外，非聚簇索引也可以包含包括聚簇索引在内的所有表列，这种索引称为覆盖索引（Covering Index），它可以避免在查询时访问表中的数据行，从而提高查询效率。

虽然非聚簇索引相对于聚簇索引来说更节省磁盘空间，但在使用非聚簇索引进行查询时，需要进行两次查找，因此查询效率相对于聚簇索引来说稍低一些。同时，非聚簇索引可能会导致较大的索引开销，因为需要存储索引列的值以及指向数据行的行指针。

说下非聚簇索引 聚簇索引 区别？
聚簇索引和非聚簇索引的主要区别在于它们决定了表中数据行的物理存储方式和索引的数据结构。

聚簇索引决定了表中数据行的物理存储方式，即按照聚簇索引列的值进行排序，然后将数据行存储在磁盘上。因此，表只能有一个聚簇索引。当使用聚簇索引进行查询时，可以直接使用索引进行查找，并且在对索引列进行聚集操作时可以更快地完成计算。

非聚簇索引并不决定表中数据行的物理存储方式，而是通过创建一个独立的数据结构来存储索引列的值，并将每个索引项指向存储数据行的物理位置。非聚簇索引可以包含多个列，通常使用最左匹配规则。当使用非聚簇索引进行查询时，需要先在索引中查找满足条件的行，然后根据行指针找到对应的数据行。

聚簇索引和非聚簇索引的选择取决于具体的情况。如果经常需要对表进行聚集操作，例如对索引列进行聚集计算，那么聚簇索引可能更适合。如果需要在多个列上进行查询，那么可以创建多个非聚簇索引。此外，由于聚簇索引决定了表中数据行的物理存储方式，因此在进行数据插入和删除操作时，可能需要进行数据重组，这可能导致开销较大。

说下用户的一个请求是怎么到达后端的？
用户请求到达后端的过程大致可以分为以下几个步骤：

1.用户在前端页面输入URL或者点击页面上的链接，浏览器将请求发送到服务器。

2.请求首先经过DNS解析，将URL解析为IP地址，找到对应的服务器。

3.浏览器向服务器发送请求，通常使用HTTP协议，请求报文中包含请求方式、URL、请求头、请求体等信息。

4.服务器接收到请求后，根据请求URL和请求方式等信息，将请求转发给对应的后端应用服务器。

5.后端应用服务器接收到请求后，根据请求信息进行处理，包括解析请求参数、校验权限、查询数据库等操作。

6.处理完成后，后端应用服务器将响应结果返回给前端，通常使用HTTP响应报文，响应报文中包含响应状态码、响应头、响应体等信息。

7.浏览器接收到响应结果后，根据响应状态码和响应类型等信息进行处理，例如渲染页面、解析响应数据等操作。

图形验证码 后端 前端怎么设计？
图形验证码是一种常用的验证码方式，它通过图像识别来验证用户身份。一般来说，图形验证码的设计需要前后端共同协作完成。

前端设计：

1.生成验证码：前端应该通过AJAX请求后端API接口，生成验证码图片。

2.显示验证码：前端应该将生成的验证码图片渲染到前端页面中，以供用户查看。

3.验证用户输入：前端应该通过表单提交将用户输入的验证码传递到后端进行验证。

后端设计：

1.生成验证码：后端应该设计一个API接口，接受前端的请求，生成验证码图片，并将验证码图片的相关信息保存到会话(session)中，以便后续验证。

2.验证用户输入：后端应该设计一个API接口，接受前端提交的用户输入信息，从会话(session)中获取生成的验证码信息，对用户输入进行验证。

3.防止暴力攻击：后端应该设计相关的安全机制，如验证码有效期、验证码使用次数限制等，以防止暴力攻击。

网站首页的展示，走的是后端还是Nginx?
网站首页的展示既可以走后端也可以走Nginx。

如果采用后端渲染方式，当用户访问网站首页时，用户请求会到达后端服务器，后端服务器会根据请求内容，动态生成网站首页的HTML页面并返回给用户。
这种方式的优点是灵活性高，可以根据用户请求内容进行动态生成，适用于复杂的业务场景和交互逻辑。

如果采用Nginx作为反向代理，当用户访问网站首页时，用户请求会先到达Nginx服务器，Nginx服务器会根据配置将请求转发给对应的后端服务器，后端服务器返回HTML页面后，Nginx服务器会将页面直接返回给用户。

这种方式的优点是响应速度快，适用于访问量大，但页面内容较为简单的网站首页场景。

需要注意的是，这两种方式并不是互斥的，实际应用中可以根据业务场景的需要进行灵活选择。

Redis 排行榜 设计？
一般来说，排行榜包括以下几个元素：

排名：每个用户在排行榜中的排名位置。

用户ID：用户在系统中的唯一标识符。

用户分数：用户在排行榜中所对应的分数。

针对这些元素，可以采用Redis有序集合(sorted set)来实现排行榜功能。在Redis有序集合中，每个元素都有一个对应的分值(score)，Redis会根据分值来对元素进行排序。

回答：使用 Redis 有序集合对排行榜的元素进行排序。

用户登录 两个用户 输入同一个手机号 redis存储验证码 校验能通过吗？
参考答案1：
无法确定是否校验通过，因为具体的校验逻辑不清楚，这里提供一种校验的思路，仅供参考。

1.一般来说，用户登录时输入的手机号和验证码需要进行校验，可以采用以下步骤：

2.用户输入手机号和验证码。

3.后端服务器根据手机号从Redis中获取对应的验证码。

4.后端服务器将用户输入的验证码和Redis中的验证码进行比对，如果相同，则认为校验通过。

5.如果校验通过，后端服务器可以根据手机号查询用户信息，并生成一个token，将token返回给客户端，表示用户已经登录成功。

需要注意的是，由于手机号和验证码是在客户端输入的，存在一定的安全风险，比如可能会被恶意攻击者盗用。为了加强安全性，可以采用一些安全措施，如限制用户尝试校验次数、增加图片验证码、采用双因素认证等方式。

参考答案2：
如果两个用户使用同一个手机号进行登录并存储到Redis中，那么在校验时，后端服务器会根据手机号从Redis中获取验证码。因为两个用户存储的验证码是相同的，所以在第二步获取验证码时，会取到同一个验证码。

在第三步校验验证码时，后端服务器会将用户输入的验证码和Redis中获取的验证码进行比对，由于两个用户输入的验证码相同，且验证码和Redis中存储的验证码也相同，所以校验通过。

因此，如果两个用户使用同一个手机号进行登录，且验证码也相同，那么在Redis存储和校验的过程中，是可以通过校验的。但是，由于两个用户共用同一个手机号可能会带来安全性问题，因此一般不建议这样使用。