数据库CPU使用机制全面解析：从查询执行到并发控制

数据库CPU使用机制全面解析：从查询执行到并发控制

一、引言：CPU在数据库系统中的核心地位

在当今数据驱动的时代，数据库系统作为数据存储和处理的核心组件，其性能直接影响着整个应用系统的响应速度和吞吐量。而CPU作为数据库系统的"大脑"，其资源利用效率对数据库性能起着决定性作用。数据库系统的CPU使用机制涉及多个层面，包括查询执行、锁管理、并发控制、存储引擎优化等，这些机制相互协作，共同决定了数据库系统的处理能力。

随着硬件技术的发展，现代服务器CPU已从单核发展到多核、多线程架构，如何充分利用这些计算资源成为数据库性能优化的关键。同时，不同类型的数据库（如关系型、NoSQL、时序数据库）在CPU使用策略上也存在显著差异，这直接影响了它们在不同应用场景（如OLTP、OLAP、混合负载）下的性能表现。

本文将全面剖析数据库系统的CPU使用机制，涵盖关系型数据库、NoSQL数据库和时序数据库等多种类型，深入探讨查询执行、锁管理、并发控制等CPU相关操作的工作原理，并提供实际配置与调优建议，帮助读者理解数据库如何高效利用CPU资源，以及如何针对不同应用场景进行优化。

二、数据库CPU使用基础机制

2.1 CPU架构与数据库性能的关系

现代CPU架构对数据库性能有着深远影响，理解这些架构特点有助于优化数据库系统的CPU使用效率。

CPU核心与线程：现代服务器CPU通常具有多个物理核心，每个核心又可以支持多个线程（如超线程技术）。例如，第四代英特尔®至强®可扩展处理器通过灵活部署实现性能核与能效核的动态协同，基于共享x86指令集与统一硬件平台，兼容多样化业务需求[]。数据库系统需要充分利用这些核心和线程，实现并行处理，提高吞吐量。

缓存层次结构：CPU包含多级缓存（L1、L2、L3），越接近CPU核心的缓存速度越快，但容量越小。数据库系统需要优化数据访问模式，提高缓存命中率，减少内存访问延迟。例如，列存储数据库通过按列存储数据，提高了缓存利用率，从而提升了CPU效率[]。

指令集扩展：现代CPU支持多种指令集扩展，如SIMD（单指令多数据），可以同时对多个数据元素执行相同操作，提高处理效率。向量化执行技术正是利用这一特性，将数据库操作向量化，大幅提升处理速度[]。例如，SQL Server 2025的查询处理器引入了改进的锁管理策略与批处理加速技术，协同提升事务处理能力[]。

CPU亲和性：数据库进程或线程可以绑定到特定的CPU核心，避免在不同核心间迁移带来的上下文切换开销。合理设置CPU亲和性，可以提高CPU缓存利用率和系统稳定性。

2.2 数据库进程与线程模型

数据库系统的进程与线程模型直接影响CPU资源的分配和利用效率。

单进程多线程模型：许多数据库系统（如MySQL）采用单进程多线程模型，主进程负责管理多个工作线程。这种模型减少了进程间通信的开销，但需要处理线程间的同步和资源竞争问题。例如，InnoDB存储引擎的线程并发控制通过innodb_thread_concurrency参数配置，该参数设置了允许同时进入InnoDB的最大线程数[]。

多进程模型：一些数据库系统（如早期版本的Oracle）采用多进程模型，每个数据库操作由独立的进程处理。这种模型提供了更好的隔离性，但增加了进程创建和销毁的开销，以及进程间通信的复杂性。

混合模型：现代数据库系统通常采用混合模型，结合了多进程和多线程的优点。例如，PostgreSQL使用多进程模型，但每个进程内部可以创建多个线程来处理并发请求[]。

无共享架构：分布式数据库系统（如OceanBase、GBase 8c）通常采用无共享架构，每个节点都是独立的数据库实例，通过网络进行通信。这种架构可以水平扩展，充分利用多个服务器的CPU资源，但需要处理分布式事务和数据一致性问题[]。

2.3 数据库CPU使用的关键指标

监控数据库的CPU使用情况需要关注以下关键指标：

CPU利用率：表示CPU处理任务的时间占总时间的百分比。持续高CPU利用率（如超过80%）可能表明系统负载过重或存在性能瓶颈。例如，在MySQL中，慢查询是导致CPU利用率升高的常见原因之一[]。

上下文切换次数：表示CPU在不同线程或进程之间切换的频率。过高的上下文切换会增加系统开销，降低性能。数据库系统通过优化锁管理和线程调度，可以减少不必要的上下文切换[]。

用户CPU时间与系统CPU时间：用户CPU时间表示CPU执行用户代码（如SQL查询）的时间，系统CPU时间表示CPU执行内核代码（如内存管理、I/O操作）的时间。两者的比例可以帮助判断性能问题的性质。

等待事件：数据库系统中的CPU等待事件（如锁等待、I/O等待）表示CPU处于空闲状态但无法执行任务的情况。高等待事件率可能表明存在资源竞争或I/O瓶颈[]。

线程状态：监控数据库进程或线程的状态（如运行、阻塞、睡眠）可以帮助识别性能问题。例如，在PostgreSQL中，执行时间长、运行状态为"Sending data"、"Sorting result"的线程可能存在性能问题[]。

通过监控这些指标，数据库管理员可以识别CPU使用的瓶颈，并采取相应的优化措施。例如，对于高CPU利用率的情况，可以通过优化查询语句、调整索引策略或增加CPU资源来改善性能[]。

三、查询执行过程中的CPU使用分析

3.1 查询解析与优化阶段的CPU消耗

查询执行过程的第一个阶段是查询解析与优化，这一阶段虽然通常只占总执行时间的一小部分，但对后续执行效率有着决定性影响。

查询解析：数据库首先将用户输入的SQL或其他查询语言转换为内部可识别的抽象语法树（AST）。这一过程包括词法分析、语法分析和语义检查，需要CPU处理大量的字符串操作和语法规则匹配。例如，增强型正则表达式在数据清洗工作流中可以提高效率，但也可能增加CPU负担[]。

查询优化：数据库优化器根据统计信息和成本模型，生成多种可能的执行计划，并选择成本最低的执行计划。这一过程可能涉及复杂的数学计算和逻辑判断，消耗大量CPU资源。例如，PostgreSQL使用基于成本的优化器（CBO），它利用数据统计信息而非静态规则来估计不同执行计划的成本。

