【七天深入MySQL实战营】答疑汇总Day6 MySQL表和索引优化实战-阿里云开发者社区

开发者社区> 阿里云数据库> 正文
登录阅读全文

【七天深入MySQL实战营】答疑汇总Day6 MySQL表和索引优化实战

简介: 【开营第六课】【MySQL表和索引优化实战】 讲师:田杰,阿里云高级运维专家。 课程内容:InnoDB表和索引设计最佳实践;索引设计的分析与优化。 答疑汇总:特别感谢班委@李敏 同学

【开营第六课】【MySQL表和索引优化实战】
讲师:田杰,阿里云高级运维专家。
课程内容:InnoDB表和索引设计最佳实践;索引设计的分析与优化。
答疑汇总:特别感谢班委@李敏 同学

https://help.aliyun.com/document_detail/129925.html  大家有时间建议看一下这篇文档,很多实用的功能,无论是云上还是云下都是比较好的解决问题思路参考

1. Mysql 有没有类似 oracle 的快速单表恢复?
A:rds / polar for mysql 都是有的

2. 在什么场景下,适合建 hash 索引?
A:5.7之下,包括 5.8 初期都是没有 hash join,5.8 最新有没有记不得太清楚了,pg 都是有 hash join 的。hash join 适合用在长字符串的等值比较,不能是 like、match、against,不能是模糊查询,也不能是全文索引,只能是等值比较;而且是长字符串,什么叫长字符串,像 abc 这种长度就没必要,五个六个七个八个没必要,可能适合在像 二三十个,三四十个,这种长度的字符串,我说的是字符串,字符串做比较,每个字符,像 utf8 是三个字节来表示,utf8amb 就是四个字节,这种长字符串的等值比较,适合用 hash join,只能做等值,因为本质是要做 hash 值比较,不能支持范围,比如说短字符串,十以内,十五以内,这种长度的比较,其实也是没必要的。在 pg 里面也是比较少用 hash join 的。

3. 运行中生产环境上,myisam 表是否不停机下线直接转换成 innodb,表中有数据,需要注意什么吗?
A:转换后是否还有需要调整的地方吗?rds / polar for mysql 环境下,大家是不可能建成 myisam 表来的,尤其是新购的实例,就我们默认在内核这一块会有一个转换,大家指定 create table engine = myisam,即便写 myisam,也会被替换成 innodb,本身 myisam 的表是创建不起来的,比如说特别老的一些实例,像一些存量的 5.5,可能还能支持 myisam,非常少的 5.5。myisam 表不停机,这种情况,首先得搭建一个复制关系,用 dts 搭建一复制关系,或者自己写 triger,但 trigger 实际上是对事务、业务是有侵入性,我们不太建议,要么就自己搭建一个 dts 的这种复制关系,从 myisam 同步到 innodb,它只读的情况下,对实例的压力还好,搭建一个复制关系,然后等到业务割接的时候做切换。

4. 我公司有张表有两千多万数据,使用的UUID作为主键,没有使用到自增列(这个历史原因),sql 语句:select count(1) cnt from table name where StartDate>=‘2020-11-01’ and StartDate < ‘2020-12-01’ and State=‘C’ and Source=‘Alipay’ 查询大概平均七分钟左右,StartDate,State,Source 都有索引,老师有什么好的优化建议吗?
A:首先这个查询里头,startdate 的两个边界,直接跨度一个月了,state、source 可选的值也不太多,如果真正想解决这个问题,如果这个查询真的运行非常频繁,经常要跑的话。首先第一件事,如果是取count,把它变成每天单独算一下,每天取一个sum值,把它的 count 取出来,然后把业务改造一下,如果我算每个月,我把每天的 count 相加就可以了,做这种事情,因为 select count,不管是 count(1) 还是 count(*) 也好,建议使用 count(*) ,它本身在 innodb 引擎表里面是怎样执行的呢?还是选择最小的索引,它会扫一下,满足这个查询条件,上面最小的索引是谁,然后它会扫这个索引,实际上是全索引扫描;如果没有合适的索引,就会做全表扫描,全表扫描实际上就是扫主键,把主键跑一遍;如果有合适的索引,会做全索引扫描。如果数据量确实比较大,而且时间跨度也比较大,没有什么太好的办法,因为你这个过滤性是比较差的,三个条件加一块,可能过滤性不太好,所以建议是每天出一个 count 值,然后 count 值相加就好了,这个比较好,能比较快的解决问题。如果不行的话,如果业务上不改造的话,建议你做一个组合索引,就把 state、source、startDate,你组合在一起,做一个组合索引,然后看一下 state 和 source ,是哪个改动量比较小,它不经常做 update,像 state 我觉得可能会经常做 update,可以把 source 放在第一个字段,把 state 放在第二个字段,把 startDate 放在第三个字段,做一个组合索引,看看这个组合索引的过滤性怎样,尺寸怎样,如果尺寸不太大,过滤性还比较好,做这么一个组合索引,看一下 count(*) 的执行计划,跑这个索引就好了,就不要再跑 primary key,不要跑原表,但是还是建议,在业务方面该,业务方面在每天做一个 count(*) ,明天算今天的值,最后做加法就好。

