AI 助理
备案控制台
开发者社区 数据库 关系型数据库 文章 正文

全文检索 (不包含、不等于) 索引优化 - 阿里云RDS PostgreSQL最佳实践

2017-07-29 4720
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：

背景

PostgreSQL内置了GIN索引，支持全文检索，支持数组检索等多值数据类型的检索。

在全文检索中，不包含某个关键字能用到索引吗？

实际上GIN是倒排索引，不包含某个关键字的查询，实际上是跳过主tree上面的TOKEN的扫描。

只要被跳过的TOKEN包含了大量数据，那么就是划算的。PostgreSQL是基于CBO的执行计划优化器，所以会自动选择最优的索引。

例子1，全文检索不包含查询

1、创建测试表

postgres=# create table notcontain (id int, info tsvector);  
CREATE TABLE

2、创建生成随机字符串的函数

CREATE OR REPLACE FUNCTION   
gen_rand_str(integer)    
 RETURNS text    
 LANGUAGE sql    
 STRICT    
AS $function$    
  select string_agg(a[(random()*6)::int+1],'') from generate_series(1,$1), (select array['a','b','c','d','e','f',' ']) t(a);    
$function$;

3、插入100万测试数据

postgres=# insert into notcontain select generate_series(1,1000000), to_tsvector(gen_rand_str(256));

4、创建全文索引（GIN索引）

create index idx_notcontain_info on notcontain using gin (info);

5、查询某一条记录

postgres=# select * from notcontain limit 1;  
-[ RECORD 1 ]----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  
id   | 1  
info | 'afbbeeccbf':3 'b':16 'bdcdfd':2 'bdcfbcecdeeaed':8 'bfedfecbfab':7 'cd':9 'cdcaefaccdccadeafadededddcbdecdaefbcfbdaefcec':14 'ceafecff':6 'd':17,18 'dbc':12 'dceabcdcbdca':10 'dddfdbffffeaca':13 'deafcccfbcdebdaecda':11 'dfbadcdebdedbfa':19 'eb':15 'ebe':1 'febdcbdaeaeabbdadacabdbbedfafcaeabbdcedaeca':5 'fedeecbcdfcdceabbabbfcdd':4

6、测试不包含某个关键字

数据库自动选择了全表扫描，没有使用GIN索引。

为什么没有使用索引呢，我前面解释了，因为这个关键字的数据记录太少了，不包含它时使用索引过滤不划算。

（当包含它时，使用GIN索引就非常划算。包含和不包含是相反的过程，成本也是反的）

select * from notcontain t1 where info @@ to_tsquery ('!eb');  
  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where info @@ to_tsquery ('!eb');  
                                                             QUERY PLAN                                                               
------------------------------------------------------------------------------------------------------------------------------------  
 Seq Scan on postgres.notcontain t1  (cost=0.00..318054.51 rows=950820 width=412) (actual time=0.016..1087.463 rows=947911 loops=1)  
   Output: id, info  
   Filter: (t1.info @@ to_tsquery('!eb'::text))  
   Rows Removed by Filter: 52089  
   Buffers: shared hit=55549  
 Planning time: 0.131 ms  
 Execution time: 1134.571 ms  
(7 rows)

7、强制关闭全表扫描，让数据库选择索引。

可以看到，使用索引确实是慢的，我们大多数时候应该相信数据库的成本规划是准确的。（只要成本因子和环境性能匹配足够的准，这些都是可以校准的，有兴趣的同学可以参考我写的因子校准方法。）

postgres=# set enable_seqscan=off;  
SET  
  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where info @@ to_tsquery ('!eb');  
                                                                       QUERY PLAN                                                                         
--------------------------------------------------------------------------------------------------------------------------------------------------------  
 Bitmap Heap Scan on postgres.notcontain t1  (cost=82294981.00..82600120.25 rows=950820 width=412) (actual time=1325.587..1540.145 rows=947911 loops=1)  
   Output: id, info  
   Recheck Cond: (t1.info @@ to_tsquery('!eb'::text))  
   Heap Blocks: exact=55549  
   Buffers: shared hit=171948  
   ->  Bitmap Index Scan on idx_notcontain_info  (cost=0.00..82294743.30 rows=950820 width=0) (actual time=1315.663..1315.663 rows=947911 loops=1)  
         Index Cond: (t1.info @@ to_tsquery('!eb'::text))  
         Buffers: shared hit=116399  
 Planning time: 0.135 ms  
 Execution time: 1584.670 ms  