执行计划生成：优化器生成的执行计划包含一系列操作符（如扫描、过滤、连接、聚合等），这些操作符的组合和顺序直接影响执行效率。现代数据库系统（如StarRocks）采用CBO优化器和向量化执行器，以提高复杂查询的执行效率[]。

优化查询解析与优化阶段的CPU使用，可以从以下几个方面入手：

1. 定期更新统计信息：确保优化器能够基于最新的数据分布生成高质量的执行计划。例如，PostgreSQL的ANALYZE命令可以更新表的统计信息。

2. 避免复杂的表达式：在查询条件和排序表达式中避免使用复杂的函数和表达式，这些会增加解析和优化的CPU负担。

3. 使用绑定变量：在重复执行的查询中使用绑定变量，避免重复解析和优化过程。例如，在Oracle中，使用绑定变量可以重用执行计划，减少硬解析的次数[]。

4. 优化器提示：在必要时使用优化器提示，引导优化器生成更高效的执行计划，但应谨慎使用，以免影响计划的适应性。

3.2 查询执行阶段的CPU消耗

查询执行阶段是CPU消耗的主要阶段，这一阶段根据优化器生成的执行计划，实际处理数据并返回结果。

数据访问方法：数据库可以通过不同的方法访问数据，包括全表扫描、索引扫描、索引范围扫描等。不同的访问方法对CPU的消耗不同。例如，全表扫描需要读取表中的所有数据块，CPU主要用于数据传输和过滤；而索引扫描则需要CPU处理索引结构，找到符合条件的数据行[]。

连接操作：连接操作是数据库查询中最消耗CPU资源的操作之一。常见的连接算法包括嵌套循环连接、哈希连接和合并连接，每种算法的CPU消耗特性不同。例如，哈希连接在处理大表连接时通常比嵌套循环连接更高效，但需要更多的内存和CPU资源来构建和探测哈希表[]。

排序和聚合操作：排序和聚合操作（如GROUP BY、ORDER BY、DISTINCT）需要CPU对数据进行重新排列和计算。这些操作的CPU消耗与数据量和数据分布密切相关。例如，在PostgreSQL中，排序操作使用的内存由work_mem参数控制，增加该参数可以减少磁盘临时文件的使用，提高排序性能[]。

向量化执行：现代数据库系统（如StarRocks、QuestDB）采用向量化执行技术，将数据分批次处理，利用CPU的SIMD指令集同时对多个数据元素执行相同操作，大幅提高执行效率。例如，QuestDB的向量化执行技术通过批量处理数据块，提高了CPU缓存效率[]。

优化查询执行阶段的CPU使用，可以考虑以下策略：

1. 优化索引设计：创建合适的索引可以减少数据访问和排序的CPU消耗。例如，在MongoDB中，确保查询语句有适当的索引支持，可以避免集合扫描，减少CPU密集型操作[]。

2. 选择合适的连接方法：根据数据量和分布特点，选择最适合的连接方法。例如，对于小结果集的连接，嵌套循环连接可能更高效；而对于大表连接，哈希连接或合并连接可能更优[]。

3. 限制返回结果集的大小：只返回必要的列和行，可以减少CPU处理的数据量。例如，在MongoDB中，投影操作（只返回必要的字段）可以减少服务器的工作量[]。

4. 使用并行查询：对于大型分析查询，启用并行查询可以利用多个CPU核心同时处理任务，减少执行时间。例如，PostgreSQL支持并行查询执行，通过max_parallel_workers_per_gather参数控制每个查询使用的最大工作进程数[]。

3.3 存储引擎层的CPU优化技术

存储引擎是数据库系统中直接与物理数据交互的组件，其CPU优化技术对整体性能至关重要。

行存储与列存储：行存储将数据按行连续存储，适合OLTP场景下的单行访问；列存储将数据按列存储，适合OLAP场景下的批量数据处理。列存储通常具有更高的压缩比和更高效的聚合性能，减少CPU在数据读取和处理上的消耗[]。例如，GBase 8c多模多态分布式数据库支持行存储、列存储、内存存储等多种引擎，可根据不同应用场景选择合适的存储模式[]。

向量化处理：存储引擎可以将数据组织成向量形式，利用CPU的SIMD指令进行批量处理。例如，StarRocks的向量化执行器通过向量化处理技术，大幅提高了复杂查询的执行效率[]。

自适应执行：现代存储引擎（如SQL Server 2025）引入了自适应执行计划技术，允许执行计划在执行过程中根据实际数据分布动态调整，提高执行效率。例如，SQL Server 2025的查询处理器引入了可选参数处理机制，改进的锁管理策略与批处理加速技术协同提升事务处理能力[]。

数据压缩：存储引擎可以对数据进行压缩，减少存储空间和I/O操作，从而间接减少CPU消耗。不同的数据类型适用不同的压缩算法，例如，数值型数据适合使用行程长度编码（RLE），文本数据适合使用字典编码或LZ4压缩算法。例如，在时序数据库中，TDengine的差值编码和通用压缩技术在处理平稳变化的时序数据时表现出了极高的压缩率，为用户节约了大量的存储成本[]。

优化存储引擎层的CPU使用，可以从以下几个方面入手：

1. 选择合适的存储引擎：根据应用场景选择最适合的存储引擎。例如，InnoDB适合OLTP场景，而ColumnStore适合OLAP场景[]。

2. 调整存储引擎参数：根据硬件配置和工作负载调整存储引擎的参数。例如，InnoDB的innodb_read_io_threads参数控制读取数据的线程数，增加该值可以提高读密集型操作的性能[]。

3. 使用内存表：对于热数据或临时数据，可以考虑使用内存表，减少磁盘I/O，提高访问速度。例如，Redis作为内存数据库，所有操作都在内存中完成，提供了极高的读写性能[]。

4. 利用硬件加速：一些存储引擎（如SQL Server）可以利用特定的硬件特性（如Intel® Advanced Matrix Extensions）加速数据处理，减少CPU消耗[]。

四、锁管理与并发控制中的CPU使用分析

4.1 锁机制及其CPU开销

锁机制是数据库系统实现并发控制的基本手段之一，不同类型的锁在CPU开销上存在显著差异。

锁类型：数据库系统通常支持多种类型的锁，包括共享锁（S锁）、排他锁（X锁）、意向锁等。不同类型的锁之间存在兼容性关系，决定了并发事务能否同时持有这些锁。例如，共享锁之间是兼容的，而共享锁和排他锁之间是互斥的[]。

锁粒度：锁可以应用在不同的粒度上，包括行级锁、页级锁和表级锁。锁粒度越细，并发度越高，但锁管理的CPU开销也越大。例如，InnoDB存储引擎默认使用行级锁，提供了较高的并发度，但需要更多的CPU资源来管理锁结构[]。