5. 单 rds,10亿大表,做优化的思路是怎样的?
A:十亿大表的话就只能拆,如果不用分库分表的话,这种 drds 也好,polar-X 也好,我们 drds 现在已经改名叫 polar-X了。十亿大表你现在只能去拆,有几种方法。第一种方法,考虑冷热数据,十亿大表不可能全部都是热的数据,不可能当前正在跑的业务,这十亿数据都需要加载到内存里头,很有可能不是这样的,那怎么办?拆成两张表,一张冷表,一张热表。保证最频繁查询的,就是最近两周或者一周的数据,这些数据在一块,可能才三千万,五千万的,做成一张表,五千万大小的一张表,性能上一般是不会有多大问题。剩下的我做成冷数据,冷数据要考虑是拆成多张表,还是拆成,如果是拆成多张表的话,每张表的数据会比较平均;如果你要是拆成一张表的话,可能也得有八九亿,操作起来也很痛苦。所以第一个考虑冷数据,第二个按业务角度拆,比如说你的业务是全国的,全国有多少个省,按省的维度拆,我查询经常是按照省的维度查,或者位置也好,时间也好,看按哪个维度拆分。拆的话有两种,第一种做分区,不太建议使用分区表,还有一种是自己去拆,我写一个函数,我的查询每次,都先通过这个函数,把这个表名确定下来,相当于是自己做一下拆表,这是比较好的方法,否则十亿大表,真的是不太好处理。

6. Rds 和 drds,单表的列数多少合适?
A:单表的列数不要太多,50 个左右是比较合适的。大家知道 tp(transaction process)类型的业务,本身是短平快的:查询简单,业务逻辑简单,然后快速地执行,对 rt(response time)要求是很敏感的。比如业务的一个动作,可能会有 5/6 sql 组合在一起,如果每个 sql  执行的时间,rt 很长,组合在一起是会有问题的。我们之前和某家银行,它做这个业务逻辑,它做一个登陆操作,要做 15 个sql,才能完成一个登陆操作,这样的情况下,要求 rt...。因为登陆操作对 rt 很敏感的,我手机登录也好,网页也好,你登陆的时候登陆不上去,对用户体验来说是一个致命的硬伤,那你如果想控制 rt 的话,就要保证它这个里面的动作简洁有效。像 tp 类型的业务,短平快,所以你这个表设计不要太复杂,弄一个大宽表,大宽表一般是 ap(analysis process)类型的业务,比如出报表,做分析,挖掘数据,做预测,是吧。是一定要考虑你的 ap 和 tp 是要分开的,不能说 tp 和ap 混着用,小业务说没问题,是吧,不这么讲究,到了一定尺寸、一定体量,还是要分开的。

7. 因为业务需求,不能使用自增主键,不得不使用还是 UUID 当作主键的时候,怎么操作会更高效一些?
A:你要用 UUID 也没问题。用 UUID,只要对 inset 这种操作,我加载数据,没有太高的要求。比如说,我们之前碰到的这个客户,它是对 insert,就是我加载数据,往里面插入数据,有很高的要求,对数据写入的 rt 是有很高的要求的,一个是要保证,每秒钟写入多少数据,因为他有很多的采集点,要保证把这些数据,它要写到这个库里去,否则它跟不上了, 后台数据写入跟不不上,前台数据吐不出,这样的话,会对他造成一个瓶颈。你如果说没问题,我 1s 就写10条,用 UUID 没问题,100ms 写一条数据,还是可以的,但是表不要太多。

