确定索引代价的方法和装置与流程

1.本公开涉及数据库领域，并且更为具体地，涉及一种确定索引代价的方法和装置。


背景技术：

2.在关系型数据库中，基表访问路径选择方法是指数据库的优化器选择索引或索引路径的方法。索引路径选择方法需要评估每一个索引的代价并选择代价最小的索引来访问数据库中的表。
3.通常来说，索引的代价评估取决于很多因素。例如，索引的代价评估可以考虑以下因素中的一种或多种：扫描的行数，回表的行数，投影的列数，谓词的个数等。这些因素中的大部分因素均需要通过数据库系统维护的统计信息计算得到。
4.在影响索引代价的因素中，行数信息是影响索引代价的重要因素。在关系型数据库中，扫描索引的代价和回表的代价，均是基于行数信息确定的。
5.传统的关系型数据库一般基于buffer-pool的存储引擎对数据进行管理。在此类存储引擎中，基于统计信息计算出的行数信息与数据库中真实存储的行数信息一般是匹配的，所以基于该行数信息进行索引代价的计算通常不会存在太大的问题。
6.但是，lsm树存储引擎的索引代价计算方法和传统的基于buffer-pool的存储引擎有着显著的区别。传统的行数信息计算方式是没办法准确的用来评估lsm树存储引擎的索引的代价，从而导致数据库系统的优化器可能没办法选到较优的基表访问路径。


技术实现要素：