锁竞争与上下文切换：当多个事务竞争同一资源的锁时，会产生锁竞争。未获得锁的事务可能进入等待状态，导致线程上下文切换，增加CPU开销。例如，在MySQL中，innodb_thread_concurrency参数可以控制同时进入InnoDB的线程数，减少锁竞争和上下文切换[]。

锁升级：当一个事务持有大量细粒度锁时，数据库系统可能会将这些锁升级为更粗粒度的锁，以减少锁管理的开销。但锁升级可能导致并发度下降，需要在锁管理开销和并发度之间取得平衡[]。

优化锁机制的CPU使用，可以考虑以下策略：

1. 优化事务设计：保持事务简短，减少锁持有时间。例如，在OLTP系统中，应避免在事务中包含用户交互或长时间运行的操作[]。

2. 合理设置锁超时：设置适当的锁等待超时时间，避免事务长时间等待锁而占用CPU资源。例如，在PostgreSQL中，可以通过lock_timeout参数设置锁等待的超时时间[]。

3. 调整锁管理参数：根据系统负载和硬件配置调整锁管理相关参数。例如，在Oracle中，可以通过_row_locking参数调整行锁的行为[]。

4. 使用乐观锁：在冲突较少的场景中，可以考虑使用乐观锁机制，减少锁竞争和上下文切换的开销。例如，MongoDB的文档级原子操作就实现了乐观锁的效果。

4.2 MVCC机制及其CPU开销

多版本并发控制（MVCC）是现代数据库系统广泛采用的一种并发控制机制，它通过维护数据的多个版本来实现读操作和写操作的并发执行。

MVCC原理：MVCC在写操作时创建数据的新版本，而不是直接修改旧版本。读操作根据事务的启动时间或快照，访问适当的数据版本。这种机制允许读操作和写操作互不阻塞，提高了并发性能[]。

版本管理：MVCC需要管理数据的多个版本，包括版本的创建、访问和清理。例如，PostgreSQL在数据行中存储xmin（创建该版本的事务ID）和xmax（删除或更新该版本的事务ID），用于判断数据版本的可见性[]。

可见性判断：MVCC的核心是可见性判断，即确定哪些数据版本对当前事务可见。这一过程需要CPU处理事务ID或时间戳的比较和逻辑判断。例如，在Oracle中，一致性读机制根据查询的启动时间（SCN）构建一个一致性视图，判断数据版本的可见性[]。

版本清理：MVCC会产生大量的旧版本数据，需要定期清理以释放空间。版本清理过程（如PostgreSQL的VACUUM操作）需要CPU资源，但可以提高系统的长期性能[]。

MVCC与传统锁机制相比，在CPU使用上具有以下优势：

1. 减少锁竞争：MVCC消除了读操作和写操作之间的锁竞争，减少了锁管理的CPU开销和上下文切换[]。

2. 降低死锁可能性：由于MVCC减少了锁的使用，特别是长时间持有的锁，降低了死锁的可能性，减少了死锁检测的CPU开销。

3. 提高吞吐量：MVCC允许读操作和写操作并发执行，提高了系统的吞吐量，特别是在读多写少的场景中[]。

然而，MVCC也有一定的CPU开销，主要体现在版本管理和可见性判断上。不同数据库的MVCC实现对CPU的影响也有所不同。例如，在MySQL的InnoDB存储引擎中，MVCC的实现相对高效，而MyRocks存储引擎的锁表CPU开销约为InnoDB的2倍[]。

4.3 乐观并发控制及其CPU开销

乐观并发控制（OCC）是另一种并发控制机制，它假设冲突很少发生，仅在事务提交时检查冲突。

乐观锁原理：OCC在事务执行过程中不获取锁，而是在提交时检查数据是否被其他事务修改。如果发现冲突，则回滚当前事务并重新执行[]。

冲突检测：OCC的冲突检测可以基于数据版本号、时间戳或数据值的变化。例如，MongoDB的文档级更新操作可以指定条件，仅在文档满足特定条件时才执行更新，实现乐观锁的效果[]。

重试机制：当冲突发生时，OCC需要回滚事务并重新执行。这一过程可能需要多次重试，增加CPU开销，特别是在冲突率较高的场景中[]。

适用场景：OCC在冲突率低、读多写少的场景中表现良好，可以减少锁管理的CPU开销。但在冲突率高的场景中，频繁的回滚和重试会导致性能下降[]。

OCC与MVCC和传统锁机制在CPU使用上的比较：

1. 锁机制：传统锁机制在冲突率高的场景中表现较好，但需要较多的CPU资源来管理锁和处理上下文切换。

2. MVCC：MVCC在大多数场景中表现均衡，通过版本管理减少锁竞争，但需要额外的CPU资源来管理版本和进行可见性判断。

3. OCC：OCC在冲突率低的场景中CPU开销最小，但在冲突率高的场景中可能导致大量的回滚和重试，增加CPU消耗[]。

在实际应用中，可以根据工作负载特点选择合适的并发控制机制。例如，对于冲突率低的OLTP系统，可以考虑使用OCC或MVCC；对于冲突率高的系统，传统锁机制可能更合适。

五、不同类型数据库的CPU使用特点

5.1 关系型数据库CPU使用特点

关系型数据库（如MySQL、PostgreSQL、Oracle）在CPU使用上具有以下特点：

查询执行引擎：关系型数据库通常使用基于成本的优化器（CBO）生成执行计划，并通过多种执行算法（如嵌套循环连接、哈希连接、合并连接）处理数据。这些过程需要大量的CPU资源，特别是在处理复杂查询时。

锁管理机制：关系型数据库广泛使用锁机制实现并发控制，不同数据库的锁管理策略对CPU使用有显著影响。例如，InnoDB的行锁管理相对高效，而MyRocks的锁表CPU开销约为InnoDB的2倍[]。

MVCC实现：大多数关系型数据库（如PostgreSQL、Oracle、MySQL的InnoDB存储引擎）采用MVCC机制实现高并发。MVCC通过版本管理减少锁竞争，但需要额外的CPU资源进行可见性判断和版本清理[]。

并行处理能力：现代关系型数据库（如PostgreSQL 17、SQL Server 2025）支持并行查询执行，可以利用多个CPU核心同时处理大型查询。例如，PostgreSQL的max_parallel_workers_per_gather参数控制每个查询使用的最大工作进程数[]。