(10 rows)

例子2，全文检索不包含查询

这个例子造一份倾斜数据，这个TOKEN包含了大量的重复记录，通过不包含过滤它。看看能否使用索引。

1、生成测试数据

postgres=# truncate notcontain ;  
TRUNCATE TABLE  
postgres=# insert into notcontain select generate_series(1,1000000), to_tsvector('abc');  
INSERT 0 1000000

2、测试不包含ABC的检索

数据库自动选择了索引扫描，跳过了不需要检索的数据块。

postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where info @@ to_tsquery ('!abc');  
                                                              QUERY PLAN                                                                 
---------------------------------------------------------------------------------------------------------------------------------------  
 Bitmap Heap Scan on postgres.notcontain t1  (cost=220432.15..220433.71 rows=1 width=21) (actual time=107.936..107.936 rows=0 loops=1)  
   Output: id, info  
   Recheck Cond: (t1.info @@ to_tsquery('!abc'::text))  
   Buffers: shared hit=268  
   ->  Bitmap Index Scan on idx_notcontain_info  (cost=0.00..220432.15 rows=1 width=0) (actual time=107.933..107.933 rows=0 loops=1)  
         Index Cond: (t1.info @@ to_tsquery('!abc'::text))  
         Buffers: shared hit=268  
 Planning time: 0.183 ms  
 Execution time: 107.962 ms  
(9 rows)

3、强制使用全表扫描，发现性能确实不如索引扫描，也验证了我们说的PostgreSQL是基于成本的优化器，自动选择最优的执行计划。

postgres=# set enable_bitmapscan =off;  
SET  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where info @@ to_tsquery ('!abc');  
                                                         QUERY PLAN                                                           
----------------------------------------------------------------------------------------------------------------------------  
 Seq Scan on postgres.notcontain t1  (cost=0.00..268870.00 rows=1 width=21) (actual time=1065.436..1065.436 rows=0 loops=1)  
   Output: id, info  
   Filter: (t1.info @@ to_tsquery('!abc'::text))  
   Rows Removed by Filter: 1000000  
   Buffers: shared hit=6370  
 Planning time: 0.059 ms  
 Execution time: 1065.449 ms  
(7 rows)

例子3，普通类型BTREE索引，不等于检索

这个例子是普通类型，使用BTREE索引，看看是否支持不等于的索引检索。

测试方法与GIN测试类似，使用倾斜和非倾斜两种测试数据。

1、非倾斜数据的不包含查询，使用索引过滤的记录非常少。

目前内核层面没有实现BTREE索引的不包含检索。（虽然技术上是可以通过INDEX SKIP SCAN来实现的，跳过不需要扫描的BRANCH节点）

postgres=# truncate notcontain ;  
TRUNCATE TABLE  
postgres=# insert into notcontain select generate_series(1,1000000);  
INSERT 0 1000000  
postgres=# create index idx1 on notcontain (id);  
CREATE INDEX  
postgres=# set enable_bitmapscan =on;  
SET  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where id<>1;  
                                                           QUERY PLAN                                                              
---------------------------------------------------------------------------------------------------------------------------------  
 Seq Scan on postgres.notcontain t1  (cost=0.00..16925.00 rows=999999 width=36) (actual time=0.011..110.592 rows=999999 loops=1)  
   Output: id, info  
   Filter: (t1.id <> 1)  
   Rows Removed by Filter: 1  
   Buffers: shared hit=4425  
 Planning time: 0.195 ms  
 Execution time: 156.013 ms  
(7 rows)  
  
  
postgres=# set enable_seqscan=off;  
SET  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where id<>1;  
                                                                   QUERY PLAN                                                                      
-------------------------------------------------------------------------------------------------------------------------------------------------  
 Seq Scan on postgres.notcontain t1  (cost=10000000000.00..10000016925.00 rows=999999 width=36) (actual time=0.011..110.964 rows=999999 loops=1)  
   Output: id, info  
   Filter: (t1.id <> 1)  
   Rows Removed by Filter: 1  
   Buffers: shared hit=4425  
 Planning time: 0.062 ms  
 Execution time: 156.461 ms  
(7 rows)

2、更换SQL写法，可以实现索引检索。但实际上由于不是使用的INDEX SKIP SCAN，所以需要一个JOIN过程，实际上效果并不佳。

postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where not exists (select 1 from notcontain t2 where t1.id=t2.id and t2.id=1);  
                                                                      QUERY PLAN                                                                        
