分库分表面试必背

一,背景

        随着互联网的普及,使用人数和场景爆炸式增长,现在随便一个应用系统都可能达到数百万千万甚至更大数量级的数据。大量的数据带来了新的挑战,怎么快速完成增删改查的业务,是应用服务开发者最头痛的问题。面对这个问题,分库分表是一个很好的思路,今天来聊聊分库分表。

二,概念

1,什么是分库分表?

分库分表是一种数据库架构优化技术,本质上就是一种分治思想。通过分库分表将数据分散到多个数据库或表中,来提高系统的性能和稳定性。分库分表可以分为以下几种策略:水平分库、水平分表、垂直分库、垂直分表

下面以订单数据库db_order和订单表tb_order为例来说明。

1.1 水平分库

按照某些规则,比如说按照年份,对订单数据库进行划分,一年一个数据库,如db_order_2024,db_order_2025,下面的表和表结构完全一致,但是存储的数据不一样,分别归属于不同年份的订单数据。

1.2 垂直分库

根据业务功能不同将数据分拆到不同的数据库中,比如订单、用户、商品、客户的数据分别存储到订单数据库、用户数据库、商品数据库和客户数据库中。

1.3 水平分表

对数据表中数据根据某个字段来做分表,比如根据订单创建月份来分表order_01和order_02, 各个表的结构完全一致,只是存储的数据分属于各个不同的月份。

1.4 垂直分表

按照业务和是否常用或者是否强关联来把宽表拆分,比如订单信息中的商品和下单人等信息可以拆分成子表,通过id来关联。

三,落地

具体可以看:看完这篇,别再说不会Spring 分库分表了_spring data jpa 分库分表-CSDN博客

可用的方案其实很多,比如常见的shardingsphere和mycat

四,问题

1,什么情况下需要分表?

根据阿里的规范,建议如下:

图片

事实上,通常在实战中,一般按经验数据达到千万级,就需要分库分表。原因如下:

我们知道:InnoDB管理磁盘的最小单元:页,页大小16KB.

mysql> show global status like '%Innodb_page_size%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.00 sec)

  在日常开发中,对于数据库性能优化,我们首先想到的是索引优化。索引的底层数据结构是B+树。其组织结构如图所示:

图片

树高为3的B+树数据存储计算规则:

根节点计算:

假设数据类型是bigint,大小为8b。数据本身也需要一小块空间,用来存储下一层索引数据页的地址,大小为6b, 那么根节点是可以存储16*1024/(8+6) = 1170 个数据。

其它层节点计算:

第二层:因为每个节点数据结构和跟节点一样,而且在跟节点每个元素都会延伸出来一个节点,所以第二层的数据量是1170*1170=1368900

第三层:因为innodb的叶子节点,是直接包含整条mysql数据的,假设每条数据以1kb计算,那么第三层每个节点为16kb,那么每个节点是可以放16个数据的,所以最终mysql可以存储的总数据为

1170 * 1170 * 16 = 21902400 (千万级)

其实计算结果与我们平时的工作经验也是相符的,一般mysql一张表的数据超过了千万也是得进行分表操作了。

2,如何选择分片键?

  例如,本节我们以订单表的分表为例,一般订单表中含有订单编号:order_id, 用户编号:user_id, 订单创建时间:order_date等。

对于订单表,通常我们可以考虑以下分片键选项:

2.1 订单编号

优点:订单编号通常是唯一的,可以确保每个订单都分散到不同的分片上。这对于保证数据均匀分布和避免热点数据非常有帮助。

2.2 用户编号

优点:用户编号通常也是唯一的,并且如果用户的订单量分布均匀,那么使用用户编号作为分片键可以确保每个用户的订单都在同一个分片上,这对于查询某个用户的所有订单非常高效。

缺点:如果用户的订单量差异很大,那么某些分片可能会存储大量的订单数据,而其他分片可能只有少量的数据。这会导致数据分布不均匀,进而影响查询性能。

2.3 订单创建时间

优点:适用于:按时间范围查询订单的场景。

缺点:可能出现热点数据倾斜问题(即在某个时段产生订单峰值)

3,如何选择数据库主键策略?