存储引擎差异：不同存储引擎在CPU使用上存在显著差异。例如，InnoDB适合OLTP场景，通过缓冲池和自适应哈希索引优化CPU使用；而ColumnStore适合OLAP场景，通过列存储和向量化执行提高CPU效率[]。

针对关系型数据库的CPU优化策略：

1. 优化查询执行计划：通过分析执行计划，找出效率低下的操作并优化。例如，在PostgreSQL中，可以使用EXPLAIN ANALYZE命令分析查询执行计划。

2. 调整并行查询参数：根据CPU核心数和工作负载调整并行查询参数。例如，在PostgreSQL中，max_parallel_workers_per_gather通常设置为CPU核心数的1/2到2/3[]。

3. 优化锁管理：根据系统负载调整锁管理参数。例如，在MySQL中，innodb_thread_concurrency参数可以控制同时进入InnoDB的线程数，减少锁竞争和上下文切换[]。

4. 使用合适的存储引擎：根据应用场景选择合适的存储引擎。例如，对于OLTP系统，选择InnoDB；对于OLAP系统，选择ColumnStore或其他列存储引擎[]。

5.2 NoSQL数据库CPU使用特点

NoSQL数据库（如Redis、MongoDB、Cassandra）在CPU使用上具有以下特点：

内存数据库特性：许多NoSQL数据库（如Redis）是内存数据库，所有操作都在内存中完成，减少了磁盘I/O，但需要高效的CPU处理能力。例如，Redis的单线程设计简化了编程模型，但需要CPU快速处理命令请求[]。

线程模型：NoSQL数据库的线程模型各不相同。Redis采用单线程模型处理命令请求，但支持多线程I/O处理；MongoDB使用多线程模型，可以利用多个CPU核心[]。

查询处理：NoSQL数据库的查询语言通常比SQL简单，查询优化和执行的CPU开销相对较小。例如，Redis的命令处理逻辑相对简单，主要消耗CPU在内存操作和网络通信上[]。

数据模型：NoSQL数据库的文档型（如MongoDB）、键值型（如Redis）、列族型（如Cassandra）等不同数据模型对CPU使用有不同影响。例如，文档型数据库需要CPU处理文档的序列化和反序列化，而键值型数据库主要处理键的哈希计算和比较[]。

索引机制：NoSQL数据库的索引机制对CPU使用有重要影响。例如，MongoDB的索引构建和维护需要CPU资源，但可以大幅提高查询性能。

针对NoSQL数据库的CPU优化策略：

1. 优化数据结构：选择合适的数据结构可以减少CPU处理时间。例如，在Redis中，有序集合（Sorted Set）比列表（List）更适合范围查询[]。

2. 使用批量操作：利用批量操作减少网络往返次数和协议解析的CPU开销。例如，Redis的MSET和MGET命令可以批量处理多个键值对[]。

3. 优化索引设计：根据查询模式设计合适的索引。例如，在MongoDB中，确保查询条件和排序字段有适当的索引支持，可以避免全表扫描和排序操作[]。

4. 调整线程配置：根据CPU核心数和工作负载调整线程配置。例如，Redis 8引入了多线程I/O处理，可以通过io-threads参数配置I/O线程数，提高处理能力[]。

5. 避免大键操作：大键（Big Keys）会增加CPU在序列化、反序列化和网络传输上的开销。例如，在Redis中，应避免存储过大的字符串或哈希键[]。

5.3 时序数据库CPU使用特点

时序数据库（如InfluxDB、TDengine、TimescaleDB）在CPU使用上具有以下特点：

时间序列数据模型：时序数据库专门优化了时间序列数据的存储和查询，通常采用时间分区和压缩技术，减少CPU在数据处理上的消耗。例如，TDengine的差值编码和通用压缩技术在处理平稳变化的时序数据时表现出了极高的压缩率[]。

索引结构：时序数据库通常使用特殊的索引结构，如InfluxDB的TSI（Time Series Index），将索引存储在磁盘上的文件中，并通过内存映射的方式访问。这种设计允许索引大小不受内存限制，但需要CPU处理索引的查找和过滤[]。

查询模式：时序数据库的查询通常基于时间范围和标签过滤，适合向量化处理和批量操作。例如，InfluxDB的Flux查询语言支持高效的时间序列聚合和过滤操作[]。

数据压缩：时序数据库使用高效的压缩算法减少存储空间和I/O操作，从而间接减少CPU消耗。例如，清华团队提出的时序聚类数据库内高效方案利用LSM-Tree的分层文件结构，通过多版本合并机制直接在数据库内对无序数据按时间范围排序，避免全量数据加载和外部排序开销[]。

并行处理：现代时序数据库（如TimescaleDB）支持并行查询执行，可以利用多个CPU核心同时处理大型查询。例如，TimescaleDB作为PostgreSQL的扩展，继承了PostgreSQL的并行查询能力[]。

针对时序数据库的CPU优化策略：

1. 优化查询语句：设计高效的查询语句，避免不必要的数据加载和处理。例如，在InfluxDB中，避免使用pivot操作，因为它在处理大量数据时会显著降低性能[]。

2. 利用时序特性：充分利用时间序列数据的特性，如时间分区和降采样，减少需要处理的数据量。例如，在时序预测中，可以降采样及自动插值的方式获取训练数据，减少CPU处理量[]。

3. 调整并行参数：根据CPU核心数和工作负载调整并行查询参数。例如，在TimescaleDB中，可以通过max_parallel_workers_per_gather参数控制每个查询使用的最大工作进程数[]。

4. 优化数据写入：设计高效的数据写入策略，减少写入时的CPU开销。例如，在InfluxDB中，使用批量写入和Line Protocol格式可以提高写入性能。

5. 使用时序特定函数：利用时序数据库提供的特定函数（如窗口函数、异常检测函数）处理数据，这些函数通常经过优化，比通用函数更高效[]。

六、不同应用场景下的CPU优化策略

6.1 OLTP场景下的CPU优化策略

联机事务处理（OLTP）场景的特点是高并发、短事务、随机读写，针对OLTP场景的CPU优化策略如下：

优化事务设计：保持事务简短，减少锁持有时间和CPU处理时间。例如，将大事务拆分为多个小事务，避免在事务中包含复杂的计算或用户交互[]。

调整锁管理参数：根据系统负载调整锁管理参数，减少锁竞争和上下文切换。例如，在MySQL中，innodb_thread_concurrency参数设置为CPU核心数的1-2倍，可以减少锁竞争和上下文切换[]。

优化索引设计：为高频访问的列创建索引，但避免过度索引。例如，在OLTP系统中，B树索引通常比哈希索引更适合范围查询[]。