------------------------------------------------------------------------------------------------------------------------------------------------------  
 Merge Anti Join  (cost=0.85..25497.28 rows=999999 width=36) (actual time=0.023..277.639 rows=999999 loops=1)  
   Output: t1.id, t1.info  
   Merge Cond: (t1.id = t2.id)  
   Buffers: shared hit=7164  
   ->  Index Scan using idx1 on postgres.notcontain t1  (cost=0.42..22994.22 rows=1000000 width=36) (actual time=0.009..148.520 rows=1000000 loops=1)  
         Output: t1.id, t1.info  
         Buffers: shared hit=7160  
   ->  Index Only Scan using idx1 on postgres.notcontain t2  (cost=0.42..3.04 rows=1 width=4) (actual time=0.007..0.008 rows=1 loops=1)  
         Output: t2.id  
         Index Cond: (t2.id = 1)  
         Heap Fetches: 1  
         Buffers: shared hit=4  
 Planning time: 0.223 ms  
 Execution time: 322.798 ms  
(14 rows)  
postgres=# set enable_mergejoin=off;  
SET  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where not exists (select 1 from notcontain t2 where t1.id=t2.id and t2.id=1);  
                                                                  QUERY PLAN                                                                    
----------------------------------------------------------------------------------------------------------------------------------------------  
 Hash Anti Join  (cost=3.05..27053.05 rows=999999 width=36) (actual time=0.060..251.232 rows=999999 loops=1)  
   Output: t1.id, t1.info  
   Hash Cond: (t1.id = t2.id)  
   Buffers: shared hit=4432  
   ->  Seq Scan on postgres.notcontain t1  (cost=0.00..14425.00 rows=1000000 width=36) (actual time=0.011..84.659 rows=1000000 loops=1)  
         Output: t1.id, t1.info  
         Buffers: shared hit=4425  
   ->  Hash  (cost=3.04..3.04 rows=1 width=4) (actual time=0.014..0.014 rows=1 loops=1)  
         Output: t2.id  
         Buckets: 1024  Batches: 1  Memory Usage: 9kB  
         Buffers: shared hit=4  
         ->  Index Only Scan using idx1 on postgres.notcontain t2  (cost=0.42..3.04 rows=1 width=4) (actual time=0.010..0.011 rows=1 loops=1)  
               Output: t2.id  
               Index Cond: (t2.id = 1)  
               Heap Fetches: 1  
               Buffers: shared hit=4  
 Planning time: 0.147 ms  
 Execution time: 297.127 ms  
(18 rows)  
  
postgres=# set enable_seqscan=off;  
SET  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from notcontain t1 where not exists (select 1 from notcontain t2 where t1.id=t2.id and t2.id=1);  
                                                                      QUERY PLAN                                                                        
------------------------------------------------------------------------------------------------------------------------------------------------------  
 Hash Anti Join  (cost=3.48..35622.27 rows=999999 width=36) (actual time=0.036..324.401 rows=999999 loops=1)  
   Output: t1.id, t1.info  
   Hash Cond: (t1.id = t2.id)  
   Buffers: shared hit=7164  
   ->  Index Scan using idx1 on postgres.notcontain t1  (cost=0.42..22994.22 rows=1000000 width=36) (actual time=0.017..149.383 rows=1000000 loops=1)  
         Output: t1.id, t1.info  
         Buffers: shared hit=7160  
   ->  Hash  (cost=3.04..3.04 rows=1 width=4) (actual time=0.011..0.011 rows=1 loops=1)  
         Output: t2.id  
         Buckets: 1024  Batches: 1  Memory Usage: 9kB  
         Buffers: shared hit=4  
         ->  Index Only Scan using idx1 on postgres.notcontain t2  (cost=0.42..3.04 rows=1 width=4) (actual time=0.008..0.009 rows=1 loops=1)  
               Output: t2.id  
               Index Cond: (t2.id = 1)  
               Heap Fetches: 1  
               Buffers: shared hit=4  
 Planning time: 0.141 ms  
 Execution time: 369.749 ms  
(18 rows)

3、PostgreSQL还支持多核并行，所以全表扫描还可以暴力提升性能。

如果记录数非常多，使用并行扫描，性能提升非常明显。

postgres=# create  unlogged table ptbl(id int);  
CREATE TABLE  
postgres=# insert into ptbl select generate_series(1,100000000);  
  
postgres=# alter table ptbl set (parallel_workers =32);  
  
\timing  
  