在选择主键策略时,需要注意以下几点:

  • 唯一性:确保主键在全局唯一,避免数据冲突。

  • 性能:选择适合的主键类型和生成策略,以提高数据插入、查询和索引的性能。

  • 扩展性:能够适应数据量和并发量增长。

  • 兼容性:选择的主键策略要与使用的数据库兼容。

  在 MySQL 中进行分库分表时,自增主键策略确实需要特别处理,因为传统的自增主键策略在分布式环境下会导致主键冲突。每个数据库实例或分片都会从相同的起始点开始自增,这会导致在不同的分片上生成相同的 ID,进而引发数据冲突。

4,几种常见的主键策略

  1. UUID:UUID 是一个 128 位的值,具有全局唯一性,可以很好地解决分布式环境下的主键冲突问题。但是,UUID 字符串较长,存储和索引效率较低,而且是无序的,可能会影响查询性能。

  2. Snowflake 算法:雪花算法(SnowFlake)是一种分布式ID生成算法,由Twitter开源。其核心思想是使用64位long型数字作为全局唯一的ID,通过时间戳、工作机器ID和序列号等部分来确保ID的全局唯一性。

图片

  1. 结构说明

    • 1位:未使用(因为二进制中最高位是符号位,正数是0,负数是1,一般生成的ID都是正数,所以这一位固定为0)。

    • 41位:时间戳(毫秒级),用来记录时间截的差值(当前时间截 - 开始时间截)。

    • 10位:工作机器ID,包括5位datacenterId(数据中心ID)和5位workerId(工作机器ID),用来表示工作机器的ID。

    • 12位:序列号,用来记录同一毫秒内产生的不同ID,12位可以表示的最大整数为4095,用来表示同一机器同一时间截(毫秒)内产生的4095个ID序号。

  通过这种结构,雪花算法可以保证生成的ID按时间递增,并且整个分布式系统中不会有重复的ID。

  1. 分布式自增 ID 生成器:使用像 Twitter 的 Snowflake、阿里巴巴的 Druid 等分布式 ID 生成器来生成全局唯一的自增 ID。这些生成器通过特定的算法和机制保证在不同实例间生成的 ID 是全局唯一的。

  2. 自增主键 + 分片策略:仍然使用自增主键,但是结合分片策略,确保每个分片上的主键值是唯一的。例如,可以预先为每个分片分配一个 ID 范围,确保在这个范围内的 ID 是唯一的。这种方法需要维护分片的 ID 范围,并在必要时进行调整。

  3. 使用数据库的自增 ID 特性:某些数据库支持在分表时自动处理自增 ID,避免冲突。例如,MySQL 8.0 引入了 AUTO_INCREMENT_INCREMENT 和 AUTO_INCREMENT_OFFSET 这两个系统变量,用于在复制或分片环境中调整自增 ID 的步长和起始值,从而避免冲突。

总之,在分库分表时,自增主键策略需要进行特殊处理,以确保全局唯一性,并根据实际情况选择合适的方案。

5,如何选择分表策略?

选择分库分表的策略时,确实需要根据具体的业务场景和数据特性来决定。例如订单表,以订单ID (order_id) 作为分表键。

5.1 基于范围的策略

适用场景:当订单ID有明确的增长趋势,例如连续的自增ID,并且你知道未来可能的订单数量时,范围分表是一个好选择。

策略实现:可以将订单ID按照范围划分到不同的表中。例如,订单ID【1-1000万】 在表tb_order_01,【1000万-2000万】在表tb_order_02,以此类推。

图片

优点

     查询效率较高,尤其是范围查询。数据迁移和维护相对简单。

缺点

     订单ID的分布必须均匀. 如果订单ID不是连续或可预测的,这种策略可能不适用。

5.2 基于哈希的策略

适用场景:当订单ID没有明确的增长趋势,哈希分表是一个好选择。

策略实现:使用哈希函数对订单ID进行哈希运算,然后根据哈希值的结果决定存储在哪个表中。

table_index = hash(order_id) % tables_num

优点

     负载均衡,每个表的数据分布相对均匀。

缺点

     不利于二次扩容。

5.3 映射表策略

适用场景:当订单ID的分布不均,或者需要灵活控制数据分布时,映射表分表可能是一个好选择。

