make doc more concise

docs/zh/guides/improving-query-performance/sparse-primary-indexes.md

@@ -335,28 +335,15 @@ UserID.bin，URL.bin，和EventTime.bin是<font face = "monospace">UserID</font>
 
 第一个(根据磁盘上的物理顺序)8192行(它们的列值)在逻辑上属于颗粒0，然后下一个8192行(它们的列值)属于颗粒1，以此类推。
 
-:::note
-- 为什么上面和接下来的图片中显示的橙色数据与结论（1.最后一个颗粒我们标记的是最大的值；2.索引条目(索引标记)不是基于表中的特定行，而是基于颗粒。）不符合？
-- 因为图中的数据是禁用了自适应索引粒度后得到的（中文文档中直接引用了英文官方文档的图片内容），默认情况下索引粒度是自适应的。而基于自适应索引粒度的表中的数据就会像上述结论中一样，下文将会分析和讲解这些问题。
-
-- 下面分别是英文官方文档和版本更新网页中的描述信息，您可以开启翻译找到对应的描述。
-- https://clickhouse.com/docs/en/optimize/sparse-primary-indexes
-- 我们在本指南开头的“DDL 语句详细信息”中提到，我们禁用了自适应索引粒度（为了简化本指南中的讨论，并使图表和结果可重现）。
-- 对于具有自适应索引粒度的表（默认情况下索引粒度是自适应的），某些粒度的大小可以小于 8192 行，具体取决于行数据大小。
-
-- https://clickhouse.com/docs/en/whats-new/changelog/2019#experimental-features-1
-- ClickHouse Release 19.6.3.18, 2019-06-13
-- Experimental Features：实验性特性
-- 为合并树家族的表设置index_granularity_bytes（自适应索引粒度）。
-
-- ClickHouse Release 19.10.1.5, 2019-07-12
-- Performance Improvement：优化改进
-- 添加在合并树列末尾写入最终标记的可能性。它可以避免对超出表数据范围的键进行无用的读取。仅当使用自适应索引粒度时，才会启用它。
-:::
-
 :::note
 - 最后一个颗粒（1082颗粒）是少于8192行的。
 
+- 我们在本指南开头的“DDL 语句详细信息”中提到，我们禁用了自适应索引粒度（为了简化本指南中的讨论，并使图表和结果可重现）。
+
+  因此，示例表中所有颗粒（除了最后一个）都具有相同大小。
+
+- 对于具有自适应索引粒度的表（默认情况下索引粒度是自适应的），某些粒度的大小可以小于 8192 行，具体取决于行数据大小。
+
 - 我们将主键列(<font face = "monospace">UserID</font>, <font face = "monospace">URL</font>)中的一些列值标记为橙色。
 
   这些橙色标记的列值是每个颗粒中每个主键列的最小值。这里的例外是最后一个颗粒(上图中的颗粒1082)，最后一个颗粒我们标记的是最大的值。