非并行查询：  
postgres=# set max_parallel_workers_per_gather =0;  
postgres=# select count(*) from ptbl where id<>1;  
  count     
----------  
 99999999  
(1 row)  
  
Time: 11863.151 ms (00:11.863)  
  
并行查询：  
postgres=# set max_parallel_workers_per_gather =32;  
postgres=# select count(*) from ptbl where id<>1;  
  count     
----------  
 99999999  
(1 row)  
  
Time: 610.017 ms

使用并行查询后，性能提升非常明显。

例子4，普通类型partial BTREE索引，不等于检索

对于固定的不等于查询，我们可以使用PostgreSQL的partial index功能。

create table tbl (id int, info text, crt_time timestamp, c1 int);

select * from tbl where c1<>1;

insert into tbl select generate_series(1,10000000), 'test', now(), 1;
insert into tbl values (1,'abc',now(),2);

create index idx_tbl_1 on tbl(id) where c1<>1;

cool，使用PARTIAL INDEX，0.03毫秒，在1000万数据中进行不等于检索。

postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tbl where c1<>1;
                                                       QUERY PLAN                                                        
-------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tbl_1 on postgres.tbl  (cost=0.12..1.44 rows=1 width=21) (actual time=0.015..0.015 rows=1 loops=1)
   Output: id, info, crt_time, c1
   Buffers: shared hit=1 read=1
 Planning time: 0.194 ms
 Execution time: 0.030 ms
(5 rows)

小结

1、PostgreSQL内置了GIN索引，支持全文检索、支持数组等多值类型的搜索。

2、PostgreSQL使用基于成本的执行计划优化器，会自动选择最优的执行计划，在进行不包含检索时，PostgreSQL会自动选择是否使用索引扫描。

3、对于BTREE索引，理论上也能实现不等于的搜索（INDEX SKIP SCAN），目前内核层面还没有实现它，目前可以通过调整SQL的写法来使用索引扫描。

4、PostgreSQL还支持多核并行，所以全表扫描还可以暴力提升性能。 如果记录数非常多，使用并行扫描，性能提升非常明显。

5、PostgreSQL支持partial index，可以用于分区索引，或者部分索引。对于固定条件的不等于查询，效果非常显著。

文章标签：
云数据库 RDS MySQL 版
云原生数据库 PolarDB
关系型数据库
索引
测试技术
PostgreSQL
RDS
关键词：
云数据库 RDS最佳实践
云数据库 RDS postgresql
rds PostgreSQL
云数据库 RDS MySQL 版postgresql
阿里云云数据库 RDS
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
德哥
目录
相关文章
游客vphb4ae2je2zi
|
3月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格：MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB，多种引擎优惠上线！MySQL倚天版88元/年，SQL Server 2核4G仅299元/年，PostgreSQL 227元/年起。高可用、可弹性伸缩，安全稳定。详情见官网活动页。
游客vphb4ae2je2zi
802 152
运营研究坊
|
6月前
|
SQL 缓存 关系型数据库
MySQL 慢查询是怎样优化的
本文深入解析了MySQL查询速度变慢的原因及优化策略，涵盖查询缓存、执行流程、SQL优化、执行计划分析（如EXPLAIN）、查询状态查看等内容，帮助开发者快速定位并解决慢查询问题。
运营研究坊
271 0
上云就上阿狸云
|
3月前
|
关系型数据库 分布式数据库 数据库
阿里云数据库收费价格：MySQL、PostgreSQL、SQL Server和MariaDB引擎费用整理
阿里云数据库提供多种类型，包括关系型与NoSQL，主流如PolarDB、RDS MySQL/PostgreSQL、Redis等。价格低至21元/月起，支持按需付费与优惠套餐，适用于各类应用场景。
上云就上阿狸云
854 4
翼龙云TG_yilongcloud
|
3月前
|
SQL 关系型数据库 MySQL
阿里云的云数据库RDS简介
阿里云关系型数据库RDS（Relational Database Service）是一种安全稳定、高性价比、可弹性伸缩的在线数据库服务。支持MySQL、SQL Server、PostgreSQL和MariaDB引擎，提供容灾、备份、恢复、监控、迁移等全套解决方案，帮助用户轻松应对数据库运维挑战。RDS具备高可用性、高安全性、轻量运维和弹性伸缩等优势，适用于各类业务场景，助力企业降低成本、提升效率。
翼龙云TG_yilongcloud
396 1
程序员爱钓鱼
|
6月前
|
SQL 关系型数据库 MySQL
Go语言数据库编程：使用 `database/sql` 与 MySQL/PostgreSQL
Go语言通过`database/sql`标准库提供统一数据库操作接口，支持MySQL、PostgreSQL等多种数据库。本文介绍了驱动安装、连接数据库、基本增删改查操作、预处理语句、事务处理及错误管理等内容，涵盖实际开发中常用的技巧与注意事项，适合快速掌握Go语言数据库编程基础。
程序员爱钓鱼
504 62
蓝易云
|
4月前
|
缓存 关系型数据库 MySQL
降低MySQL高CPU使用率的优化策略。
通过上述方法不断地迭代改进，在实际操作中需要根据具体场景做出相对合理判断。每一步改进都需谨慎评估其变动可能导致其他方面问题，在做任何变动前建议先在测试环境验证其效果后再部署到生产环境中去。
蓝易云
230 6
上云就上阿狸云
|
3月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎，提供高性价比、稳定安全的云数据库服务，适用于多种行业与业务场景。
上云就上阿狸云
319 0
Unfailed_realme
|
5月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分，阐述了 char 与 varchar 在存储方式和性能上的差异，以及事务的 ACID 特性、并发事务问题及对应的隔离级别（MySQL 默认 REPEATABLE READ）。 索引基础部分，详解了 InnoDB 默认的 B+tree 索引结构（多路平衡树、叶子节点存数据、双向链表支持区间查询），区分了聚簇索引（数据与索引共存，唯一）和二级索引（数据与索引分离，多个），解释了回表查询的概念及优化方法，并分析了 B+tree 作为索引结构的优势（树高低、效率稳、支持区间查询）。 索引优化部分，列出了索引创建的六大原则
Unfailed_realme
148 2
青云@yd
|
5月前
|
存储 SQL 关系型数据库
MySQL 动态分区管理：自动化与优化实践
本文介绍了如何利用 MySQL 的存储过程与事件调度器实现动态分区管理，自动化应对数据增长，提升查询性能与数据管理效率，并详细解析了分区创建、冲突避免及实际应用中的关键注意事项。
青云@yd
230 0
技术自由圈/原疯狂创客圈
|
7月前
|
存储 SQL 关系型数据库
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
技术自由圈/原疯狂创客圈
525 8
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
数据库

