IT评测·应用市场-qidao123.com技术社区

标题: KES的执行计分别析与索引优化 [打印本页]

---

作者: 篮之新喜    时间: 2025-1-3 09:52
标题: KES的执行计分别析与索引优化
今天我们继续探究国产数据库KES的相关内容，本次的讨论重点将放在SQL优化的细节上。作为Java开辟职员，我们通常并不必要深入相识数据库的底层实现细节，而是更多地关注如何提拔应用性能与数据库的交互服从。具体来说，工作中我们经常必要关注的优化策略包括查察SQL的执行计划和合理地创建索引。
今天我们就从这两个方面深入讨论一下相关的优化技巧。假如你希望相识更深入的内容，建议阅读KES数据库的官方文档，里面涵盖了更多的最佳实践和细节阐明：https://bbs.kingbase.com.cn/docHtml?recId=d16e9a1be637c8fe4644c2c82fe16444&url=aHR0cHM6Ly9iYnMua2luZ2Jhc2UuY29tLmNuL2tpbmdiYXNlLWRvYy92OS9wZXJmb3Ivc3FsLW9wdGltaXphdGlvbi9pbmRleC5odG1s
环境准备

好的，首先，我已经在本地成功安装了KES数据库，为了确保接下来的操作顺利举行，我们首先必要准备好一些底子的数据表以及相应的数据。命令如下：

1. create table t1(id int, val int, name varchar(64));
2. create table t2(id int, val int);
3. create index t1_idx on t1(id);
4. create index t2_idx on t2(id);
5. insert into t1 select i, i%5000, CONCAT('Kingbase',(i%5)) from generate_series(1,3000000) as x(i);
6. insert into t2 select i, i%5000 from generate_series(1,1000000) as x(i);

复制代码

为防止并行影响测试结果，以下所有示例结果是在关闭并行扫描的前提下举行，命令如下：

set max_parallel_workers_per_gather = 0;

执行计划

作为开辟职员，我们与执行计划的接触是最为频繁的。尽管我们编写的 SQL 查询在功能上是可用的，但与程序代码差别，数据库的性能压力会受到 SQL 查询服从的显著影响。因此，在我们将 SQL 查询部署到生产环境之前，通常会细致分析执行计划，确保查询的高效性。否则，一个不优化的慢查询不仅可能影响到单一业务模块的性能，更有可能波及到整个系统，导致性能瓶颈，影响用户体验，以致影响系统的稳定性。
KingbaseES中explain命令来查察执行计划时最常用的方式。其命令格式如下：

explain [option] statement

其中option为可选项，可以是以下5种情况的组合：

• analyze：执行命令并显示执行事件，默认false(更新语句计划慎用)
  
• verbose：显示附加信息，好比计划树中每个节点输出的字段名等，默认false
  
• costs：显示执行计划的成本，默认true
  
• buffers：显示缓冲区的使用信息，包括共享快、本地块和临时读写块，默认false，前置条件是analyze
  
• format：指定执行计划的输出格式，支持：TEXT、XML、JSON或者YAML，默认是text
  

分析执行计划

关于analyze之前说过，我们简单相识下如何分析下explain结果。

explain analyze select * from t1 t where id =555;

• 执行动作：Index Scan using t1_idx on t1
  
  
  
  • Index Scan表现索引扫描，还有一种是Seq Scan代表全表扫描。t1_idx为索引名称。
    
  
  
• 估算成本：(cost=0.43..8.45 rows=1 width=18)
  
  
  
  • Cost=0.43..8.45：第一个数0.43表现启动成本，也就是说返回第一行必要多少cost。第二个数值8.45表现返回所有的数据的成本。这两个数值用..分开。
    
  
  
• 实际成本：(actual time=0.039..0.040 rows=1 loops=1)
  
  
  
  • 只有启动analyze 时才会有。Rows=1：表现实际查询返回了1行记载。Loops=1：表现该索引扫描只执行了1次。
    
  
  
• 索引条件：Index Cond: (id = 555)
  
  
  
  • 代表哪个检索条件命中了索引。
    
  
  

会看执行计划了，我们基本就不会犯特别大的错误。接下来，我们看下索引部门。
索引

在数据库优化中，索引是提高查询服从的关键本领。常见的普通索引和主键索引在此不再赘述，这些类型的索引一般用于对常见查询字段举行优化。
然而，除了这些常见的索引类型之外，还有一些较为特殊的索引类型，对于某些复杂或不常见的查询条件，可能会带来更好的性能提拔。接下来，我们将介绍一些不那么常见的索引类型，建议在遇到复杂查询或特殊查询需求时，实行应用这些索引方式，以便更好地优化数据库的查询服从。
表达式索引

我们通常知道，假如一个查询条件加了函数的话，那么这个索引是肯定无法命中的。所以，在KES也有相应的处置惩罚方法，给函数也加上索引。如下所示：

create index idx_t1 on t1(upper(name));

好比数据库内存储的是包含大小写的字母，但是用户在搜索的时候很难真的将大小写写正确，所以我们直接全都按照大写处置惩罚，这样就可以正常匹配数据了。效果对好比图所示：
未创建索引情况下如下：

创建索引后，情况如下：

like后匹配索引

正常情况下，不管是联合索引照旧like查询都是要满足最左原则的。这明白不介绍了，但是假如我们的like条件是后缀匹配怎么办？如下：

select * from t1 where t1.name  like '%2';

直接全表扫描，如图所示：

这里给出的解决方案是反转函数，其中Collate 为 "C"的字段做like操作时，也被转换为">= AND

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4