数据库优化的指导思路是首先写出的SQL是优化器喜欢的,然后在排除烂的SQL的情况下就是,找瓶颈,数据库吞吐量上不去或者查询慢都是因为某一瓶颈的存在,从非常大的粒度来看,瓶颈可以分为五类:io内存CPU网络锁。
当卡在某一瓶颈时,其他的资源就会被闲置,解决瓶颈或者用非瓶颈的资源做tradeoff达到总和的最大才是优化的正解,比如建索引就是以空间换时间的做法。
由于数据库相对比较复杂,上下文有区别优化思路也会不一样,所以离开上下文谈具体的优化手段就是坑。
大部分开发人员会犯的错误是所谓的“锤子人”,也就是自己是锤子看什么都像钉子,比如觉得慢就说要分区,觉得某种语句的写法一定比另一种快而不考虑场景。
1、调整数据结构的设计。这一部分在开发信息系统之前完成,程序员需要考虑是否使用ORACLE数据库的分区功能,对于经常访问的数据库表是否需要建立索引等。
2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成,程序员在这一步需要考虑应用程序使用什么样的体系结构,是使用传统的Client/Server两层体系结构,还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。
3、调整数据库SQL语句。应用程序的执行最终将归结为数据库中的SQL语句执行,因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器(Oracle Optimizer)和行锁管理器(row-level manager)来调整优化SQL语句。
4、调整服务器内存分配。内存分配是在信息系统运行过程中优化配置的,数据库管理员可以根据数据库运行状况调整数据库系统全局区(SGA区)的数据缓冲区、日志缓冲区和共享池的大小;还可以调整程序全局区(PGA区)的大小。需要注意的是,SGA区不是越大越好,SGA区过大会占用 *** 作系统使用的内存而引起虚拟内存的页面交换,这样反而会降低系统。
5、调整硬盘I/O,这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上,做到硬盘之间I/O负载均衡。
6、调整 *** 作系统参数,例如:运行在UNIX *** 作系统上的ORACLE数据库,可以调整UNIX数据缓冲池的大小,每个进程所能使用的内存大小等参数。
数据库(Database)是按照数据结构来组织、存储和管理数据的仓库,它产生于距今六十多年前,随着信息技术和市场的发展,特别是二十世纪九十年代以后,数据管理不再仅仅是存储和管理数据,而转变成用户所需要的各种数据管理的方式。数据库有很多种类型,从最简单的存储有各种数据的表格到能够进行海量数据存储的大型数据库系统都在各个方面得到了广泛的应用。
在信息化社会,充分有效地管理和利用各类信息资源,是进行科学研究和决策管理的前提条件。数据库技术是管理信息系统、办公自动化系统、决策支持系统等各类信息系统的核心部分,是进行科学研究和决策管理的重要技术手段。
在经济管理的日常工作中,常常需要把某些相关的数据放进这样的“仓库”,并根据管理的需要进行相应的处理。
例如,企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表中,这张表就可以看成是一个数据库。有了这个"数据仓库"我们就可以根据需要随时查询某职工的基本情况,也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行,那我们的人事管理就可以达到极高的水平。此外,在财务管理、仓库管理、生产管理中也需要建立众多的这种"数据库",使其可以利用计算机实现财务、仓库、生产的自动化管理。
扩展资料
数据库,简单来说是本身可视为电子化的文件柜--存储电子文件的处所,用户可以对文件中的数据进行新增、截取、更新、删除等 *** 作。
数据库指的是以一定方式储存在一起、能为多个用户共享、具有尽可能小的冗余度的特点、是与应用程序彼此独立的数据集合。
在经济管理的日常工作中,常常需要把某些相关的数据放进这样的"仓库",并根据管理的需要进行相应的处理。
例如,企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表中,这张表就可以看成是一个数据库。有了这个"数据仓库"我们就可以根据需要随时查询某职工的基本情况,也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行,那我们的人事管理就可以达到极高的水平。此外,在财务管理、仓库管理、生产管理中也需要建立众多的这种"数据库",使其可以利用计算机实现财务、仓库、生产的自动化管理。
参考资料:
主从延时排查方法:
第一种方法:
1showmasterstatus\G;#查看主库的position号记录到多少了。
2从库中执行showslavestatus\G;#查看从库现在获取到哪个position号了
3如果从库的postion号远小于主库的position号,则表示主库dump线程传送二进制出问题了
第二种方法(推荐):
通过监控showslavestatus命令输出的“Seconds_Behind_Master”参数的值来判断NULL,表示io_thread或是sql_thread有任何一个发生故障;
0,该值为零,表示主从复制良好;正值,表示主从已经出现延时,数字越大表示从库延迟越严重。为了再现这种高并发时刻,测试指令为:ab-c12-n10000>
数据库优化是系统工程,性能的提升靠整体。本课程将面面俱到的讲解提升数据库性能的各种因素,让你在最短的时间从小白到资深,将数据库整体架构了然于胸
第1章 实例和故事 试看7 节 | 50分钟
决定电商11大促成败的各个关键因素。
收起列表
视频:1-1 什么决定了电商双11大促的成败 (04:04)试看
视频:1-2 在双11大促中的数据库服务器 (06:03)
视频:1-3 在大促中什么影响了数据库性能 (07:55)
视频:1-4 大表带来的问题 (14:13)
视频:1-5 大事务带来的问题 (17:27)
作业:1-6 讨论题在日常工作中如何应对高并发大数据量对数据库性能挑战
作业:1-7 讨论题在MySQL中事务的作用是什么?
第2章 什么影响了MySQL性能 试看30 节 | 210分钟
详细介绍影响性能各个因素,包括硬件、 *** 作系统等等。
收起列表
视频:2-1 影响性能的几个方面 (04:08)试看
视频:2-2 CPU资源和可用内存大小 (10:54)
视频:2-3 磁盘的配置和选择 (04:44)
视频:2-4 使用RAID增加传统机器硬盘的性能 (11:30)
视频:2-5 使用固态存储SSD或PCIe卡 (08:35)
视频:2-6 使用网络存储SAN和NAS (07:16)
视频:2-7 总结:服务器硬件对性能的影响 (03:27)
视频:2-8 *** 作系统对性能的影响-MySQL适合的 *** 作系统 (03:50)
视频:2-9 CentOS系统参数优化 (11:43)
视频:2-10 文件系统对性能的影响 (03:29)
视频:2-11 MySQL体系结构 (05:29)
视频:2-12 MySQL常用存储引擎之MyISAM (13:23)
视频:2-13 MySQL常用存储引擎之Innodb (10:44)
视频:2-14 Innodb存储引擎的特性(1) (15:24)
视频:2-15 Innodb存储引擎的特性(2) (08:44)
视频:2-16 MySQL常用存储引擎之CSV (09:19)
视频:2-17 MySQL常用存储引擎之Archive (06:08)
视频:2-18 MySQL常用存储引擎之Memory (10:40)
视频:2-19 MySQL常用存储引擎之Federated (11:21)
视频:2-20 如何选择存储引擎 (04:33)
视频:2-21 MySQL服务器参数介绍 (08:04)
视频:2-22 内存配置相关参数 (09:24)
视频:2-23 IO相关配置参数 (10:01)
视频:2-24 安全相关配置参数 (06:13)
视频:2-25 其它常用配置参数 (03:41)
视频:2-26 数据库设计对性能的影响 (04:36)
视频:2-27 总结 (01:32)
作业:2-28 讨论题你会如何配置公司的数据库服务器硬件?
作业:2-29 讨论题你认为对数据库性能影响最大的因素是什么
作业:2-30 讨论题做为电商的DBA,建议开发选哪种MySQL存储引擎
第3章 MySQL基准测试8 节 | 65分钟
了解基准测试,MySQL基准测试工具介绍及实例演示。
收起列表
视频:3-1 什么是基准测试 (02:20)
视频:3-2 如何进行基准测试 (09:00)
视频:3-3 基准测试演示实例 (11:18)
视频:3-4 Mysql基准测试工具之mysqlslap (13:30)
视频:3-5 Mysql基准测试工具之sysbench (11:07)
视频:3-6 sysbench基准测试演示实例 (17:11)
作业:3-7 讨论题MySQL基准测试是否可以体现出业务系统的真实性能
作业:3-8 实 *** 题参数不同取值对性能的影响
第4章 MySQL数据库结构优化14 节 | 85分钟
详细介绍数据库结构设计、范式和反范式设计、物理设计等等。
收起列表
视频:4-1 数据库结构优化介绍 (06:52)
视频:4-2 数据库结构设计 (14:49)
视频:4-3 需求分析及逻辑设计 (11:00)
视频:4-4 需求分析及逻辑设计-反范式化设计 (06:44)
视频:4-5 范式化设计和反范式化设计优缺点 (04:06)
视频:4-6 物理设计介绍 (05:17)
视频:4-7 物理设计-数据类型的选择 (18:59)
视频:4-8 物理设计-如何存储日期类型 (13:37)
视频:4-9 物理设计-总结 (02:37)
图文:4-10 说明MyISAM和Innodb存储引擎的5点不同
作业:4-11 讨论题判断表结构是否符合第三范式要求如不满足要如何修改
作业:4-12 实 *** 题请设计一个电商订单系统的数据库结构
作业:4-13 讨论题以下那个字段适合作为Innodb表的主建使用
作业:4-14 讨论题请为下表中的字段选择合适的数据类型
第5章 MySQL高可用架构设计 试看24 节 | 249分钟
详细介绍二进制日志及其对复制的影响、GTID的复制、MMM、MHA等等。
收起列表
视频:5-1 mysql复制功能介绍 (04:58)
视频:5-2 mysql二进制日志 (22:05)
视频:5-3 mysql二进制日志格式对复制的影响 (09:37)
视频:5-4 mysql复制工作方式 (03:08)
视频:5-5 基于日志点的复制 (20:06)
视频:5-6 基于GTID的复制 (22:32)
视频:5-7 MySQL复制拓扑 (13:58)
视频:5-8 MySQL复制性能优化 (09:23)
视频:5-9 MySQL复制常见问题处理 (08:31)
视频:5-10 什么是高可用架构 (14:09)
视频:5-11 MMM架构介绍 (08:09)
视频:5-12 MMM架构实例演示(上) (09:16)试看
视频:5-13 MMM架构实例演示(下) (18:55)
视频:5-14 MMM架构的优缺点 (08:01)
视频:5-15 MHA架构介绍 (10:02)
视频:5-16 MHA架构实例演示(1) (13:11)
视频:5-17 MHA架构实例演示(2) (16:54)
视频:5-18 MHA架构优缺点 (05:14)
视频:5-19 读写分离和负载均衡介绍 (11:42)
视频:5-20 MaxScale实例演示 (18:25)
作业:5-21 讨论题MySQL主从复制为什么会有延迟,延迟又是如何产生
作业:5-22 实 *** 题请为某互联网项目设计9999%MySQL架构
作业:5-23 讨论题如何给一个已经存在的主从复制集群新增一个从节点
作业:5-24 讨论题给你三台数据库服务器,你如何设计它的高可用架构
第6章 数据库索引优化8 节 | 65分钟
介绍BTree索引和Hash索引,详细介绍索引的优化策略等等。
收起列表
视频:6-1 Btree索引和Hash索引 (20:09)
视频:6-2 安装演示数据库 (01:19)
视频:6-3 索引优化策略(上) (17:33)
视频:6-4 索引优化策略(中) (13:02)
视频:6-5 索引优化策略(下) (12:30)
作业:6-6 讨论题一列上建立了索引,查询时就一定会用到这个索引吗
作业:6-7 讨论题在定义联合索引时为什么需要注意联合索引中的顺序
作业:6-8 实 *** 题SQL建立索引,你会考虑那些因素
第7章 SQL查询优化9 节 | 62分钟
详细介绍慢查询日志及示例演示,MySQL查询优化器介绍及特定SQL的查询优化等。
收起列表
视频:7-1 获取有性能问题SQL的三种方法 (05:14)
视频:7-2 慢查询日志介绍 (08:57)
视频:7-3 慢查询日志实例 (08:27)
视频:7-4 实时获取性能问题SQL (02:21)
视频:7-5 SQL的解析预处理及生成执行计划 (16:02)
视频:7-6 如何确定查询处理各个阶段所消耗的时间 (09:35)
视频:7-7 特定SQL的查询优化 (10:34)
作业:7-8 讨论题如何跟据需要对一个大表中的数据进行删除或更新
作业:7-9 讨论题如何获取需要优化的SQL查询
第8章 数据库的分库分表5 节 | 48分钟
详细介绍数据库分库分表的实现原理及演示案例等。
收起列表
视频:8-1 数据库分库分表的几种方式 (04:34)
视频:8-2 数据库分片前的准备 (13:53)
视频:8-3 数据库分片演示(上) (11:40)
视频:8-4 数据库分片演示(下) (17:02)
作业:8-5 讨论题对于大表来说我们一定要进行分库分表吗
第9章 数据库监控7 节 | 29分钟
介绍数据库可用性监控、性能监控、MySQL主从复制监控等
收起列表
视频:9-1 数据库监控介绍 (04:46)
视频:9-2 数据库可用性监控 (07:20)
视频:9-3 数据库性能监控 (09:39)
视频:9-4 MySQL主从复制监控 (06:16)
作业:9-5 讨论题QPS是否可以真实的反映出数据库的负载情况
作业:9-6 讨论题如何正确评估数据库的当前负载状况
作业:9-7 实 *** 题开发一个简单监控脚本,监控mySQL数据库阻塞情况
数据库慢一般有三种情况
逐渐变慢
突然变慢
不定时变慢
第一种情况 逐渐变慢 要建立一个长期的监控机制 比如 写个shell脚本每天的忙时(通常 ~ etc )定时收集os neork db的信息 每个星期出report对收集到的信息进行分析 这些数据的积累 可以决定后期的优化决策 并且可以是DBA说服manager采用自己决策的重要数据 DBA的价值 就在每个星期的report中体现
第二种情况 突然变慢 也是最容易解决的 先从业务的角度看是DB的使用跟以前有何不同 然后做进一步判断 硬件/网络故障通常也会引起DB性能的突然下降
第一步: 察看DB/OS/NEORK的系统log 排除硬件/网络问题
第二步 察看数据库的等待事件 根据等待事件来判断可能出问题的环节 如果 没有等待事件 可以排除数据库的问题 如果有等待时间 根据不同的等待事件 来找引起这些事件的根源
比如latch free等跟SQL parse有关系的等待事件 OS的表现是CPU 的占用率高
db file scattered read等跟SQL disk read有关系的等待时间 OS的表现是iostat可以看到磁盘读写量增加
第三步: 察看os的信息 CPU/IO/MEMORY等
a Cpu 的占用率
CPU占用率与数据库性能不成反比 CPU占用率高 不能说明数据库性能慢 通常情况 一个优化很好 而且业务量确实很大的数据库 CPU的占用率都会高 而且会平均分布在每个进程上 反过来 CPU的占用率都会高也不代表数据库性能就好 要结合数据库的等待事件来判断CPU占用率高是否合理
如果某个进程的cpu占用高 肯定是这个进程有问题 如果 不是oracle的进程 可以让application察看是否程序有死循环等漏洞 如果 是oracle的进程 可以根据pid查找oracle数据字典看看这个进程的发起程序 正在执行的sql语句 以及等待事件 然后 不同情况使用不同的方法来解决
b IO
排除硬件的IO问题 数据库突然变慢 一般来说 都是一个或几个SQL语句引起的
如果IO很频繁 可以通过优化disk reads高的TOP SQL来解决 当然这也是解决IO问题的最笨也是最有效的办法
OS以及存储的配置也是影响IO的一个重要的原因
比如 最常见的HP unix下异步IO的问题 如果DBA GROUP没有MLOCK的权限 ORACLE是不使用AIO的 偏偏OS与DB的两方的admin如果配合不够好地话 这个配置就很容易给漏掉了
c Memory
第二种情况与memory的关系比较小 只要SGA区配置合理没有变化 一般来说 只要不是Application Memory leak 不会引起突然变慢的现象
第三种情况 不定时变慢 是最难解决的 现场出现的问题原因也是五花八门千奇百怪 最重要的是 出现慢的现象时 以最快的速度抓取到最多的信息以供分析 先写好抓取数据的shell 脚本 并在现象发生时及时按下回车键
一个例子
数据库突然变慢
背景: 一个新应用上线后 数据库突然变慢
第一步 调查新应用
据开发人员讲新应用访问的都是新建立的表 表的数据量很小 没有复杂的SQL查询
查询 v$sqlarea 分别按照disk_reads / buffer_gets / executions 排序 TOP SQL 中没有新应用的SQL 排除新应用数据库访问照成的性能问题
第二步 察看数据库log/ OS log
数据库log中可以看到大量的ORA 错误 以及大量的dump文件 分析dump文件(时间久了 没有dump文件可参考 具体细节没法描述下来 ) 发现是新应用通过dblink访问remote DB时生成的dump文件 应用开发人说没法修改 Oracle也没有相应的patch解决
OS log中没有错误信息
第三步 察看statspack report
从wait events中看到 Top event是 buffer busy waits db file parallel write 等于IO相关的等待事件
从buffer busy waits 的统计信息来看 是等待data block
还有些physical reads等信息与从前比没有太多的异常
Tablespace 的IO reads/writes也没有异常 但是wait明显增加
初步确定是IO问题
第四步 察看OS的信息
top 命令(输出为实验室数据 仅作格式参考)
load averages: : :
processes: sleeping zombie stopped on cpu
CPU states: % idle % user % kernel % iowait % swap
Memory: M real M free M swap in use M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU MAND
a K K cpu/ : % top
mpgj M K sleep : % view_server
当时现场数据显示 iowait 值与以前相比大很多 没有异常进程
sar –d (输出为实验室数据 仅作格式参考)
SunOS sc Generic_ sun u / /
: : device %busy avque r+w/s blks/s avwait avserv
sd
sd a
sd b
sd c
sd g
当时现场数据显示 放数据文件的设备 avwait avque blks/s值偏大
第五步 察看数据库的等待事件
一个大业务量的数据库如果性能不好的话 一般来说都会有大量的等待事件 上百个等待事件很常见 我通常会按照EVENT进行group
Select count() event from v$session_wait where event not in ( on timer pmon timer rdbms ipc message SQLNet message from client ) group by event order by desc;
输出结果显示最多的等待事件是buffer busy waits
进一步分析 找出等待的原因
Select count() p p p from v$session_wait where event = buffer busy waits group by p p p ;
在buffer busy waits等待事件中
P = file#
P = block#
P = id ( 此id对应为等待的原因)
按照p p p group是为了明确buffer busy waits的等待集中在哪些对象上
Metalink对buffer busy waits等待事件的描述有如下一段话
If P shows that the buffer busy wait is waiting for a block read to plete then the blocking session is likely to be waiting on an IO wait (eg: db file sequential read or db file scattered read for the same file# and block#
输出结果显示 等待分布在多个不同的对象上 等待原因为 waiting for a block read to plete 进一步分析为IO的问题
如果 buffer busy waits等待集中在某个对象上 说明有hot block 通过重新rebuild这个对象增加freelist来解决 RAC环境增加freelist group
通过以下SQL可以找到具体的object
Select owner segment_name segment_type from dba_extents where file_id=P and P beeen block_id and block_id+blocks;
P P 是上面v$session_wait查出的具体的值
第六步 明确原因 找出解决步骤
分析
磁盘的IO流量增加
磁盘的IO等待增加
DB的IO流量没有增加
DB的IO等待增加
由 可以推出 有数据库以外的IO访问磁盘
察看磁盘配置 该VG只存放了数据库数据文件和数据库系统文件 排除数据文件 产生IO的是数据库系统文件
数据库系统文件一般来说不会产生IO 有IO读写的地方只有log和dump文件
结论 ora 产生的大量core dump文件堵塞IO
解决办法
消除ora (应用不改的情况下 无法解决)
把dump目录指向别的VG
让oracle尽量少的去写core dump文件
background_core_dump = partial
lishixinzhi/Article/program/Oracle/201311/18969
大家好,我是Tom哥~
为了便于大家查找问题,了解全貌,整理个目录,我们可以快速全局了解关于mysql数据库,面试官一般喜欢问哪些问题
接下来,我们逐条来看看每个问题及答案
MyISAM 和 InnoDB 的区别?
答案:InnoDB 支持 事务、外键、聚集索引,通过MVCC来支持高并发,索引和数据存储在一起。InnoDB 不保存表的具体行数,执行 select count() from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数。
InnoDB 最小的锁粒度是行锁,MyISAM 最小的锁粒度是表锁,并发能力低。MySQL 将默认存储引擎是 InnoDB
mysql 锁有哪些类型?
答案:mysql锁分为共享锁( S lock ) 、排他锁 ( X lock ),也叫做读锁和写锁。根据粒度,可以分为表锁、页锁、行锁。
什么是间隙锁?
答案:间隙锁是可重复读级别下才会有的锁,mysql会帮我们生成了若干 左开右闭 的区间,结合MVCC和间隙锁可以解决幻读问题。
如何避免死锁?
答案:死锁的四个必要条件:1、互斥 2、请求与保持 3、环路等待 4、不可剥夺。
数据库的隔离级别?
答案:读未提交、读已提交、可重复读(mysql的默认级别,每次读取结果都一样,但是有可能产生幻读)、串行化。
Mysql有哪些类型的索引?
答案:
什么是覆盖索引和回表?
答案:
1、覆盖索引,指的是在一次查询中,一个索引包含所有需要查询的字段的值,可能是返回值或where条件
假如我们创建了一个(money,buyer_id)的联合索引,索引的叶子节点包含了 buyer_id 的信息,则不会再 回表 查询。
2、回表,指查询时一些字段值拿不到,需要到主键索引B+树再查一次。
Mysql的最左前缀原则?
答案:即最左优先,在检索数据时从联合索引的最左边开始匹配,直到遇到范围查询(如:> 、< 、between、like等)
例子:where a = 1 and b = 2 and c > 3 and d = 4 ,如果建立(a,b,c,d)组合索引,d是用不到索引的;如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整。
线上SQL的调优经验?
答案:
官方为什么建议采用自增id 作为主键?
答案:自增id是连续的,插入过程也是顺序的,总是插入在最后,减少了页分裂,有效减少数据的移动。所以尽量不要使用字符串(如:UUID)作为主键。
索引为什么采用B+树,而不用B-树,红黑树?
答案:提升查询速度,首先要减少磁盘IO次数,也就是要降低树的高度。
事务的特性有哪些?
答案:ACID。
如何实现分布式事务?
答案:
日常工作中,MySQL 如何做优化?
答案:
mysql 主从同步具体过程?
答案:
什么是主从延迟?
答案:指一个写入SQL *** 作在主库执行完后,将数据完整同步到从库会有一个时间差,称之为主从延迟。计算公式:
注意:不同服务器要保持时钟一致
主从延迟排查方法?
答案:通过 show slave status 命令输出的 Seconds_Behind_Master 参数的值来判断
主从延迟要怎么解决?
答案:
如果数据量太大怎么办?
答案:mysql表的数据量一般控制在千万级别,如果再大的话,就要考虑分库分表。除了分表外,列举了面对海量数据业务的一些常见优化手段
分表后ID如何保证全局唯一呢?
答案:分库分表后,多张表共用一套全局id,原来单表主键自增方式满足不了要求。我们需要重新设计一套id生成器。特点:全局唯一、高性能、高可用、方便接入。
分表后可能遇到的哪些问题?
答案:分表后,与单表的最大区别是有分表键 sharding_key ,用来路由具体的物理表,以电商为例,有买家和卖家两个维度,以 buyer_id 路由,无法满足卖家的需求,反之同样道理。如何解决?
以上就是关于有哪些常见的数据库优化方法(数据库如何优化)全部的内容,包括:有哪些常见的数据库优化方法(数据库如何优化)、数据库性能优化有哪些措施、测量从数据库延迟的方法有等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)