使用绑定变量：在重复执行的查询中使用绑定变量，避免重复解析和优化过程。例如，在Oracle中，使用绑定变量可以重用执行计划，减少硬解析的CPU开销[]。

调整线程池大小：根据CPU核心数和工作负载调整线程池大小。例如，在SQL Server中，max worker threads参数通常设置为CPU核心数的2-4倍[]。

避免复杂查询：OLTP系统应避免执行复杂的JOIN和聚合操作，这些操作会消耗大量CPU资源。例如，可以将复杂查询分解为多个简单查询，或在业务层处理部分逻辑[]。

6.2 OLAP场景下的CPU优化策略

联机分析处理（OLAP）场景的特点是低并发、长查询、批量读写，针对OLAP场景的CPU优化策略如下：

使用列存储：列存储在OLAP场景中表现优异，因为它可以提高缓存利用率和压缩比，减少CPU在数据读取和处理上的消耗。例如，GBase 8c的列存引擎和向量引擎专为OLAP场景设计[]。

向量化执行：利用向量化执行技术，将数据组织成向量形式，利用CPU的SIMD指令进行批量处理。例如，StarRocks的向量化执行器通过向量化处理技术，大幅提高了复杂查询的执行效率[]。

并行查询执行：启用并配置并行处理功能，利用多个CPU核心处理大型分析查询。例如，PostgreSQL的max_parallel_workers_per_gather参数控制每个查询使用的最大工作进程数[]。

优化聚合操作：使用高效的聚合算法和数据结构。例如，在OLAP系统中，哈希聚合通常比排序聚合更高效[]。

批量数据加载：使用批量加载工具（如PostgreSQL的COPY命令）加载大量数据，减少单条插入的CPU开销[]。

使用物化视图：对于频繁执行的复杂查询，可以考虑使用物化视图预计算结果，减少实时计算的CPU消耗。例如，在Oracle中，物化视图可以定期刷新，提供接近实时的查询性能[]。

6.3 混合负载场景下的CPU优化策略

混合负载场景同时包含OLTP和OLAP工作负载，需要平衡两种工作负载的CPU需求，优化策略如下：

资源隔离：使用资源管理工具（如PostgreSQL的资源队列、SQL Server的Resource Governor）为不同类型的工作负载分配不同的CPU资源。例如，可以为OLTP事务分配更高的优先级和更多的CPU资源[]。

分时处理：根据业务高峰和低谷时段，调整资源分配。例如，在业务高峰期优先处理OLTP事务，在低谷期处理OLAP查询[]。

混合存储架构：使用混合存储架构，将频繁更新的热数据存储在适合OLTP的存储引擎中，将静态的冷数据存储在适合OLAP的存储引擎中。例如，可以使用关系型数据库处理OLTP工作负载，使用列存储处理OLAP工作负载[]。

调整并行度：根据工作负载动态调整并行查询的并行度。例如，可以在OLTP负载较高时降低并行查询的并行度，避免过多的CPU资源被分析查询占用[]。

优化索引策略：设计兼顾OLTP和OLAP需求的索引。例如，可以为频繁查询的列创建B树索引，为分析查询的列创建位图索引[]。

使用查询提示：在必要时使用查询提示，引导优化器生成更适合当前工作负载的执行计划。例如，可以在OLAP查询中使用NOLOCK提示，减少锁竞争[]。

七、数据库CPU性能监控与调优实践

7.1 CPU性能监控工具与方法

有效的CPU性能监控是数据库调优的基础，以下是常用的监控工具与方法：

数据库内置监控工具：

• MySQL：使用SHOW ENGINE INNODB STATUS查看InnoDB引擎状态，SHOW FULL PROCESSLIST查看当前执行的查询[]。
• PostgreSQL：使用pg_stat_activity查看活动进程，pg_stat_statements查看查询统计信息[]。
• Oracle：使用V$SESSION、V$SQL、V$SQLAREA等动态性能视图监控查询执行[]。

操作系统监控工具：

• Linux：使用top、htop、vmstat、pidstat等命令监控系统和进程的CPU使用情况[]。
• Windows：使用任务管理器或性能监视器监控CPU使用情况[]。

专用监控工具：

• Percona Monitoring and Management (PMM)：专为MySQL和PostgreSQL设计的监控工具，提供详细的性能指标和诊断信息[]。
• Datadog：云原生监控平台，支持多种数据库的性能监控[]。
• Prometheus/Grafana：开源监控系统，可以监控多种数据库的CPU使用情况并创建自定义仪表盘[]。

慢查询日志：启用并分析慢查询日志，找出执行时间长、消耗CPU多的查询。例如，MySQL的慢查询日志记录执行时间超过阈值的查询[]。

性能分析工具：

• pt-query-digest（Percona Toolkit）：分析MySQL慢查询日志，生成统计报告[]。
• pg_profile（PostgreSQL）：分析PostgreSQL查询性能，找出热点函数和低效操作。
• 火焰图：可视化CPU使用情况，帮助识别性能瓶颈。例如，通过火焰图可以发现MyRocks的锁表CPU开销约为InnoDB的2倍[]。

7.2 CPU性能瓶颈分析方法

分析CPU性能瓶颈需要综合考虑多种因素，以下是常用的分析方法：

CPU使用率分析：检查系统整体和数据库进程的CPU使用率。持续高CPU使用率可能表明存在性能瓶颈。例如，在MySQL中，慢查询是导致CPU使用率升高的常见原因[]。

查询执行计划分析：分析执行计划，找出效率低下的操作（如全表扫描、低效连接）。例如，使用PostgreSQL的EXPLAIN ANALYZE命令分析查询执行计划。

等待事件分析：分析数据库和操作系统的等待事件，确定CPU空闲但无法执行任务的原因。例如，高锁等待可能表明存在锁竞争问题[]。

热点函数分析：使用性能分析工具（如火焰图）找出消耗CPU最多的函数和代码路径。例如，通过火焰图可以发现锁表操作消耗了大量CPU时间[]。

线程状态分析：检查数据库线程的状态，确定是否存在大量阻塞或等待的线程。例如，在MySQL中，执行状态为"Sending data"、"Sorting result"的线程可能存在性能问题[]。

比较分析：比较不同时间段的CPU使用模式，识别工作负载变化对CPU的影响。例如，可以比较工作日和周末的CPU使用情况，找出周期性的性能问题[]。

7.3 CPU性能调优最佳实践

基于CPU性能分析结果，可以采取以下调优措施：

查询优化：