8. Drds 百亿大表如果做查询优化?
A:百亿大表,做 ddl 管理是很困难的,而且你的有足够大的内存,还有你索引的效率可能会下降,所以一个表不要弄得太大。百亿肯定是要拆表了,一般情况下,你考虑这个拆表,里头是有建议值的,一般的 mysql 单实例,这个表最理想的尺寸是存,一千万数据量,五个 GB 数据尺寸。五千万也可以,六千万也可以,十个 GB 一张表,没什么太大问题,那个是理想经验值。当然你说我到了 百亿,这个表的尺寸,绝对不能说是 十几个GB,二十个GB,除非你里头插的都是 int,都是整形值,这是不太可能的。那你到百亿了,你那个表可能得几百个GB,你到这个尺寸了,即便 mysql 最大的 rds 实例,470 GB的内存,承 70%,你放这一张表也不可能,它还有二级索引,这表上肯定还会有二级索引呢,所以还是要拆,而且这张表上是不是这些数据吗,全是我业务当前正在用的,从业务角度看一眼。

9. 虚拟列设置为不持久化,请问数据结果存储在内存中吗?
A:如果是的话,那重启数据库还需要重新计算虚拟列结果到内存中,是吗?没有太多的研究,5.8,8.0 新出的这个。

10. 关于索引字段,是说 varchar 100 是要比 varchar 250 好很多是吗?所以关于索引字段的类型及长度应该更准确?
A:这个 varchar 的问题,实际上它要跟你的字符串实体来呀,最好的情况下是不要把它弄得太长,不是说 varchar 100 一定比 varchar 250 好很多,不要弄得太长。

11. 请问高可用和主从同步一致性,您一般采用什么架构呢?
A:首先说一点,主备实例之间不是同步复制,同步复制什么意思,就是主实例、备实例,做事务 commit 提交的时候,我要保证两遍的事务日志都要同步落盘,mysql 没有干这种事情的,oracle 有,但是 o 真正做这种datagate 也好,三个模式里面选择一个最安全的,数据安全的,这个不可能的,因为你走网络的这样,主库被备库拖累是很严重的,严重影响你的 rt。而且网络波动,大家要有一个概念:网络是不可靠的,网络协议为什么这么复杂,都是处理二般情况的,一般情况都很好处理。所以说这个网络波动,所以是没有用同步复制的,都是异步复制,或者是半同步复制。那这种中间肯定是会出现这种...。数据一致性和高可用之间是有一个矛盾关系,只能是我在这种场景,或者技术条件下,我有一种妥协。我们这边的架构,实际上都是主备复制,咱们的 rds 默认都是半同步复制,大家如果再公共云上,开一个 rds ,如果不做任何操作的话,默认,不能选高性能模版,选那个最基本的性能模版的话,出来的都是半同步复制。半同步复制,是要求主实例事务提交的时候,就commit的时候,也许是自动,也许是手动 commit,也就是隐式/显式 commit 的时候,备库是要能收到主库对这个事务,所有的事务信息是要发过来的,发过来的情况下,我不落盘,但是我要收全了,也就是我的 receive buffer 要收到,并且我的 receive buffer 要通知到 mysql 的,mysql 要认为我这个事务收全了,mysql 要读到结束的标志位了,这个时候它会把这个,返回一个 ack 给主实例,主实例收到这个 ack 之后,主实例才会把这个 commit 提交成功,返回给应用。意思是说,在主实例上,你是看到事务提交成功,那么表示至少有一个备实例,它拿到了主实例上面的事务信息的。

12. Mysql 服务每次重启都特别慢,mysql 进程一直在读数据,3306 进程要两个小时左右才能起来,库里共 1T 左右数据,这种情况是什么原因导致的?
A:重启特别慢,实际上跟踪下,看它到底在干什么。有可能,是不是你的 innodb buffer pool 给 dump 到磁盘上了,启动的时候,是要这个加载回去的,实际上你也跟踪一下,看它在干什么,mysqld 启两个小时才能起起来,实在是有点时间太长了,最好是做一下跟踪,看一下他到底是在干什么,就你 debug 一下。