策略实现:使用一个映射表来记录每个订单ID应该存储在哪个表中。这个映射表可以是内存中的数据结构,也可以是数据库中的一个表。

优点

    灵活,可以根据需要调整数据分布。

缺点

     查询时需要先查询映射表,可能影响性能。

5.4 一致性哈希策略

适用场景:当系统需要高可用性,并且希望在添加或删除节点时尽量减少数据迁移时,一致性哈希可能是一个好选择。

策略实现:使用一致性哈希算法将订单ID映射到哈希环上,然后根据哈希环上的节点(或表)来存储数据。

一致性哈希算法的核心思想是将哈希值空间表示为一个闭合的圆环(哈希环),每个节点负责维护圆环上一段连续的哈希值范围。

图片

  在分库分表的场景中,可以将每个数据库或表看作是一个节点,将这些节点均匀地分布在哈希环上。当插入或查询数据时,根据数据的哈希值将其映射到哈希环上,然后顺时针查找最近的节点(即负责该哈希值范围的数据库或表),将数据插入或查询该节点。
优点
     支持节点的动态扩容。
缺点
     当节点数量变化较大时,可能需要重新计算所有数据的哈希值并进行迁移,增加系统的开销,范围查询和顺序查询可能不如范围分表和哈希分表高效。
 

6,非分片键字段如何查询?

  曾几何时,面试过程中遇到过这样一个问题:假设有一个用户表,你用ID做的分片键,那么有一个类似于name这样的字段如何查询?

这里提供几种常见的思路:

6.1.全局索引

  全局索引是一个跨所有分片的索引,它包含了非分片键字段和对应的分片键信息。查询时,先通过全局索引找到相关的分片键,然后在相应的分片中查询详细数据。

        适用场景:适用于查询频率高、数据量大的非分片键字段。

        优点:查询效率高,可以快速定位到数据所在的分片。

        缺点:全局索引维护成本较高,需要定期更新以保持与分片数据的一致性。

6.2. 数据冗余

  在每个分片中存储部分非分片键字段的数据。这样,即使不直接查询分片键,也可以在分片内快速找到相关数据。

        适用场景:适用于查询性能要求极高,且可以接受一定数据冗余的场景。

        优点:查询性能高,无需跨分片查询。

        缺点:数据冗余增加了存储成本和维护复杂性。

6.3. 应用层处理

  在应用层实现复杂的查询逻辑,将多个分片中的查询结果汇总后进行处理。

        适用场景:适用于查询频率不高,或者可以接受一定延迟的场景。

        优点:灵活性高,可以根据业务需求定制查询逻辑。

        缺点:查询性能可能受到网络延迟和分片数量的影响。

6.4. 使用Elasticsearch

  将非分片键字段的数据同步到Elasticsearch中,利用Elasticsearch强大的搜索和查询能力进行查询。

        适用场景:适用于非结构化数据、全文搜索、复杂查询等场景。

        优点:支持复杂的查询操作,如全文搜索、模糊匹配等;查询性能高,支持分布式部署。

        缺点:需要维护Elasticsearch集群,增加了系统的复杂性;数据同步可能引入一定的延迟。

6.5. 数据库中间件

使用数据库中间件(如ShardingSphere、MyCAT等)来管理分库分表,中间件可以自动处理非分片键字段的查询,将请求路由到正确的分片。

        适用场景:适用于希望减少应用层复杂性的场景。

        优点:简化了应用层的查询逻辑,减少了开发和维护的工作量。

        缺点:需要配置和维护数据库中间件。

7,如何解决热点数据倾斜问题?

热点数据倾斜通常发生在某些特定的数据项(例如,用户激增、促销订单峰值等)等,导致这些数据的查询和更新操作集中在些某特定的数据库或表上,从而造成性能瓶颈。

解决方案:采用Range分库+Hash分表

图片


8,如何解决跨库关联查询?

