今天我们继续探究国产数据库KES的相关内容，本次的讨论重点将放在SQL优化的细节上。作为Java开辟职员，我们通常并不必要深入相识数据库的底层实现细节，而是更多地关注如何提拔应用性能与数据库的交互服从。具体来说，工作中我们经常必要关注的优化策略包括查察SQL的执行计划和合理地创建索引。
今天我们就从这两个方面深入讨论一下相关的优化技巧。假如你希望相识更深入的内容，建议阅读KES数据库的官方文档，里面涵盖了更多的最佳实践和细节阐明：https://bbs.kingbase.com.cn/docHtml?recId=d16e9a1be637c8fe4644c2c82fe16444&url=aHR0cHM6Ly9iYnMua2luZ2Jhc2UuY29tLmNuL2tpbmdiYXNlLWRvYy92OS9wZXJmb3Ivc3FsLW9wdGltaXphdGlvbi9pbmRleC5odG1s
环境准备
好的，首先，我已经在本地成功安装了KES数据库，为了确保接下来的操作顺利举行，我们首先必要准备好一些底子的数据表以及相应的数据。命令如下：- create table t1(id int, val int, name varchar(64));
- create table t2(id int, val int);
- create index t1_idx on t1(id);
- create index t2_idx on t2(id);
- insert into t1 select i, i%5000, CONCAT('Kingbase',(i%5)) from generate_series(1,3000000) as x(i);
- 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 |