• 优化低效查询：通过分析执行计划，优化低效查询。例如，为缺少索引的查询添加适当的索引[]。
• 简化查询逻辑：避免复杂的表达式和子查询，将部分逻辑移至应用层处理[]。
• 限制结果集大小：只返回必要的列和行，减少数据传输和处理的CPU开销[]。

索引优化：

• 创建适当的索引：根据查询模式创建适当的索引，但避免过度索引。例如，在MongoDB中，确保查询条件有适当的索引支持[]。
• 定期重建索引：定期重建碎片化的索引，提高查询性能。例如，在Oracle中，可以使用ALTER INDEX ... REBUILD命令重建索引[]。
• 使用覆盖索引：设计覆盖索引，避免回表查询，减少I/O和CPU开销[]。

参数调整：

• 调整并行查询参数：根据CPU核心数调整并行查询参数。例如，在PostgreSQL中，max_parallel_workers_per_gather通常设置为CPU核心数的1/2到2/3[]。
• 调整线程池大小：根据工作负载调整线程池大小。例如，在MySQL中，innodb_thread_concurrency参数通常设置为CPU核心数的1-2倍[]。
• 调整内存参数：根据内存大小调整缓存和排序参数。例如，在PostgreSQL中，work_mem参数控制每个排序操作使用的内存量[]。

系统配置：

• CPU绑定：将数据库进程绑定到特定的CPU核心，减少CPU迁移的开销。例如，在Linux中，可以使用taskset命令绑定进程到特定CPU核心[]。
• NUMA优化：对于具有NUMA架构的服务器，调整数据库配置以优化内存访问。例如，在SQL Server中，可以启用soft-NUMA优化内存访问[]。
• 硬件升级：在必要时升级CPU或增加CPU核心数，提高处理能力[]。

工作负载管理：

• 读写分离：将读操作和写操作分离到不同的服务器，减轻主库的CPU负担。例如，在MySQL中，可以使用数据库代理+只读实例架构实现读写分离[]。
• 分库分表：将大型表拆分到不同的数据库或表中，分散CPU负载。例如，可以根据时间或业务逻辑进行分库分表[]。
• 资源管理：使用资源管理工具为不同类型的工作负载分配CPU资源。例如，在PostgreSQL中，可以使用资源队列限制某些查询的CPU使用[]。

八、总结与展望

8.1 数据库CPU使用的关键原则

通过对数据库CPU使用机制的全面分析，可以总结出以下关键原则：

效率优先：数据库系统的CPU使用应始终以提高处理效率为目标，通过优化查询执行、减少锁竞争、提高并行处理能力等方式，充分利用CPU资源[]。

平衡策略：在CPU使用上需要平衡多种因素，包括吞吐量与响应时间、并发度与锁开销、内存使用与CPU消耗等。例如，MVCC通过增加内存使用减少锁竞争，提高了CPU的有效利用率[]。

场景适配：不同应用场景（如OLTP、OLAP、混合负载）对CPU使用有不同需求，应根据具体场景调整数据库配置和优化策略。例如，OLTP系统需要优化短事务处理，而OLAP系统需要优化批量数据处理[]。

持续监控：数据库CPU使用情况会随工作负载变化而变化，需要持续监控和调整。例如，通过监控CPU使用率、查询执行时间、锁等待时间等指标，及时发现和解决性能问题[]。

硬件协同：数据库CPU使用应与硬件特性协同优化。例如，利用多核CPU的并行处理能力、SIMD指令集的向量化处理能力、NUMA架构的内存访问优化等[]。

8.2 不同数据库类型CPU使用比较

不同类型数据库在CPU使用上的比较如下：

关系型数据库：

• 优势：强大的查询语言和优化器，成熟的MVCC和锁管理机制，适合复杂查询。
• 劣势：复杂查询优化和执行消耗大量CPU资源，锁管理可能带来额外开销[]。
• 适用场景：OLTP、混合负载、复杂查询场景[]。

NoSQL数据库：

• 优势：简单的数据模型和查询语言，灵活的架构，适合高并发和大数据量[]。
• 劣势：查询功能有限，复杂查询处理能力较弱，索引管理可能消耗较多CPU资源[]。
• 适用场景：高并发、简单查询、非结构化数据场景。

时序数据库：

• 优势：高效的时间序列数据存储和查询，优化的压缩和索引机制，适合时序分析[]。
• 劣势：功能相对单一，不适合通用数据存储和复杂查询[]。
• 适用场景：物联网、监控、时序数据分析场景[]。

8.3 未来发展趋势

数据库CPU使用技术的未来发展趋势包括：

更高效的查询处理：未来数据库将发展更高效的查询处理技术，如更智能的优化器、更高效的执行算法、更先进的向量化执行等。例如，SQL Server 2025的查询处理器引入了改进的锁管理策略与批处理加速技术[]。

AI驱动的优化：人工智能技术将被应用于数据库优化，包括查询优化、索引推荐、参数调优等。例如，利用机器学习预测查询执行时间，生成更优的执行计划[]。

硬件协同优化：数据库将更深入地利用特定硬件特性（如Intel® Advanced Matrix Extensions、GPU加速等）优化CPU使用。例如，第四代英特尔®至强®可扩展处理器内置众多加速器，可为AI、数据分析等工作负载提供性能和能效优势[]。

分布式并行处理：分布式数据库将进一步优化并行处理能力，充分利用集群中的多个节点和CPU核心。例如，GBase 8c的分布式形态支持向量引擎和智能优化，提供极高性能[]。

混合存储与计算：未来数据库将融合多种存储和计算模式，根据数据特性和查询需求动态调整处理方式。例如，GBase 8c的多模多态特性支持行存引擎、列存引擎、内存引擎和向量引擎，可根据不同场景选择合适的处理方式[]。

通过遵循CPU使用的关键原则，理解不同数据库类型的特点，并关注技术发展趋势，数据库管理员可以更有效地优化数据库性能，充分发挥CPU资源的潜力，为各种应用场景提供高效、可靠的数据服务。

参考文献

1. 微软推出SQL Server 2025技术预览版，深化人工智能应用集成[EB/OL]. https://blog.youkuaiyun.com/Leinwin/article/details/148474298, 2025-06-06.

2. 第四代英特尔® 至强® 可扩展处理器[EB/OL]. https://www.intel.sg/content/dam/www/central-libraries/cn/zh/documents/2023-01/23-spr-provide-a-barrier-free-environment-for-your-cloud-growth-business-brief.pdf.

3. 场景1 慢查询导致CPU升高[EB/OL]. https://www.huaweicloud.com/guide/productsdesc-bms_5a90121dd36a4c9638e58acbc5664fd7support0_y, 2025-02-12.