13. 请问主从复制时,从库开启多线程复制时,如何保证从库应用主库 binlog 的执行顺序,例如:A事务创建表 T,B 事务向表 T 中插入数据 1,两个事务的 binlog 同时复制到从库上,此时多线程会不会先应用 B 事务?是如何保证先应用 A 的?逻辑时钟的执行原理是咋样的呢?Mysql 复制?多线程复制,它本身是表级别的,就是我按照表级别的,我一个表一个线程,他是这样,mysql 官方最开始是按照库级别的,后来改成表级别,我们这边一开始全都是按照表级别的。

14. 表分区可以作为查询优化的方向吗?
A:分区表作为查询优化的方向,分区表,它有一个最大的问题,就是分几个方面。第一方面,它是对主键是有要求的,主键和分区键,是需要都定义在分区键里的,我的分区键都是要包含主键的,或者是要包含一个唯一键也可以,这是一个问题,就是我在做这个分区设计的时候很非常不方便,就是我要把这个主键放进去,这是第一件事;第二件事呢,就是它本身,mysql 的分区设计比 oracle 的灵活性还是要差一些的,差一些差在哪里呢,始载于它没有那么多的这种排列组合,oracle 支持 range list、list range、range hash、hash range,反正怎么折腾都行,排列组合都是可以的,mysql 还是有些限制的;它最大的一个问题是在于,分区表下面的这个数据文件是有多个的,每一个分区实际对应的是一个数据文件,innodb 的一个文件,但是它的这个锁只有一个吧,就是我的这个 mdl 锁,就我做 ddl 的时候,就是我做 ddl 的时候,首先要拿到 mdl 锁,我的 mdl 锁只有一把,就是我如果一旦对这个表做 ddl,做管理操作,那这个表下面所有的分区都会受影响,也就是说,对数据库管理员非常不友好,这个是最大的问题,从业务角度来说还好,因为业务本身对 ddl 不是很敏感,不会经常去跑做那些 ddl 的,如果说我管理员愿意麻烦一点,那么也ok。如果分区规则满足业务的需求,你使用分区也没什么问题,对管理员,对 dba 非常不太友好,通常情况下,我们不太建议用。尤其是什么情况,咱们有的同学做业务设计的时候,喜欢规划三年,规划三年的时候,他按分区的时候,他可能不是按照月分区,而是按照天分区,然后搞得好多表会出一堆特别碎的文件,一张表下面可能会堆好多好多的文件,它每个分区都会做出一个文件,你这种情况下呢,他这个文件会非常多,首先第一个你会吃这个文件描述符,这是一件事;就是 mysql 在文件特别多的时候是有问题的,文件特别特别多,什么情况,就是几十万这种场景,rds 说一个值,rds 超过 40W 数据文件的话,这是没法做备份的,做备份会很困难,基本上做不了,超过 40W,我们的建议值,就是你表的总数量保证在 6/7W 以下,否则对性能是有影响的,所以即便做分区,不要说我规划地非常远,搞得下面几十W 个文件都是分区文件。

15. Optimize table,结果表大了很多,这是为什么?
A:如果确实是这种情况的话,首先第一件事情,把 optimize table 改成 alter table,然后要去加参数的,把 algorithm 从 inplace 改成 copy。改成 copy 的话,是强制要复制表的,但是注意如果你改成 copy 的情况下,你的表是被锁了的,不能写只能读,这种情况下,它是强制复制表。一般情况下,如果你那个表里面真的有很多空洞,有很多空间浪费的,它是能收缩回来的,它那个后台会变成:创建一张新表,把数据倒腾过去,它会变成这种算法,但是它是锁表的。一般情况下,我们不太喜欢用 optimize table,我们都会用 alter table,后边加上 engine = innodb ,这样加参数的,algorithm 控制它的方式,lock 控制它加不加锁,是要用这种方式的。5.8.8.0 的这个版本会好很多,好多事情都是不用这个再去改这个表结构的,它事实上改一下元数据就好,而且有些操作,它是支持新的这个 instant 的,5.8.0 以下 alter table 只支持 copy 和 inplace 这两种方式,5.8 支持 instant,好多操作如果做 instant,会省事很多。技术在发展,我建议大家上来,不要直接做 optimize table这个命令。大家可以看一下,在 innodb 里面,optimize table 等于两条命令的,变成 alter table 表名 engine = table,它先做一件这件事;第二件事它做一个 analyze table,它变成这两件事情。但是它做那个 alter table 是不加参数的,不加的情况下,会有一个问题,就是它有可能会偷偷摸摸地帮你降级,如果你这个表这个操作不满足 inplace 和 lock = none,它是不会报错的,它直接帮你降级,所以有可能会锁表,而且用 inplace 这种方式,它有可能出来之后,表的空间收缩是不明显的,因为它实际上是一个偷懒迂回的策略。如果你为了收缩空间,用 copy 这种方式会是比较好的,但是注意 copy 是要锁表。我们建议还是用 dms,或者是其他的工具,比如像 gost,也有同学喜欢用 percona 的 online schema change,那个也可以,但那个似乎是有点慢,它那个实际是基于 trigger 的,对外键实际上是有特殊考虑的,gost 也是对外键有特殊考虑的。

