[shardingsphere] branch master updated: Update pagination page Apache/ShardingSphere' document (#13269)

[wu...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

wuweijie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git


The following commit(s) were added to refs/heads/master by this push:
     new a24bc24  Update pagination page Apache/ShardingSphere' document (#13269)
a24bc24 is described below

commit a24bc244eaac525bb87ecda2a860df60c376e3df
Author: Liang Zhang <te...@163.com>
AuthorDate: Mon Oct 25 23:13:05 2021 +0800

    Update pagination page Apache/ShardingSphere' document (#13269)
---
 .../features/sharding/use-norms/pagination.cn.md   | 48 +++++++++++-----------
 .../features/sharding/use-norms/pagination.en.md   |  2 +-
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/docs/document/content/features/sharding/use-norms/pagination.cn.md b/docs/document/content/features/sharding/use-norms/pagination.cn.md
index 4e4d437..63657ae 100644
--- a/docs/document/content/features/sharding/use-norms/pagination.cn.md
+++ b/docs/document/content/features/sharding/use-norms/pagination.cn.md
@@ -3,49 +3,49 @@ title = "分页"
 weight = 2
 +++
 
-完全支持MySQL、PostgreSQL和Oracle的分页查询，SQLServer由于分页查询较为复杂，仅部分支持。
+完全支持 MySQL、PostgreSQL 和 Oracle 的分页查询，SQLServer 由于分页查询较为复杂，仅部分支持。
 
 ## 分页性能
 
 ### 性能瓶颈
 
-查询偏移量过大的分页会导致数据库获取数据性能低下，以MySQL为例：
+查询偏移量过大的分页会导致数据库获取数据性能低下，以 MySQL 为例：
 
 ```sql
 SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10
 ```
 
-这句SQL会使得MySQL在无法利用索引的情况下跳过1000000条记录后，再获取10条记录，其性能可想而知。
-而在分库分表的情况下（假设分为2个库），为了保证数据的正确性，SQL会改写为：
+这句 SQL 会使得 MySQL 在无法利用索引的情况下跳过 1,000,000 条记录后，再获取 10 条记录，其性能可想而知。
+而在分库分表的情况下（假设分为2个库），为了保证数据的正确性，SQL 会改写为：
 
 ```sql
 SELECT * FROM t_order ORDER BY id LIMIT 0, 1000010
 ```
 
-即将偏移量前的记录全部取出，并仅获取排序后的最后10条记录。这会在数据库本身就执行很慢的情况下，进一步加剧性能瓶颈。
-因为原SQL仅需要传输10条记录至客户端，而改写之后的SQL则会传输`1,000,010 * 2`的记录至客户端。
+即将偏移量前的记录全部取出，并仅获取排序后的最后 10 条记录。这会在数据库本身就执行很慢的情况下，进一步加剧性能瓶颈。
+因为原SQL仅需要传输 10 条记录至客户端，而改写之后的SQL则会传输 `1,000,010 * 2` 的记录至客户端。
 
-### ShardingSphere的优化
+### ShardingSphere 的优化
 
-ShardingSphere进行了2个方面的优化。
+ShardingSphere 进行了 2 个方面的优化。
 
-首先，采用流式处理 + 归并排序的方式来避免内存的过量占用。由于SQL改写不可避免的占用了额外的带宽，但并不会导致内存暴涨。
-与直觉不同，大多数人认为ShardingSphere会将`1,000,010 * 2`记录全部加载至内存，进而占用大量内存而导致内存溢出。
-但由于每个结果集的记录是有序的，因此ShardingSphere每次比较仅获取各个分片的当前结果集记录，驻留在内存中的记录仅为当前路由到的分片的结果集的当前游标指向而已。
-对于本身即有序的待排序对象，归并排序的时间复杂度仅为`O(nlogn)`，性能损耗很小。
+首先，采用流式处理 + 归并排序的方式来避免内存的过量占用。由于 SQL 改写不可避免的占用了额外的带宽，但并不会导致内存暴涨。
+与直觉不同，大多数人认为 ShardingSphere 会将 `1,000,010 * 2` 记录全部加载至内存，进而占用大量内存而导致内存溢出。
+但由于每个结果集的记录是有序的，因此 ShardingSphere 每次比较仅获取各个分片的当前结果集记录，驻留在内存中的记录仅为当前路由到的分片的结果集的当前游标指向而已。
+对于本身即有序的待排序对象，归并排序的时间复杂度仅为 `O(nlogn)`，性能损耗很小。
 
-其次，ShardingSphere对仅落至单分片的查询进行进一步优化。
-落至单分片查询的请求并不需要改写SQL也可以保证记录的正确性，因此在此种情况下，ShardingSphere并未进行SQL改写，从而达到节省带宽的目的。
+其次，ShardingSphere 对仅落至单分片的查询进行进一步优化。
+落至单分片查询的请求并不需要改写 SQL 也可以保证记录的正确性，因此在此种情况下，ShardingSphere 并未进行 SQL 改写，从而达到节省带宽的目的。
 
 ## 分页方案优化
 
-由于LIMIT并不能通过索引查询数据，因此如果可以保证ID的连续性，通过ID进行分页是比较好的解决方案：
+由于 LIMIT 并不能通过索引查询数据，因此如果可以保证 ID 的连续性，通过 ID 进行分页是比较好的解决方案：
 
 ```sql
 SELECT * FROM t_order WHERE id > 100000 AND id <= 100010 ORDER BY id
 ```
 
-或通过记录上次查询结果的最后一条记录的ID进行下一页的查询：
+或通过记录上次查询结果的最后一条记录的 ID 进行下一页的查询：
 
 ```sql
 SELECT * FROM t_order WHERE id > 100000 LIMIT 10
@@ -53,38 +53,38 @@ SELECT * FROM t_order WHERE id > 100000 LIMIT 10
 
 ## 分页子查询
 
-Oracle和SQLServer的分页都需要通过子查询来处理，ShardingSphere支持分页相关的子查询。
+Oracle 和 SQLServer 的分页都需要通过子查询来处理，ShardingSphere 支持分页相关的子查询。
 
 - Oracle
 
-支持使用rownum进行分页：
+支持使用 rownum 进行分页：
 
 ```sql
 SELECT * FROM (SELECT row_.*, rownum rownum_ FROM (SELECT o.order_id as order_id FROM t_order o JOIN t_order_item i ON o.order_id = i.order_id) row_ WHERE rownum <= ?) WHERE rownum > ?
 ```
 
-目前不支持rownum + BETWEEN的分页方式。
+目前不支持 rownum + BETWEEN 的分页方式。
 
 - SQLServer
 
-支持使用TOP + ROW_NUMBER() OVER配合进行分页：
+支持使用 TOP + ROW_NUMBER() OVER 配合进行分页：
 
 ```sql
 SELECT * FROM (SELECT TOP (?) ROW_NUMBER() OVER (ORDER BY o.order_id DESC) AS rownum, * FROM t_order o) AS temp WHERE temp.rownum > ? ORDER BY temp.order_id
 ```
 
-支持SQLServer 2012之后的OFFSET FETCH的分页方式：
+支持 SQLServer 2012 之后的 OFFSET FETCH 的分页方式：
 
 ```sql
 SELECT * FROM t_order o ORDER BY id OFFSET ? ROW FETCH NEXT ? ROWS ONLY
 ```
 
-目前不支持使用WITH xxx AS (SELECT ...)的方式进行分页。由于Hibernate自动生成的SQLServer分页语句使用了WITH语句，因此目前并不支持基于Hibernate的SQLServer分页。
-目前也不支持使用两个TOP + 子查询的方式实现分页。
+目前不支持使用 WITH xxx AS (SELECT ...) 的方式进行分页。由于 Hibernate 自动生成的 SQLServer 分页语句使用了 WITH 语句，因此目前并不支持基于 Hibernate 的 SQLServer 分页。
+目前也不支持使用两个 TOP + 子查询的方式实现分页。
 
 - MySQL, PostgreSQL
 
-MySQL和PostgreSQL都支持LIMIT分页，无需子查询：
+MySQL 和 PostgreSQL 都支持 LIMIT 分页，无需子查询：
 
 ```sql
 SELECT * FROM t_order o ORDER BY id LIMIT ? OFFSET ?
diff --git a/docs/document/content/features/sharding/use-norms/pagination.en.md b/docs/document/content/features/sharding/use-norms/pagination.en.md
index 800d0b7..948303d 100644
--- a/docs/document/content/features/sharding/use-norms/pagination.en.md
+++ b/docs/document/content/features/sharding/use-norms/pagination.en.md
@@ -21,7 +21,7 @@ This SQL will make MySQL acquire another 10 records after skipping 1,000,000 rec
 SELECT * FROM t_order ORDER BY id LIMIT 0, 1000010
 ```
 
-It also means taking out all the records prior to the offset and only acquire the last 10 records after ordering. It will further aggravate the performance bottleneck effect when the database is already slow in execution. The reason for that is the former SQL only needs to transmit 10 records to the user end, but now it will transmit `1000010 * 2` records after the rewrite.
+It also means taking out all the records prior to the offset and only acquire the last 10 records after ordering. It will further aggravate the performance bottleneck effect when the database is already slow in execution. The reason for that is the former SQL only needs to transmit 10 records to the user end, but now it will transmit `1,000,010 * 2` records after the rewrite.
 
 ### Optimization of ShardingSphere