4. 英特尔亮相超聚变探索者大会2025，共建智能体时代[EB/OL]. https://m.sohu.com/a/890529835_114822/, 2025-04-29.

5. 2025年3月国产数据库大事记[EB/OL]. https://blog.youkuaiyun.com/Era666/article/details/147218704, 2025-04-14.

6. MVCC, MultiVersion Concurrency Control[EB/OL]. https://deepaksood619.github.io/databases/concepts/mvcc-multiversion-concurrency-control/, 2023-12-05.

7. 数据库性能问题处理[EB/OL]. https://www.iesdouyin.com/share/video/7149172445797190950/, 2022-09-30.

8. How To Reduce CPU Usage In A Redis Cluster[EB/OL]. https://tyk.io/docs/5.5/developer-support/frequently-asked-questions/how-to-reduce-cpu-usage-in-a-redis-cluster/, 2024-07-08.

9. Redis High CPU Usage[EB/OL]. https://drdroid.io/stack-diagnosis/redis-high-cpu-usage.

10. How to Monitor Redis CPU Usage in 2024?[EB/OL]. https://ubuntuask.com/blog/how-to-monitor-redis-cpu-usage, 2024-11-01.

11. Optimizing Long-Running Query Execution Time[EB/OL]. https://www.mongodb.com/community/forums/t/optimizing-long-running-query-execution-time/240274, 2023-08-19.

12. Troubleshooting High CPU Usage and Slow Query Performance in MongoDB[EB/OL]. http://www.shurl.cc/20f658920b3da5a91cfcae1e202c4e4b.

13. How do I manage MongoDB CPU utilization?[EB/OL]. https://www.dragonflydb.io/faq/mongodb-cpu-utilization-management.

14. Optimizing MongoDB Performance for Large-Scale Data Processing[EB/OL]. https://blog.poespas.me/posts/2024/06/02/optimizing-mongodb-performance-for-large-scale-data-processing/, 2024-06-02.

15. How to enhance MongoDB query speed[EB/OL]. https://labex.io/tutorials/mongodb-how-to-enhance-mongodb-query-speed-435540.

16. Optimizing Flux Query to Retrieve CPU MAX and Memory Usage Without Using Pivot[EB/OL]. https://community.influxdata.com/t/optimizing-flux-query-to-retrieve-cpu-max-and-memory-usage-without-using-pivot/38859.

17. Optimize queries[EB/OL]. https://docs.influxdata.com/influxdb/clustered/query-data/troubleshoot-and-optimize/optimize-queries/.

18. taosd 写入与查询场景下压缩解压及加密解密的 CPU 占用分析[EB/OL]. https://segmentfault.com/a/1190000046197366.

19. HoraeDB 2025 年的发展深度分析[EB/OL]. https://blog.youkuaiyun.com/qq_35760825/article/details/145458616, 2025-02-05.

20. ES时序数据库的性能优化[EB/OL]. https://blog.youkuaiyun.com/sdwxy/article/details/146001593, 2025-03-03.

21. 上海沄熹科技推广时序数据库查询优化新专利，提升数据处理效率[EB/OL]. https://m.sohu.com/a/854070476_121798711/, 2025-01-28.

22. Java时序数据库：InfluxDB数据写入性能调优[EB/OL]. http://www.shurl.cc/4f453960661338a4b7d1c06bf92f5704, 2025-03-16.

23. 时序引擎版本说明[EB/OL]. https://help.aliyun.com/document_detail/316746.html, 2025-03-06.

24. 清华团队提出时序聚类数据库内高效方案，已被SIGMOD 2025接收[EB/OL]. https://blog.youkuaiyun.com/2501_91070801/article/details/147565531, 2025-04-27.

25. MVCC, MultiVersion Concurrency Control[EB/OL]. https://deepaksood619.github.io/databases/concepts/mvcc-multiversion-concurrency-control/, 2023-12-05.

26. Exploring MVCC in Database Systems[EB/OL]. https://makemychance.com/mvcc-in-database-systems/, 2024-01-28.

27. MVCC[EB/OL]. http://www.shurl.cc/e60a8e330a982a7bfe818d109cf7d726.

28. What is MVCC? How does multiversion concurrency control work?[EB/OL]. https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/What-is-MVCC-How-does-Multiversion-Concurrencty-Control-work.

29. Locking Mechanisms in High-Load Systems[EB/OL]. https://luminousmen.com/post/locking-mechanisms-in-highload-systems, 2024-10-06.

30. CPU overhead from lock_tables is about 2X larger for MyRocks than for InnoDB[EB/OL]. https://github.com/facebook/mysql-5.6/issues/1484, 2024-08-07.

31. Implementation of Locking in DBMS[EB/OL]. https://www.prepbytes.com/blog/dbms/implementation-of-locking-in-dbms/, 2024-01-30.

32. SQL ‘LOCKING MECHANISMS’ Statement[EB/OL]. https://reintech.io/blog/sql-locking-mechanisms-comprehensive-tutorial, 2023-09-22.

33. Vectorization[EB/OL]. https://celerdata.com/glossary/vectorization?hs_amp=true, 2023-12-26.

34. Vectorized Execution[EB/OL]. https://questdb.io/glossary/vectorized-execution/.

35. Vectorized Query Execution[EB/OL]. https://www.dremio.com/wiki/vectorized-query-execution/.

36. Vector Database Hardware Requirements[EB/OL]. https://www.restack.io/p/vector-database-answer-hardware-requirements-cat-ai, 2025-04-30.

37. State of Open Source Read-Time OLAP Systems 2025[EB/OL]. http://www.shurl.cc/2878d963623769c6a1459422be874f98, 2025-01-26.

38. Optimization of OLAP In-Memory Database Management Systems with Processing-In-Memory Architecture[EB/OL]. http://www.shurl.cc/11a5a932200cdb745b8463786c7c2d27, 2023-08-26.

39. OLAP database query optimizer and performance[EB/OL]. http://www.shurl.cc/991e8d0491ed1051aaba8062074f2398.

40. Optimizing SQL Server for OLAP Workloads[EB/OL]. http://www.shurl.cc/0964a2fc8c404246f7618ef5c4618354, 2022-06-12.

41. What You Possibly Don’t Know About Columnar Storage[EB/OL]. https://dzone.com/articles/what-you-possibly-dont-know-about-columnar-storage, 2024-02-01.

42. Demystifying Columnar Storage Model[EB/OL]. http://www.shurl.cc/563b79350d6ba3897eaef689d928033d, 2023-05-11.