16. 20亿条数据的表,加字段,大致会加一个星期左右,加字段会导致表不可用,怎么解决?
A:几种方法:一种方法,新买一个实例,新买一个 rds 实例,拿 dts 把数据同步过去,在 dts 的同步的时候,你在那张表单独做一个任务,然后把这个表做个映射,那边新建一个表做个映射,这种最后做切换,这是一种方式,这种情况不影响原实例的业务,如果再做实例上做 ddl 操作,做一个星期,这个是很危险的事情,因为如果你做原生的 ddl,它是有两次缩表的,在最开始和结束的时候,它那个 dml 锁是有两次锁升级的,拿到这个互斥的;当然在 8.0 这个加字段,就不是什么太大的问题了。

17. 硬链接删表是怎么操作的呢?
A:这是日常做这种线下的库吧,在 Rds 是没有这种硬连接删表的,他怎么做的呢。我们会发现一个问题,在 rds,这种大表,做 truncate 或者 drop 的时候,truncate 实际上也是先 drop 掉,再create,这种是要把内存是要扫一遍的,然后本身对 io 有是有比较大冲击,所以我们的 rds 是做了优化,她是对这种大表是做异步的,我对大表做 truncate 还是 drop,都是后台在删除的,这个对前面没有什么太大影响。大家如果线下,如果硬链接,实际上是文件句柄,有多个文件句柄对这一个数据,只要文件句柄还剩下一个,那么这个文件就还存在,说白了就是偷梁换柱。

18. 数据少不需要加索引,那什么时候加(数据越多增加索引代价就越大)?
A:索引这事,首先要看查询,大家优化的时候,首先要关注慢查询,mysql 为什么要把这个慢查询首先一个单独的日志,这个慢查询实际上是很重要的,大家日常是要去扫一扫慢查询的,慢查询里面大家要去关注什么。执行频次非常频繁,扫数据量多,执行时间长,这三个条件来选。而且它是这种这种一层一层的,就是割韭菜一样,割掉一批再出来一批。你先把这个 mysql long query time 参数默认是 1s,先找这种 1s 以上的,性能特别不好的。先改成 3s 或者 5s,先把这些慢查询干掉,干掉一批,优化完了之后,再找 1s 以上的,处理掉,再找 0.5s 的,不要一上来把 long query time,long query time 设置得非常低的话,会发现慢日志里面的条数会非常多,人的处理能力实际上是很有限的,一次应付个十几条,一下子出来 3w 多条慢日志,在丛里头摘可就费了劲了,这就稻草里头长根针,别干这种事情,即便是 CPU 打满了,如果抓不到现场,你要去看慢日志的话,也是这种方法。好多这种同学,我们也碰上好多项目,也是一上来就是 0.1、0.03,定着这个值。出事的时候,生成 36GB 的慢日志,你说这个慢日志怎么分析。数据少的时候不要加索引,表里头几百条,上千条,几千条,这种是没必要加索引的,到了十几万的时候,你是要考虑加索引的给表里头的数据,主要是要看看这个表是不是经常用,如果是像配置表,里头三千行数据,这个配置表加不加索引,如果只是个配置表,它使用的频率是比较低。我举个例子,酒店的业务,会员级别表本身使用频率是非常低的,在内存里头就保留很少一块,你给它加索引不加索引没什么意义,会员级别也就就十来个,表里头就十几行数据。

