前言

  本篇我们介绍HaloDB中min_parallel_table_scan_size参数，在大数据和复杂查询日益普遍的今天，为了应对海量数据的查询，对于一款成熟的商业化产品来说，并行查询的能力显得格外重要，
  其中，min_parallel_table_scan_size参数在优化并行查询性能方面扮演着至关重要的角色。本文将深入探讨该参数的作用、设置方法以及调整策略，帮助数据库管理员和开发人员更好地熟悉HaloDB的并行处理能力。
  号外，HaloDB 16 已经正式发布，如果对新版本感兴趣的朋友请移步 https://www.modb.pro/doc/132036 后续会推出HaloDB 16版本的解读。

广告时间：
   HaloDB 认证培训他来了！！！感兴趣的朋友可以下方扫码进群关注~~~
   如果有对我们的产品感兴趣的朋友可以通过主页的联系方式与我取得联系，获取license来安装体验，目前已经开通HaloDB吐槽群，欢迎来喷，进群请私聊我获取。
个人公众号：张某人的DBA菜谱

HaloDB产品吐槽群（欢迎各位展示语言艺术）：

一、min_parallel_table_scan_size参数的作用

  min_parallel_table_scan_size是Halo中关键的配置参数，它决定了何时启动并行顺序扫描。当表的物理大小超过此参数设置的值时，Halo的优化器会考虑对该表使用并行扫描，以加速查询处理。并行扫描能够利用多个CPU核心同时扫描表数据，从而显著提高查询性能，特别是在处理大数据量表时。

二、如何设置min_parallel_table_scan_size参数

如要设置min_parallel_table_scan_size参数，需要执行以下步骤：

1、在配置文件根据需求中添加或者修改min_parallel_table_scan_size。

[halo@halodb1 ~]$ hsql 
psql (1.0.14.10 (231130))
Type "help" for help.
halo0root=# show min_parallel_table_scan_size;
 min_parallel_table_scan_size 
------------------------------
 16MB
(1 row)

这里需要注意，参数值应使用适当的单位（如KB、MB、GB等），否则会有意想不到的惊喜出现。

2、修改参数完毕后，重启Halo使其生效。

重启命令如下：

[halo@halodb1 ~]$ pg_ctl restart 
waiting for server to shut down....2024-11-01 11:24:19.867 CST [2879] LOG:  received fast shutdown request
2024-11-01 11:24:19.879 CST [2879] LOG:  aborting any active transactions
2024-11-01 11:24:19.880 CST [2879] LOG:  background worker "logical replication launcher" (PID 2886) exited with exit code 1
2024-11-01 11:24:19.881 CST [2881] LOG:  shutting down
2024-11-01 11:24:19.896 CST [2879] LOG:  database system is shut down
 done
server stopped
waiting for server to start....2024-11-01 11:24:19.989 CST [3247] LOG:  starting 羲和(Halo) 1.0.14.10 (231130) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
2024-11-01 11:24:19.989 CST [3247] LOG:  listening on IPv4 address "0.0.0.0", port 1921
2024-11-01 11:24:19.989 CST [3247] LOG:  listening on IPv6 address "::", port 1921
2024-11-01 11:24:19.991 CST [3247] LOG:  listening on Unix socket "/var/run/halo/.s.PGSQL.1921"
2024-11-01 11:24:19.997 CST [3248] LOG:  database system was shut down at 2024-11-01 11:24:19 CST
2024-11-01 11:24:20.001 CST [3247] LOG:  database system is ready to accept connections
 done
server started

三、min_parallel_table_scan_size参数应该如何调整

  在参数调整的过程中，我们应该综合考虑多个因素，包括系统资源、查询负载、表大小分布以及与其他参数的协同作用等，否则就会出现调整参数并没有起到预期效果，以及出现反向优化的操作（这在生产环境是不可接受的），我根据自己的经验，给出了一些建议的调整策略：

1、了解当前系统资源：

  在调整参数之前，应充分了解当前系统的CPU、内存等资源情况，以及数据库的查询负载和表的大小分布。这有助于确定合理的并行查询阈值。

2、评估并行查询的效益：

  通过观察查询执行计划、系统资源使用情况以及查询响应时间等指标，评估当前并行查询的效益。如果并行查询并没有带来显著的性能提升，或者反而增加了系统开销，那么可能需要调整min_parallel_table_scan_size参数。

3、逐步调整参数值：

  可以逐步降低或增加min_parallel_table_scan_size的值，并观察其对查询性能的影响。建议每次调整时只改变一个参数，以便更容易地确定哪个参数对性能有最大影响。同时，要确保调整后的参数值不会导致系统资源过度消耗或查询性能下降。