分库分表后,数据被分散到了不同的数据库或表中。跨库关联查询成为新的问题。为了解决这个问题,可以采取以下几种策略:

  1. 字段冗余:对于经常需要进行关联查询的字段,可以考虑将这些字段冗余到每个相关的表中。这样,在进行查询时就不需要跨库关联,可以直接在单个表内完成查询。例如,如果经常需要查询合同和客户的关联信息,可以在合同表中冗余一些客户的基础字段,这样查询时就不需要跨库关联客户表。

  2. 数据同步:如果某个系统经常需要查询另一个系统的数据,可以在当前系统中创建一张对应的表,并通过ETL或其他数据同步工具定时同步所需的数据。这样,查询时就可以直接在本地表中完成,避免了跨库关联查询。

  3. 全局表(广播表):对于某些基础数据,如行名行号信息等,如果它们被多个业务系统频繁使用,可以考虑在所有的数据库中都存储这些基础数据。这样,无论哪个系统需要这些数据,都不需要进行跨库关联查询。

  4. ER表(绑定表):对于存在逻辑主外键关系的表,如订单表和订单明细表,可以考虑将它们的数据物理上存储在一起,形成一个绑定表。这样,查询时就可以在一个表中完成主表和明细表的关联查询,避免了跨库关联。

  5. 使用分布式中间件:分布式中间件如Sharding-JDBC、MyCAT等,可以将多个物理数据库视为一个逻辑数据库。这些中间件能够处理复杂的联合查询、排序、聚合等SQL操作,并根据分片规则指导SQL语句的执行。它们能够解决分库分表后的通过程序聚合汇总结果,解决跨库关联查询问题。

  6. 应用层数据聚合:在应用层,可以编写逻辑来聚合来自不同数据库或表的数据。这通常涉及发起多个数据库查询,然后在应用层将结果集合并成所需的结构。

需要注意的是,虽然上述方法可以解决跨库关联查询的问题,但它们也会带来一些额外的复杂性。在设计分库分表方案时,需要综合考虑业务需求、数据量、查询频率等因素,选择合适的策略来平衡性能和可维护性。同时,随着业务的发展和数据量的增长,可能需要对分库分表方案进行调整和优化。
 

9,如何解决分库分表后排序问题?

  分库分表后,排序和分页问题变得相对复杂,因为数据不再集中在一个单一的数据库或表中。解决这些问题需要综合考虑多种因素,包括数据量、查询频率、业务需求等。以下是一些解决分库分表后排序和分页问题的策略:

  1. 全局排序字段:在分库分表时,可以引入一个全局排序字段,所有分片都基于这个字段进行排序。这样,即使数据分布在不同的分片中,也可以保证整体排序的一致性。

  2. 数据同步与合并:在查询时,从各个分片中分别获取数据,然后在应用层将这些数据按照排序规则进行合并。这种方式需要处理大量的数据传输和合并逻辑,可能对性能有一定影响。

  3. 中间件支持:使用支持分库分表的中间件,如ShardingSphere、MyCAT等。这些中间件通常提供了强大的排序功能,能够处理分库分表后的排序问题。

  4. 预算与缓存:对于某些固定的排序需求,可以预先计算排序结果并缓存起来,减少实时计算的压力。
     

10,如何解决分库分表后分页问题?

        10.1 分页参数调整: 在分库分表的情况下,传统的LIMIT OFFSET分页方式可能不再适用。可以考虑调整分页参数,比如使用基于游标(cursor)的分页方式,或者基于时间戳、ID等排序字段的范围查询来实现分页。
        10.2 数据聚合: 类似于排序问题的解决方式,从各个分片中分别获取数据,然后在应用层进行数据聚合,实现分页功能。
        10.3 中间件支持:使用支持分库分表的中间件,这些中间件通常也提供了分页功能的支持,能够简化分页查询的处理。
        10.4 限制分页:对于深度分页的需求,可以考虑限制分页的深度,避免查询大量的数据。例如,只支持查询前100页的数据。
        10.5 预加载与缓存:对于经常访问的分页数据,可以考虑预加载并缓存起来,减少实时查询的开销。