43. How to make the columnar storage data warehouse more efficient[EB/OL]. https://dev.to/jbx1279/how-to-make-the-columnar-storage-data-warehouse-more-efficient-5h2a, 2023-04-16.

44. What is Columnar Database: Storage Formats & Examples[EB/OL]. https://airbyte.com/data-engineering-resources/columnar-storage#:~:text=A%20relational%20database%20(RDBMS)%2C,and%20accessed%20column%20by%20column., 2023-05-31.

45. Columnar Storage & why you must use it[EB/OL]. https://sqlandhadoop.com/columnar-storage-why-you-must-use-it/.

46. PostgreSQL Documentation: max_parallel_workers_per_gather parameter[EB/OL]. https://postgresqlco.nf/doc/en/param/max_parallel_workers_per_gather/.

47. max_parallel_workers_per_gather[EB/OL]. http://www.shurl.cc/f11bab4fae7efdd19d1092330ab545f6.

48. Maxing out max_parallel_workers in Postgres[EB/OL]. http://www.shurl.cc/3a02cddefb4faec921352c37ceff6051, 2023-02-22.

49. PostgreSQL Performance Tuning: Key Parameters[EB/OL]. https://www.timescale.com/learn/postgresql-performance-tuning-key-parameters, 2024-03-06.

50. PostgreSQL: increased max_parallel_workers_per_gather results in fewer workers?[EB/OL]. https://www.postgresql.org/message-id/B2C0B20E-4562-4F0B-A876-922EA4AC22A8%40americanefficient.com, 2020-06-03.

51. Fine-Tuning PostgreSQL 17 for Optimal Performance[EB/OL]. https://toxigon.com/postgresql-17-performance-tuning, 2024-12-19.

52. MySQL :: MySQL 8.0 Reference Manual :: 17.8.4 Configuring Thread Concurrency for InnoDB[EB/OL]. https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-thread_concurrency.html.

53. innodb_thread_concurrency[EB/OL]. https://releem.com/docs/mysql-performance-tuning/innodb_thread_concurrency.

54. Optimizing MySQL Performance with innodb_thread_concurrency[EB/OL]. https://minervadb.xyz/optimizing-mysql-throughput-fine-tuning-innodb-thread-concurrency/.

55. Fundamentals of MySQL concurrency and its Behavior – Part 1[EB/OL]. https://genexdbs.com/fundamentals-of-mysql-concurrency-and-its-behavior-part-1/, 2022-08-22.

56. InnoDB Thread Concurrency[EB/OL]. https://www.percona.com/blog/innodb-thread-concurrency/.

57. The Engineering Wisdom Behind Redis’s Single-Threaded Design[EB/OL]. https://community.aws/content/2tfQijlXleV5iM6hDkSGkMJlpcd/the-engineering-wisdom-behind-redis-s-single-threaded-design?lang=en, 2025-02-28.

58. Is Redis Multithreaded?[EB/OL]. https://www.dragonflydb.io/faq/is-redis-multithreaded.

59. When I use the io-threads, when the num more than 24， the redis become a single thead[EB/OL]. https://github.com/redis/redis/issues/9327, 2021-08-06.

60. Optimize Flux queries[EB/OL]. https://docs.influxdata.com/influxdb/v2/query-data/optimize-queries/.

61. How to Optimize InfluxDB Performance for Large Time Series Data Sets?[EB/OL]. https://community.influxdata.com/t/how-to-optimize-influxdb-performance-for-large-time-series-data-sets/34411, 2024-06-01.

62. Optimize queries[EB/OL]. https://docs.influxdata.com/influxdb3/clustered/query-data/troubleshoot-and-optimize/optimize-queries/.

63. CPU Performance Metrics[EB/OL]. https://www.influxdata.com/integration/cpu/.

64. influxdb v2.0 CPU utilization is very high[EB/OL]. https://github.com/influxdata/influxdb/issues/23930, 2022-11-21.

65. Optimization of OLAP In-Memory Database Management Systems with Processing-In-Memory Architecture[EB/OL]. http://www.shurl.cc/11a5a932200cdb745b8463786c7c2d27, 2023-08-26.

66. Boost Database Performance with SQL Query Processor in 2025[EB/OL]. https://risingwave.com/blog/boost-database-performance-with-sql-query-processor-in-2025/, 2024-07-29.

67. PostgreSQL Database Tuning for OLAP vs. OLTP Workloads[EB/OL]. https://reintech.io/blog/postgresql-database-tuning-olap-vs-oltp, 2024-04-30.

68. OLAP Database Performance Tuning Guide[EB/OL]. https://github.com/kangkaisen/olap-performance.

69. Mr. JIANG’s DataTalk Room - What You Possibly Don’t Know About Columnar Storage[EB/OL]. http://www.linkedin.com/pulse/mr-jiangs-datatalk-room-what-you-possibly-dont-know-han-lijun, 2017-09-13.

70. Data Warehousing with Columnar Storage[EB/OL]. http://www.shurl.cc/c4fb057c6d5476ad02303df807b672a2, 2024-03-21.

71. 250% cpu used when querying empty column store tables[EB/OL]. https://www.singlestore.com/forum/t/250-cpu-used-when-querying-empty-column-store-tables/1410, 2019-11-25.

72. Columnar Storage[EB/OL]. https://www.dremio.com/wiki/columnar-storage/.

73. innodb_thread_concurrency[EB/OL]. http://www.shurl.cc/ce783e9648c936edede55258a7ce673c.

74. MySQL :: MySQL 9.2 Reference Manual :: 17.8.4 Configuring Thread Concurrency for InnoDB[EB/OL]. https://dev.mysql.com/doc/refman/9.2/en/innodb-performance-thread_concurrency.html.

75. MySQL :: innodb_thread_concurrency[EB/OL]. https://forums.mysql.com/read.php?22,67555,67555.

76. Tuning InnoDB System Variables for Optimal MySQL Thread Performance: A Guide[EB/OL]. https://minervadb.xyz/tuning-innodb-system-variables-for-optimal-mysql-thread-performance/.

77. innodb_thread_concurrency — MariaDB Documentation[EB/OL]. http://www.shurl.cc/53ea9546d9d514a255a2206c105d2c21.

78. PostgreSQL Performance Tuning: Key Parameters[EB/OL]. https://www.timescale.com/learn/postgresql-performance-tuning-key-parameters/.

79. Understanding PostgreSQL Parallel Query[EB/OL]. https://stormatics.tech/blogs/understanding-postgresql-parallel-query, 2023-05-02.

80. PostgreSQL Performance Tuning[EB/OL]. http://www.shurl.cc/a7953fd6839b34f0313421ceab936dcb, 2023-04-24.