关系型数据库

热门文章

最新文章

  • 1
    德哥的PostgreSQL私房菜 - 史上最屌PG资料合集
  • 2
    什么场景应该用 MongoDB ？
  • 3
    在Docker上玩转PostgreSQL -- Mac篇
  • 4
    Linux 性能诊断 perf使用指南
  • 5
    PostgreSQL 9种索引的原理和应用场景
  • 6
    Jedis常见异常汇总
  • 7
    PostgreSQL 9.5+ 高效分区表实现 - pg_pathman
  • 8
    PostgreSQL 触发器用法详解 - 1
  • 9
    时序数据库分析 - TimescaleDB时序数据库介绍
  • 10
    PostgreSQL 与基友们的故事之 - Redis (无限缓存,实时标签...)
  • 1
    CAXA 电子图板 2025 下载安装指南：小白也能轻松搞定
    61
  • 2
    【赵渝强老师】国产金仓数据库的体系架构
    130
  • 3
    阿里巴巴双肩包带回家！参与「RDS AI助手」体验反馈赢好礼
    113
  • 4
    RDS AI助手深度测评-场景4：CPU压测指引
    89
  • 5
    【Java架构师体系课 | MySQL篇】⑦ 深入理解MySQL事务隔离级别与锁机制
    146
  • 6
    TRUNCATE、DELETE、DROP 的区别？
    299
  • 7
    为什么MySQL会选错索引，如何解决？
    138
  • 8
    【Java架构师体系课 | MySQL篇】⑤ 索引优化实战一
    113
  • 9
    什么是脏读、幻读、不可重复读？Mysql的隔离级别是什么？
    333
  • 10
    【Java架构师体系课 | MySQL篇】② 深入理解MySQL索引底层数据结构与算法
    145

    • 相关产品

  • 云数据库 RDS
    文档详情 产品详情
  • 云数据库 RDS PostgreSQL 版
    文档详情 产品详情
  • 云数据库 RDS MySQL 版
    文档详情 产品详情

    • 相关课程

    更多
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布
  • 阿里云MySQL云数据库产品体系介绍
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL

    • 推荐镜像

    更多
  • mysql
  • postgresql
    • 下一篇
    安全设备篇——WAF