11,分库分表如何扩容?

  当数据量逐渐增加,需要进行分库分表的扩容时,可以从以下几个方面来考虑和制定策略:

       11.1. 数据增长评估: 要对数据的增长趋势进行准确的评估,通过分析历史数据、业务发展趋势以及用户增长情况,可以预测未来的数据量增长情况。一般预估未来3~5年的数据增长。
        11.2. 选择合适的分片键: 选择一个合适的分片键是分库分表的关键。分片键应该能够均匀分布数据,避免某些数据库或表过载。同时,分片键的选择也要考虑到查询性能和数据一致性等因素。
        11.3. 实施扩容: 基于数据增长趋势和分片键的选择,制定详细的扩容计划。这包括确定扩容的时间点、扩容的目标规模、数据迁移和重新分配的策略等。确保扩容过程能够顺利进行,尽可能减少对业务的影响。
        11.4. 数据迁移与重新分配: 在扩容过程中,需要进行数据迁移和重新分配。这通常涉及到将现有数据从旧的数据库或表迁移到新的数据库或表中。可以使用数据迁移工具或自动化脚本来完成这个过程,确保数据的完整性和一致性。
        11.5. 负载均衡: 在扩容后,需要确保数据在新旧数据库或表之间均匀分布,以实现负载均衡。可以使用负载均衡器或支持分库分表的中间件来动态分配请求,确保系统的性能和稳定性。
        11.6. 监控与调优: 在扩容过程中和扩容后,需要对系统进行持续的监控和调优。通过监控数据库或表的负载情况、查询性能等指标,及时发现并解决性能瓶颈和故障。同时,根据实际需求进行调优,如调整索引、优化查询语句等,以提升系统的整体性能。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/689757.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Linux网络编程套接字

目录 认识端口号认识传输层协议TCP/UDP网络字节序socket编程接口实现简单的UDP网络程序实现远程执行服务器shell指令Windows套接字编写UDP实现一个简单的聊天室实现简单的TCP网络程序TCP实现一个中英互译程序守护进程原理 认识端口号 在进行网络通信的时候是不是我们两台机器…

grafana配置钉钉告警模版(一)

1、配置钉钉告警模版 创建钉钉告警模版,然后在创建钉钉告警时调用模版。 定义发送内容具体代码 my_text_alert_list 是模版名称后面再配置钉钉告警时需要调用。 {{/* 定义消息体片段 */}} {{ define "my_text_alert_list" }}{{ range . }}告警名称&…

SpringAop是什么?

简单介绍: AOP:Aspect Oriented Programming (面向切面编程、面向方面编程),其实就是面向特定方法编程。 场景: 比如现在有一个需求,我要统计每一个业务方法的耗时时长, 我们只需在业务方法的前面获取一个…

srs 边缘集群

srs官方关于边缘集群的介绍: Edge Cluster | SRS 本篇分析一下边缘集群中上行边缘节点的处理逻辑。 关于上行的边缘节点: SRS对于上行边缘,采取直接代理方式,并没有采取边缘缓存方式。所谓边缘缓存方式,即推流到边…

操作系统概念