7.本公开提供一种确定索引代价的方法和装置，以提高lsm树存储引擎中的索引代价评估的准确性。
8.第一方面，提供一种确定索引代价的方法，所述方法应用于基于lsm树存储引擎的数据库，所述数据库中存储有基线数据和增量数据，所述基线数据和所述增量数据包含索引的数据，所述索引具有物理行，所述索引的物理行的行数为所述基线数据中包含的所述索引的行数和所述增量数据中包含的所述索引的行数之和，所述方法包括：接收第一数据库查询语句；根据所述第一数据库查询语句确定所述索引需要被扫描的物理行的行数；根据所述物理行的行数确定扫描所述索引的代价。
9.可选地，作为一种可能的实现方式，所述索引还具有逻辑行，所述索引的逻辑行的行数为所述基线数据中包含的所述索引的行和所述增量数据中包含的所述索引的行经过合并之后的剩余行的行数，所述方法还包括：根据所述第一数据库查询语句确定所述索引需要回表的逻辑行的行数；根据所述逻辑行的行数确定所述索引的回表代价。
10.可选地，作为一种可能的实现方式，所述索引需要被扫描的物理行的行数是基于第一行数信息和第二行数信息确定的，所述第一行数信息用于指示所述基线数据中包含的行数，所述第二行数信息用于指示所述增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。
11.可选地，作为一种可能的实现方式，所述索引需要回表的逻辑行的行数是基于第一行数信息和第二行数信息确定的，所述第一行数信息用于指示所述基线数据中包含的行数，所述第二行数信息用于指示所述增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。
12.可选地，作为一种可能的实现方式，所述第一行数信息是从所述基线数据的元数据中获取的。
13.可选地，作为一种可能的实现方式，所述第二行数信息是通过对所述增量数据进行动态采样获取的。
14.第二方面，提供一种确定索引代价的装置，所述装置包括基于lsm树存储引擎的数据库，所述数据库中存储有基线数据和增量数据，所述基线数据和所述增量数据包含索引的数据，所述索引具有物理行，所述索引的物理行的行数为所述基线数据中包含的所述索引的行数和所述增量数据中包含的所述索引的行数之和，所述装置包括：接收模块，用于接收第一数据库查询语句；第一确定模块，用于根据所述第一数据库查询语句确定所述索引需要被扫描的物理行的行数；第二确定模块，用于根据所述物理行的行数确定扫描所述索引的代价。
15.可选地，作为一种可能的实现方式，所述索引还具有逻辑行，所述索引的逻辑行的行数为所述基线数据中包含的所述索引的行和所述增量数据中包含的所述索引的行经过合并之后的剩余行的行数，所述装置还包括：第三确定模块，用于根据所述第一数据库查询语句确定所述索引需要回表的逻辑行的行数；第四确定模块，用于根据所述逻辑行的行数确定所述索引的回表代价。
16.可选地，作为一种可能的实现方式，所述索引需要被扫描的物理行的行数是基于第一行数信息和第二行数信息确定的，所述第一行数信息用于指示所述基线数据中包含的行数，所述第二行数信息用于指示所述增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。
17.可选地，作为一种可能的实现方式，所述索引需要回表的逻辑行的行数是基于第一行数信息和第二行数信息确定的，所述第一行数信息用于指示所述基线数据中包含的行数，所述第二行数信息用于指示所述增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。
18.可选地，作为一种可能的实现方式，所述第一行数信息是从所述基线数据的元数据中获取的。
19.可选地，作为一种可能的实现方式，所述第二行数信息是通过对所述增量数据进行动态采样获取的。
20.第三方面，提供一种确定索引代价的装置，包括：存储器，用于存储指令；处理器，用于执行所述存储器中存储的指令，以执行如第一方面或第一方面中的任意一种可能实现方式所述的方法。
21.第四方面，提供一种计算机可读存储介质，其上存储有用于执行第一方面或第一方面中的任意一种可能的实现方式所述的方法的指令。
22.第五方面，提供一种计算机程序产品，包括用于执行第一方面或第一方面中的任意一种可能的实现方式所述的方法的指令。
23.在考虑了引入了lsm树存储引擎的数据存储特点的前提下，本公开实施例引入了物理行的概念，与传统的统计信息统计出的行数不同，物理行是lsm树存储引擎在扫描索引过程中真实需要访问的行数，因此，物理行概念的引入能够提高索引路径选择的准确性。
附图说明
24.为了更清楚地说明本公开实施例或背景技术中的技术方案，下面将对本公开实施例或背景技术中所需要使用的附图进行说明。
25.图1是lsm树存储引擎的数据存储方式的示例图。
26.图2是lsm树存储引擎的行数信息的示例图。
27.图3是本公开实施例提供的物理行和逻辑行的确定方式示例图。
28.图4是本公开一个实施例提供的确定索引代价的方法的流程示意图。
29.图5是本公开另一实施例提供的确定索引代价的方法的流程示意图。
30.图6是本公开一个实施例提供的确定索引代价的装置的流程示意图。
31.图7是本公开另一实施例提供的确定索引代价的装置的流程示意图。
具体实施方式
32.下面结合本公开实施例中的附图对本公开实施例进行描述。以下描述中，参考形成本公开一部分并以说明之方式示出本公开实施例的具体方面或可使用本公开实施例的具体方面的附图。应理解，本公开实施例可在其它方面中使用，并可包括附图中未描绘的结构或逻辑变化。因此，以下详细描述不应以限制性的意义来理解。例如，应理解，结合所描述方法的揭示内容可以同样适用于用于执行所述方法的对应设备或系统，且反之亦然。例如，如果描述一个或多个具体方法步骤，则对应的设备可以包含如功能单元等一个或多个单元，来执行所描述的一个或多个方法步骤（例如，一个单元执行一个或多个步骤，或多个单元，其中每个都执行多个步骤中的一个或多个），即使附图中未明确描述或说明这种一个或多个单元。另一方面，例如，如果基于如功能单元等一个或多个单元描述具体装置，则对应的方法可以包含一个步骤来执行一个或多个单元的功能性（例如，一个步骤执行一个或多个单元的功能性，或多个步骤，其中每个执行多个单元中一个或多个单元的功能性），即使附图中未明确描述或说明这种一个或多个步骤。进一步，应理解的是，除非另外明确提出，本文中所描述的各示例性实施例和/或方面的特征可以相互组合。
33.在关系型数据库中，基表访问路径选择方法是指数据库的优化器选择索引的方法。因此，基表访问路径选择方法有时也可称为索引路径选择方法。索引路径选择方法需要评估每一个索引的代价并选择代价最小的索引来访问数据库中的表。
34.通常来说，索引的代价评估取决于很多因素。例如，索引的代价评估可以考虑以下因素中的一种或多种：扫描的行数，回表的行数，投影的列数，谓词的个数等。这些因素中的大部分因素均需要通过数据库系统维护的统计信息计算得到。
35.在影响索引代价的因素中，行数信息是影响索引代价的重要因素。在传统的关系型数据库中，扫描索引的代价和回表的代价。上述两种代价均是基于行数信息确定的。
36.以扫描索引的代价为例。通常来讲，扫描索引的代价跟该索引需要被扫描的行数成正比，而索引需要被扫描的行数则是由数据库查询语句中的一部分查询谓词决定的，这
些谓词定义了索引扫描开始和结束位置（也就是说，这些谓词定义了索引的扫描范围（queryrange））。理论上来说，扫描的行数越多，数据库查询语句的执行时间就会越久。
37.以索引回表的代价为例。索引的回表代价跟该索引需要回表的行数也是正相关的，而回表的行数也是由数据库查询语句中的查询谓词来决定的。理论上来说，回表的行数越多，数据库查询语句的执行时间就会越久。
38.在传统的关系型数据库中，行数信息一般是通过优化器中维护的统计信息来计算谓词选择率得到。当然，在一些数据库中，行数信息也可以通过其他更加高级的方式获取，比如通过动态采样的方式获取。举个简单的例子，给定联合索引(a,b)和查询谓词a》1 and a《5 and b《5, 那么谓词a》1 and a《5定义了索引扫描开始和结束的位置，如果满足这两个条件的行数有1万行，那么扫描索引的代价就是1万行的顺序扫描。如果select语句所选择的字段在联合索引(a,b)中是缺失的，则需要回表，假设谓词b《5的谓词选择率是0.5，那么该索引的回表代价为5千行的随机扫描。
39.最近几年，很多数据库系统使用lsm树（lsm-tree）作为它们的存储引擎。lsm树存储引擎把数据分为了如图1所示的两部分：基线数据和增量数据。基线数据也可称为静态数据，增量数据也可称为动态数据。基线数据不会被修改，是只读的，存储于磁盘；所有的修改操作（增、删、改）被记录在增量数据中，增量数据通常先存储于内存中，如果内存中存储的数据量超过一定的阈值，则增量数据会被转储至磁盘中。基线数据和增量数据会定期的合并形成新的基线数据。在lsm树存储引擎中，对于一个查询操作，需要合并lsm树来形成最终的查询结果。
40.传统的关系型数据库一般基于buffer-pool的存储引擎对数据进行管理。在此类存储引擎中，基于上述统计信息计算出的行数信息与数据库中真实存储的行数信息一般是匹配的，所以基于该行数信息进行索引代价的计算通常不会存在太大的问题。
41.但是，lsm树存储引擎的索引代价计算方法和传统的基于buffer-pool的存储引擎有着显著的区别。传统的基于选择率计算的行数信息是没办法准确的用来评估lsm树存储引擎中的索引代价，导致优化器可能没办法选到较优的基表访问路径。
42.考虑图2所示的lsm树存储引擎中的基线数据被删除的一个例子。在图2中，基线数据包含10万行数据，增量数据中维护了对这10万行数据的删除操作。在这种场景下，这张表的总行数是0行，在传统的基于buffer-pool的存储引擎中，扫描索引的代价和扫描索引的行数相匹配，因此扫描会很快完成。但是，在lsm树存储引擎中，扫描会很慢（扫描过程涉及10万行基线数据和10万行增量数据的合并）。由此可见，在lsm树存储引擎中，索引的行数和扫描索引的代价是不匹配的。产生这个问题的原因在于：在基于lsm树的存储引擎上，传统的基于动态采样和谓词选择率计算出来的行数信息不足以反应实际计算代价过程中需要扫描的行数。举个简单的例子，在传统的关系型数据库中，如果插入1万行数据，然后删除其中的1千行数据，那么在计算索引代价的时候会用9千行去计算。但是，在lsm树存储引擎的场景下，如果前文提到的1万行数据存储在基线数据中，1k行数据为存储在内存中的增量数据，那么在计算索引代价的时候，用一万一千行去计算才是准确的。
43.为了解决lsm树存储引擎在计算索引的代价时，行数信息与索引中的真实行数不一致的问题，本公开实施例提供一种新的适于lsm树存储引擎的行数计算方式。该行数计算方式可以应用于基于lsm树存储引擎的数据库，如oceanbase数据库。
44.首先，本公开实施例引入了“物理行”和“逻辑行”的概念，并在此基础上提出了基于“物理行”和“逻辑行”的索引代价计算方法。
45.一个索引的物理行的行数可以等于基线数据中包含的该索引的行数和增量数据中包含的该索引的行数之和。物理行主要用于表征lsm树这种存储引擎在计算扫描索引的代价时需要真正访问的行数。一个索引的逻辑行的行数为基线数据中包含的索引的行和增量数据中包含的该索引的行经过合并之后的剩余行的行数。逻辑行可以理解为传统意义上的行数。重新参见图2，在图2的示例中，逻辑行是0行，而物理行是20w行。
46.物理行可以用于确定扫描索引的代价。也就是说，扫描索引的代价可以基于该索引需要被扫描的物理行的行数确定。
47.在一些实施例中，索引需要被扫描的物理行的行数可以基于第一行数信息和第二行数信息确定。第一行数信息指的是与基线数据关联的行数信息；第二行数信息指的是与增量数据关联的行数信息。
48.第一行数信息可用于指示基线数据中包含的行数。例如，可以先确定索引的扫描范围，然后确定基线数据中的位于该索引的扫描范围内的行数。
49.第一行数信息的获取方式可以有多种。例如，可以通过数据库的统计信息获取。又如，可以从基线数据的元数据中获取。有些数据库（如oceanbase数据库）为基线数据维护了块级别的统计信息，因此能够很快地计算出上述第一行数信息。
50.第二行数信息可用于指示增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。例如，可以先确定索引的扫描范围，然后确定增量数据中的位于该索引的扫描范围内的新增的行数、删除的行数以及更改的行数。
51.本公开实施例同时考虑了增量数据和基线数据，相当于统计信息是实时的，而传统的统计信息搜集是有一定的滞后性的（通常是一张表的增/删/修改操作到了一定程度，才会触发统计信息的重新搜集）。
52.逻辑行可用于确定索引需要回表的代价。也就是说，索引需要回表的代价可以基于该索引需要回表的逻辑行的行数确定。索引需要回表的代价之所以可以采用逻辑行确定，是因为在扫描索引的过程中，会对基线数据和增量数据进行合并，因此直接利用基线数据和增量数据合并后的数据计算索引的回表代价即可。
53.在一些实施例中，索引需要回表的逻辑行的行数可以基于第一行数信息和第二行数信息确定。第一行数信息指的是与基线数据关联的行数信息；第二行数信息指的是与增量数据关联的行数信息。
54.第一行数信息可用于指示基线数据中包含的行数。例如，可以先确定索引的扫描范围，然后确定基线数据中的位于该索引的扫描范围内的行数。
55.第一行数信息的获取方式可以有多种。例如，可以通过数据库的统计信息获取。又如，可以从基线数据的元数据中获取。有些数据库（如oceanbase数据库）为基线数据维护了块级别的统计信息，因此能够很快地计算出上述第一行数信息。
56.第二行数信息可用于指示增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。例如，可以先确定索引的扫描范围，然后确定增量数据中的位于该索引的扫描范围内的新增的行数、删除的行数以及更改的行数。
57.参见图3，基线数据包含元数据。因此，可以利用元数据计算基线数据中的行数（对
应于上文中的第一行数信息），并利用动态采样的方式对增量数据进行动态采样，得到新增、删除、修改的行数（对应于上文中的第二行数信息）。将二者合并，则可以得到逻辑行和物理行。
58.图4示出的是本公开一个实施例提供的确定索引代价的方法。图4的方法400可以由数据库执行，例如可以由数据库中的优化器执行。该数据库可以为基于lsm树存储引擎的数据库。例如，该数据库可以为oceanbase数据库。oceanbase数据库的优势之一在于解决了索引列上的谓词依赖关系。例如，考虑索引(a,b)以及查询条件a=1 and b=1，传统数据库在计算这个查询条件的谓词选择率的时候必然要考虑的一个问题是a和b是否存在依赖关系，然后再使用对应的统计信息（多列直方图或者动态采样）来估计行数信息，从而提高谓词选择率计算的正确率。oceanbase数据库目前的估行方式已经将不同谓词条件之间的依赖关系考虑在内，因此利用oceanbase数据库默认能够解决a和b存在依赖关系的场景。数据库可以基于图4所示的方法对基表访问路径进行选择（即选择访问数据库中的表的索引）。例如，数据库可以基于图4所示的方法计算各个索引的代价，然后根据各个索引的代价，确定访问数据库中的表的索引路径。如图4所示，该方法400可以包括步骤s410、步骤s420和步骤s430，下面对这些步骤进行详细描述。
59.在步骤s410，接收第一数据库查询语句。作为一个示例，该数据库查询语句可以是sql语句。
60.在步骤s420，根据第一数据库查询语句确定索引需要被扫描的物理行的行数。例如，可以根据数据库查询语句中的谓词，确定索引的扫描范围，然后计算基线数据和增量数据中的位于该扫描范围内的行数之和，从而得到该索引需要被扫描的物理行的行数。
61.在步骤s430，根据物理行的行数确定扫描索引的代价。以该索引需要被扫描的物理行的行数为1万行为例，则可以将扫描该索引的代价确定为1万行的顺序扫描。
62.在考虑了引入了lsm树存储引擎的数据存储特点的前提下，本公开实施例引入了物理行的概念，与传统的统计信息统计出的行数不同，物理行是lsm树存储引擎在扫描索引过程中真实需要访问的行数，因此，物理行概念的引入能够提高索引路径选择的准确性。
63.图5示出的是本公开另一实施例提供的确定索引代价的方法。图5的方法500可以由数据库执行，例如可以由数据库中的优化器执行。该数据库可以为基于lsm树存储引擎的数据库。例如，该数据库可以为oceanbase数据库。数据库可以基于图5所示的方法对基表访问路径进行选择（即选择访问数据库中的表的索引）。例如，数据库可以基于图5所示的方法计算各个索引的代价，然后根据各个索引的代价，确定访问数据库中的表的索引路径。如图5所示，该方法500可以包括步骤s510、步骤s520以及步骤s530。下面对这些步骤进行详细描述。
64.在步骤s510，接收第一数据库查询语句。作为一个示例，该数据库查询语句可以是sql语句。
65.在步骤s520，根据第一数据库查询语句确定索引需要被扫描的物理行的行数以及索引需要回表的逻辑行的行数。例如，可以根据数据库查询语句中的谓词，确定索引的扫描范围，然后计算基线数据和增量数据中的位于该扫描范围内的行数，从而得到该索引需要被扫描的物理行和逻辑行的行数。
66.在步骤s530，根据物理行的行数和逻辑行的行数分别确定扫描索引的代价和索引
的回表代价。以该索引需要被扫描的物理行的行数为1万行、逻辑行为5千行为例，则可以将扫描该索引的代价确定为1万行的顺序扫描，将索引的回表代价确定为5千行的随机扫描。
67.本公开实施例通过引入逻辑行和物理行两个概念，能够提高lsm树存储引擎估行的准确性，从而提高索引路径选择的准确性。
68.上文结合图1至图5，详细描述了本公开的方法实施例，下面结合图6至图7，详细描述本公开的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
69.图6是本公开实施例提供的一种确定索引代价的装置。图6所示的装置600包括基于lsm树存储引擎的数据库，所述数据库中存储有基线数据和增量数据，所述基线数据和所述增量数据包含索引的数据，所述索引具有物理行，所述索引的物理行的行数为所述基线数据中包含的所述索引的行数和所述增量数据中包含的所述索引的行数之和。
70.所述装置600包括：接收模块610、第一确定模块620以及第二确定模块630。
71.接收模块610可用于接收第一数据库查询语句。
72.第一确定模块620可用于根据所述第一数据库查询语句确定所述索引需要被扫描的物理行的行数。
73.第二确定模块630可用于根据所述物理行的行数确定扫描所述索引的代价。
74.可选地，在一些实施例中，所述索引还具有逻辑行，所述索引的逻辑行的行数为所述基线数据中包含的所述索引的行和所述增量数据中包含的所述索引的行经过合并之后的剩余行的行数，所述装置还包括：第三确定模块，用于根据所述第一数据库查询语句确定所述索引需要回表的逻辑行的行数；第四确定模块，用于根据所述逻辑行的行数确定所述索引的回表代价。
75.可选地，在一些实施例中，所述索引需要被扫描的物理行的行数是基于第一行数信息和第二行数信息确定的，所述第一行数信息用于指示所述基线数据中包含的行数，所述第二行数信息用于指示所述增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。
76.可选地，在一些实施例中，所述索引需要回表的逻辑行的行数是基于第一行数信息和第二行数信息确定的，所述第一行数信息用于指示所述基线数据中包含的行数，所述第二行数信息用于指示所述增量数据中包含的以下行数中的一种或多种：新增的行数、删除的行数以及更改的行数。
77.可选地，在一些实施例中，所述第一行数信息是从所述基线数据的元数据中获取的。
78.可选地，在一些实施例中，所述第二行数信息是通过对所述增量数据进行动态采样获取的。
79.图7是本公开另一实施例提供的确定索引代价的装置的结构示意图。图7所述的确定索引代价的装置700可以包括存储器710和处理器720，存储器710可以用于存储指令。处理器720可以用于执行存储器710中存储的指令，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置700还可以包括网络接口730，处理器720与外部设备的数据交换可以通过该网络接口730实现。
80.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其他任意组合来实
现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，dsl））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质（例如，软盘、硬盘、磁带）、光介质（例如数字视频光盘（digital video disc，dvd））、或者半导体介质（例如固态硬盘（solid state disk，ssd））等。
81.本领域普通技术人员可以意识到，结合本公开实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。
82.在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
83.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
84.另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
85.以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。