4、考虑与其他参数的协同作用：

  在调整min_parallel_table_scan_size时，应同时考虑其他与并行查询相关的参数（如max_worker_processes、max_parallel_workers、max_parallel_workers_per_gather等）的设置。这些参数共同决定了系统能够支持的并行查询能力和资源分配策略。因此，在调整min_parallel_table_scan_size时，应确保其他相关参数也得到了合理的配置。否则就会出现参数未生效，反向优化的操作。下面是整理了一下相关的参数，给各位参考。

5、最佳实践建议：

我基于我自己的测试环境（基于4核8G内存环境）给各位朋友一个参数的配置作为参考。

• max_worker_processes：设置为8或稍高（如16），但不应超过系统的CPU核心数（4核）过多，以避免不必要的资源竞争和开销。考虑到可能存在的备库和未来的扩展性，可以设置为16。
• max_parallel_workers：根据CPU核心数和内存大小进行权衡。在4核8G的环境下，可以设置为8（与CPU核心数相当或稍高），以确保有足够的并行处理能力，同时避免内存过度消耗。
• max_parallel_workers_per_gather：可以设置为4或更低，以在并行查询和资源消耗之间取得平衡。考虑到并行查询的资源开销，设置为4可以在大多数情况下提供良好的性能表现。
• min_parallel_table_scan_size：根据表的实际情况和查询需求进行调整。在4核8G的环境下，默认值8MB通常是一个合理的起点。如果表很大且查询性能是关键，可以适当增加此值以启用更多的并行查询。但请注意，并行查询会消耗更多的资源，因此需要在性能和资源之间取得平衡。

6、持续监控和优化：

  在调整参数后，应持续监控数据库的性能和资源使用情况，并根据实际情况进行进一步的优化。这可以通过使用PostgreSQL提供的系统视图（如pgstat_activity、pg_stat_progress*等）和查询分析工具（如EXPLAIN、ANALYZE等）来完成。通过持续监控和优化，可以确保数据库始终保持在最佳性能状态。

四、当前主流数据库产品的相关功能

  在大数据处理和高并发查询场景中，数据库系统的并行查询能力成为衡量其性能的重要指标之一。MySQL和Oracle作为主流的关系型数据库管理系统，在并行查询参数设置与优化方面各有特色。将对这三个数据库系统在并行查询参数设置与优化方面进行对比分析，以帮助数据库管理员和开发人员更好地理解和应用这些功能。

1、MySQL的并行查询参数设置与优化

  MySQL在并行查询方面的支持相对有限。在MySQL的InnoDB存储引擎中，直到MySQL 8.0版本才引入了部分并行查询功能操作。
  在MySQL中，并没有min_parallel_table_scan_size这种参数来直接控制并行扫描的启动条件。相反，MySQL更多地依赖于其内部的查询优化器和执行计划来决定是否使用并行处理。此外，MySQL也提供了一些参数（如innodb_thread_concurrency）来控制并发线程的数量，但这些参数与并行查询的直接关联并不强。
  在优化方面，MySQL的并行查询优化主要依赖于其内部的查询优化器算法和索引策略。对于需要并行处理的复杂查询，MySQL用户可能需要考虑使用其他技术（如分片、分区等）来提高性能。

2、Oracle的并行查询参数设置与优化

  Oracle数据库在并行查询方面有着丰富的功能和强大的性能。Oracle提供了多个参数来控制和优化并行查询，如parallel_max_servers、parallel_min_servers、parallel_threads_per_cpu等。这些参数允许数据库管理员根据系统的硬件资源和查询负载来灵活配置并行查询的资源和性能。
示例：

-- 创建表的时候设置默认并行度
CREATE TABLE test_parallel (  
    id NUMBER,  
    name VARCHAR2(50)  
) PARALLEL (DEGREE 4);

-- 使用/*+ PARALLEL */提示来指定查询的并行度
SELECT /*+ PARALLEL(test_parallel, 4) */ COUNT(*) FROM test_parallel;

  如上所示，在Oracle中，用户可以通过在表级别或查询级别设置并行度来启用并行查询。例如，可以在创建表时指定parallel子句来设置表的默认并行度，或者在查询语句中使用/*+ PARALLEL */提示来指定查询的并行度。在优化方面，Oracle的并行查询优化器会根据系统的资源和查询的复杂度自动选择最优的并行查询策略。此外，Oracle还提供了丰富的性能监控和调优工具（如AWR、ASH、Statspack等）来帮助用户分析和优化并行查询的性能。这一点也确实值得国产数据库学习。相比AWR这种利器，国产的监控工具以及视图目前还是很粗糙的，这是个不争的事实。

最后：

最近确实更新的频率并不频繁，在这里跟大家说句抱歉，虽然是慢工，但是不是什么细活，下期见