一、概念 任何计算机系统都包含一个基本的程序集合,称为操作系统(OS)。笼统的理解,操作系统包括: 内核(进程管理,内存管理,文件管理,驱动管理)其他程序(例如函数库&…

区块链技术和Hyperledger Fabric介绍

1 区块链介绍 1.1 区块链技术形成 1.1.1 起源 在比特币诞生之时,技术专家们开始研究比特币的底层技术,并抽象提取出来,形成区块链技术,或者称分布式账本技术。 1.1.2 定义 简称BT(Blockchain technology&#xff…

【递归】【后续遍历】【迭代】【队列】Leetcode 101 对称二叉树

【递归】【后续遍历】Leetcode 101 对称二叉树 解法一: 递归:后序遍历 左右中解法二: 迭代法,用了单端队列 ---------------🎈🎈对称二叉树 题目链接🎈🎈------------------- 解法一…

Eclipse - Code Templates

Eclipse - Code Templates References Window -> Preferences -> C/C -> Code Style -> Code Templates 配置默认代码模板,可以点击 Export 将自己配置好的 Code Templates 导出去,以便备份和共享。 References [1] Yongqiang Cheng, https…

Docker原理及概念相关

Docker最核心的组件 image:镜像,构建容器,也可以通过Dockerfile文本描述镜像的内容。 (我们将应用程序运行所需的环境,打包为镜像文件) Container:容器 (你的应用程序,就跑在容器中 ) 镜像仓库(dockerhub)(…

应急响应实战笔记02日志分析篇(5)

第5篇:MySQL日志分析 常见的数据库攻击包括弱口令、SQL注入、提升权限、窃取备份等。对数据库日志进行分析,可以发现攻击行为,进一步还原攻击场景及追溯攻击源。 0x01 Mysql日志分析 general query log能记录成功连接和每次执行的查询,我们…

《白话C++》第10章 STL和boost,Page84 shared_ptr示例使用,容器中的指针

容器中的指针在容器解体时经常忘了释放&#xff1f;指针存放在容器中多次&#xff0c;结果被重复释放&#xff1f;这个问题&#xff0c;通过std::shared_ptr都可以完美地解决&#xff1a; #include <iostream> #include <list> #include <vector> #include …

如何使用Net2FTP部署本地Web网站并实现远程文件共享

文章目录 1.前言2. Net2FTP网站搭建2.1. Net2FTP下载和安装2.2. Net2FTP网页测试 3. cpolar内网穿透3.1.Cpolar云端设置3.2.Cpolar本地设置 4.公网访问测试5.结语 1.前言 文件传输可以说是互联网最主要的应用之一&#xff0c;特别是智能设备的大面积使用&#xff0c;无论是个人…

【DBeaver+mysql】如何在DBeaver中创建mysql服务的连接并新建数据库

一、创建步骤 1、下载安装mysql 8.0&#xff08;注意&#xff0c;安装过程会启动mysql服务&#xff0c;这才是能用命令行执行node处理sql语句的关键&#xff09; 下载地址&#xff1a;https://dev.mysql.com/downloads/file/?id526407 2、下载安装DBeaver数据库管理IDE 3、在…

优化线性回归模型的代价函数

目录 前言1 代价函数与线性回归模型2 单变量线性回归3 双变量线性回归4 优化过程结论 前言 线性回归是机器学习领域中最基础的模型之一&#xff0c;它通过找到最佳拟合直线来预测连续型输出变量。在线性回归中&#xff0c;代价函数&#xff08;Cost Function&#xff09;起着至…

查询获取SMBIOS的方法

一、用于在本地查询 SMBIOS 的示例 PowerShell 脚本 Microsoft网站参考 以下 ChassisTypes 列表是从最新的 DMTF SMBIOS 规范复制的。 # Set-ExecutionPolicy or Script Signing documentation needs to be reviewed # Current script is designed to run on individual mach…

x86下使用硬件实现的任务切换(TSS表)---使用代码讲解

实现任务切换(使用TSS) 视频讲解可以看这一个课程 • The current program, task, or procedure executes a JMP or CALL instruction to a TSS descriptor in the GDT. • The current program, task, or procedure executes a JMP or CALL instruction to a task-gate descri…

并查集,真好用,一次AC不是梦!

文章目录 &#x1f680;前言&#x1f680;并查集&#x1f680;并查集的两个优化✈️路径压缩✈️按秩合并 &#x1f680;并查集代码模板 &#x1f680;前言 大家好啊&#xff01;今天阿辉来给大家介绍一种简洁而优雅的数据结构——并查集&#xff0c;不知道各位是否了解它&…

ssh连接服务器需要子网掩码吗?

IP寻址需要同时知道IP地址和子网掩码&#xff0c;但是在通过ssh连接服务器时&#xff0c;只需要知道IP地址和端口号就可以了&#xff0c;ssh通讯为什么不需要子网掩码呢。在不知道子网掩码的前提下&#xff0c;可以正确找到IP对应的主机吗&#xff1f; 不需要&#xff0c;SSH&a…

桌面显示器应用Type-C接口

随着科技的飞速发展&#xff0c;桌面显示器作为我们日常工作中不可或缺的设备之一&#xff0c;也在不断地更新换代。其中&#xff0c;Type-C接口的应用成为了桌面显示器发展的一个重要趋势。那么&#xff0c;桌面显示器应用Type-C接口究竟有什么好处呢&#xff1f; 首先&#x…

职场隐私守则:关系再好也别碰这些“雷区”

在职场中&#xff0c;与同事建立良好的关系是非常重要的&#xff0c;它有助于提高工作效率、增进团队协作&#xff0c;并且能够为日常的工作带来便利。 然而&#xff0c;即便与同事的关系再亲密&#xff0c;也有一些隐私话题是绝对不能轻易透露的。 在与同事和领导相处时&…