19. Where 条件中 like 双边都有 % 号,怎么优化走索引,场景是文本匹配?
A:首先你看查询条件后面,insert / delete 都一样的,首先去看 where 条件以后的条件,去看 where 条件子句,根据这个子句,去考虑建立什么样的索引。Like 双 %,有几种情况,但是最好的方法是,把它放到 es(elastic search)里头,或者 adb 里头,我们的 adb for mysql,这种模糊查询最好是放到那边去处理,这叫术业有专攻。真的靠数据库双 %,有在特别特殊的场景下,你 force index,让它走like 对应的字段,全索引扫描,有可能性能会比优化之前会好,这个是很特别的场景,是有强烈的限制条件的。我们不能说把这个作为通用的方法,我们之前优化过,它那个场景没办法走 es ,页来不及放到 adb,没有搭建 es,查询还非得是加 %走,我看它那个表,表里头数据是比较特殊的,它里头可选的值并不是很多,这是让它去 force index,那个 index 会比较小,扫 index 全扫描一遍,速度反而会比它扫描全表要快,它这个是非常特殊的场景,如果是文本匹配,你要看看你是不是要做分词,做全文检索,全文检索必须要用全文检索的引擎,还是用 like %,它出来的结果其实是不一样的。

20. 为什么全文索引中,无论任何查询条件都会 explain 出使用索引?比如 id + age + 那么,建立一个三列的索引,即便单独使用 name 的等值查询,也会 explain 出索引?我建议大家不要考虑在 innodb 里面做全文索引,它对 ddl 是有影响的。在 8.0 以前,5.7、5.6 这两个版本,如果你这个 innodb 表建过全文索引,全文索引即便已经删除了,后边你在做 ddl 操作的时候,好多 ddl 是不能用 inplace 这种操作去做的,只能用 copy 去做,这是 mysql 的限制,所以不要在 mysql 里面做全文检索,不太好用。

21. 达到什么条件需要进行分表?
A:数据量大了,查询慢了,索引的效率下降。或者是你管理上不好管理,那你就考虑要分了,最好是分某个数据。

22. 建议在生产大规模使用 mysql 8.0 MGR 架构吗?有无普通主从复制稳定?
A:Mysql 8.0 mgr,我们是阿里云,我们只能推荐我们自己的产品,关于 mgr 这个架构,就不太多说,不太深入的说。

23. 对亿级大表的查询(字段很少 5 ~ 10)每次 explain 执行计划总是变,我们是靠 force index(时间列二级索引)来解决的,从原理上,这种情况怎么回事?
A:执行计划变这种事情,不光是 mysql 里面出,oracle、db2、pg 也出,只要是这种 cbo(cost-based optimizer) 模型的,肯定会出,大家说这种事很好解,大家到 rds 上,rds 都是有绑定执行计划,有绑定执行计划的 profile,上官网看看 rds 的新特性,新特性里面都有,不用去改 sql,加force index,hint了,因为你改 sql 的话,是要改业务的,我们这边直接绑定执行计划的,绑定就行了。

24. 单表列数 10 列左右比较合理是吗?刚才没有听清?
A:单表列数,经验值是 50 列以内,10 列太少了,50 列就好了,当然这只是经验值,供大家参考。

25. Drds 5.1.28 分库分表 128 分库,整个逻辑表 70 亿数据,4T 大小,这种情况下增加字段有什么建议?
A:Drds 加字段,建议大家,第一个 drds 升级到最新的一个版本,最新的版本 ddl 管理方式和之前是不一样,新版本的 ddl 会比之前有很多增强;第二点是 drds 上加多 ddl 这种事情,一定要对 rds 有一个监控,因为下面可能挂了,我印象中挂了最多,就是 1 个 drds 后面挂了 256个rds 实例,就是你做一个 ddl,分发到每一个 rds 上,每个实例都要跑的,所以说这种多了什么情况都会有,mdl 锁的问题可能是最严重,或者说性能的问题会碰到比较多,所以 ddl 操作一定要在业务低峰期,同时有个监控去看一下。



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

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
链接