数据库性能指标，衡量数据库性能的重要指标

各位老铁们好，相信很多人对数据库性能指标都不是特别的了解，因此呢，今天就来为大家分享下关于数据库性能指标以及衡量数据库性能的重要指标的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！

数据库性能优化基准测试的度量指标有哪些

当前业界常见的服务器性能指标有:

TPC-C

TPC-E

TPC-H

SPECjbb2005

SPECjEnterprise2010

SPECint2006及 SPECint_rate_2006

SPECfp2006及 SPECfp_rate_2006

SAP SD 2-Tier

LINPACK

RPE2

一、TPC(Transaction Processing Performance Council)即联机交易处理性能协会,成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标:为业界提供可信的数据库及交易处理基准测试结果,当前发布主要基准测试为:

TPC-C:数据库在线查询(OLTP)交易性能

TPC-E:数据库在线查询(OLTP)交易性能

TPC-H:商业智能/数据仓库/在线分析(OLAP)交易性能

1.TPC-C测试内容：数据库事务处理测试,模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现.正规 TPC-C测试结果发布必须提供 tpmC值,即每分钟完成多少笔 TPC-C数据库交易(TPC-C Transaction Per Minute),同时要提供性价比$/tpmC。如果把 TPC-C测试结果写成为 tpm, TPM, TPMC, TPCC均不属正规。

2.TPC-E测试内容：数据库事务处理测试，模拟一个证券交易系统。与TPC-C一样，实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现。正规TPC-E测试结果必须提供tpsE值，即每秒钟完成多少笔TPC-E数据库交易（transaction per second），同时提供$/tpsE。测试结果写成其他形式均不属正规。

对比：TPC-E测试较TPC-C测试，在测试模型搭建上增加了应用服务器层，同时增加了数据库结构的复杂性,测试成本相对降低。截止目前，TPC-E的测试结果仅公布有50种左右，且测试环境均为PC服务器和windows操作系统，并无power服务器的测试结果。除此之外，TPC官方组织并未声明TPC-E取代TPC-C，所以，说TPC-E取代TPC-C并没有根据。

衡量数据库性能的重要指标

具体来说，本文包括以下内容:

事务

查询性能

用户和查询冲突

容量

配置

NoSQL数据库

事务

事务可以观察真实用户的行为：能够在应用交互时捕获实时性能。众所周知，测量事务的性能包括获取整个事务的响应时间和组成事务的各个部分的响应时间。通常我们可以用这些响应时间与满足事务需求的基线对比，来确定当前事务是否处于正常状态。

如果你只想衡量应用的某个方面，那么可以评估事务的行为。所以，尽管容器指标能够提供更丰富的信息，并且帮助你决定何时对当前环境进行自动测量，但你的事务就足以确定应用性能。无需向应用程序服务器获取 CPU的使用情况，你更应该关心用户是否完成了事务，以及该事务是否得到了优化。

补充一个小知识点，事务是由入口点决定的，通过该入口点可以启动事务与应用进行交互。

一旦定义了事务，会在整个应用生态系统中对其性能进行测量，并将每个事务与基线进行比对。例如，我们可能会决定当事务的响应时间与基线相比，一旦慢于平均响应时间的两个标准差是否就应该判定为异常，如图1所示。

用于评估事务的基线与正在进行的事务活动在时间上是一致的，但事务会由每个事务执行来完善。例如，当你选定一个基线，在当前事务结束之后，将事务与平均响应时间按每天的小时数和每周的天数进行对比，所有在那段时间内执行的事务都将会被纳入下周的基线中。通过这种机制，应用程序可以随时间而变化，而无需每次都重建原始基线；你可以将其看作是一个随时间移动的窗口。

总之，事务最能反映用户体验的测量方法，所以也是衡量性能状况最重要的指标。

查询性能

最容易检测到查询性能是否正常的指标就是查询本身。由查询引起的问题可能会导致时间太长而无法识别所需数据或返回数据。所以不妨在查询中排查以下问题。

1.选择过多冗余数据

编写查询语句来返回适当的数据是远远不够的，很可能你的查询语句会返回太多列，从而导致选择行和检索数据变得异常缓慢。所以，最好是列出所需的列，而不是直接用 SELECT*。当需要在特定字段中查询时，该计划可能会确定一个覆盖索引从而加快结果返回。覆盖索引通常会包含查询中使用的所有字段。这意味着数据库可以仅从索引中产生结果，而不需要通过底层表来构建。

另外，列出结果中所需的列不仅可以减少传输的数据，还能进一步提高性能。

2.表之间的低效联接

联接会导致数据库将多组数据带到内存中进行比较，这会产生多个数据库读取和大量 CPU。根据表的索引，联接还可能需要扫描两个表的所有行。如果写不好两个大型表之间的联接，就需要对每个表进行完整扫描，这样的计算量将会非常大。其他会拖慢联接的因素包括联接列之间存在不同的数据类型、需要转换或加入包含 LIKE的条件，这样就会阻止使用索引。另外，还需注意避免使用全外联接；在恰当的时候使用内部联接只返回所需数据。

3.索引过多或过少

如果查询优化没有可用的索引时，数据库会重新扫描表来产生查询结果，这个过程会生成大量的磁盘输入/输出（I/O）。适当的索引可以减少排序结果的需要。虽然非唯一值的索引在生成结果时，不能像唯一索引那样方便。如果键越大，索引也会变大，并通过它们创建更多的磁盘 I/O。大多数索引是为了提高数据检索的性能，但也需要明白索引本身也会影响数据的插入和更新，因为所有相关联的指标都必须更新。

4.太多的SQL导致争用解析资源

任何 SQL查询在执行之前都必须被解析，在生成执行计划之前需要对语法和权限进行检查。由于解析非常耗时，数据库会保存已解析的 SQL来重复利用，从而减少解析的耗时。因为 WHERE语句不同，所以使用文本值的查询语句不能被共享。这将导致每个查询都会被解析并添加到共享池中，由于池的空间有限，一些已保存的查询会被舍弃。当这些查询再次出现时，则需要重新解析。

用户和查询冲突

数据库支持多用户，但多用户活动也可能造成冲突。

1.由慢查询导致的页/行锁定

为了确保查询产生精确的结果，数据库必须锁定表以防止在运行读取查询时再发生其他的插入和更新行为。如果报告或查询相当缓慢，需要修改值的用户可能需要等待至更新完成。锁提示能帮助数据库使用最小破坏性的锁。从事务数据库中分离报表也是一种可靠的解决方法。

2.事务锁和死锁

当两个事务被阻塞时会出现死锁，因为每一个都需要使用被另一个占用的资源。当出现一个普通锁时，事务会被阻塞直到资源被释放。但却没有解决死锁的方案。数据库会监控死锁并选择终止其中一个事务，释放资源并允许该事务继续进行，而另一个事务则回滚。

3.批处理操作造成资源争夺

批处理过程通常会执行批量操作，如大量的数据加载或生成复杂的分析报告。这些操作是资源密集型的，但可能影响在线用户的访问应用的性能。针对此问题最好的解决办法是确保批处理在系统使用率较低时运行，比如晚上，或用单独的数据库进行事务处理和分析报告。

容量

并不是所有的数据库性能问题都是数据库问题。有些问题也是硬件不合适造成的。

1. CPU不足或 CPU速度太慢

更多 CPU可以分担服务器负载，进一步提高性能。数据库的性能不仅是数据库的原因，还受到服务器上运行其他进程的影响。因此，对数据库负载及使用进行审查也是必不可少的。由于 CPU的利用率时时在变，在低使用率、平均使用率和峰值使用率的时间段分别检查该指标可以更好地评估增加额外的 CPU资源是否有益。

2. IOPS不足的慢磁盘

磁盘性能通常以每秒输入/输出操作（IOPS）来计。结合 I/O大小，该指标可以衡量每秒的磁盘吞吐量是多少兆。同时，吞吐量也受磁盘的延迟影响，比如需要多久才能完成请求，这些指标主要是针对磁盘存储技术而言。传统的硬盘驱动器（HDD）有一个旋转磁盘，通常比固态硬盘（SSD）或闪存更慢。直到近期，SSD虽然仍比 HDD贵，但成本已经降了下来，所以在市场上也更具竞争力。

3.全部或错误配置的磁盘

众所周知，数据库会被大量磁盘访问，所以不正确配置的磁盘可能带来严重的性能缺陷。磁盘应该适当分区，将系统数据目录和用户数据日志分开。高度活跃的表应该区分以避免争用，通过在不同磁盘上存放数据库和索引增加并行放置，但不要将操作系统和数据库交换空间放置在同一磁盘上。

4.内存不足

有限或不恰当的物理内存分配会影响数据库性能。通常我们认为可用的内存更多，性能就越好。监控分页和交换,在多个非繁忙磁盘中建立多页面空间，进一步确保分页空间分配足够满足数据库要求；每个数据库供应商也可以在这个问题上提供指导。

5.网速慢

网络速度会影响到如何快速检索数据并返回给终端用户或调用过程。使用宽带连接到远程数据库。在某些情况下，选择 TCP/IP协议而不是命名管道可显著提高数据库性能。

配置

每个数据库都需设置大量的配置项。通常情况下，默认值可能不足以满足数据库所需的性能。所以，检查所有的参数设置，包括以下问题。

1.缓冲区缓存太小

通过将数据存储在内核内存，缓冲区缓存可以进一步提高性能同时减少磁盘 I/O。当缓存太小时，缓存中的数据会更频繁地刷新。如果它再次被请求，就必须从磁盘重读。除了磁盘读取缓慢之外，还给 I/O设备增添了负担从而成为瓶颈。除了给缓冲区缓存分配足够的空间，调优 SQL查询可以帮助其更有效地利用缓冲区缓存。

2.没有查询缓存

查询缓存会存储数据库查询和结果集。当执行相同的查询时，数据会在缓存中被迅速检索，而不需要再次执行查询。数据会更新失效结果，所以查询缓存是唯一有效的静态数据。但在某些情况下，查询缓存却可能成为性能瓶颈。比如当锁定为更新时，巨大的缓存可能导致争用冲突。

3.磁盘上临时表创建导致的 I/O争用

在执行特定的查询操作时，数据库需要创建临时表，如执行一个 GROUP BY子句。如果可能，在内存中创建临时表。但是，在某些情况下，在内存中创建临时表并不可行，比如当数据包含 BLOB或 TEXT对象时。在这些情况下，会在磁盘上创建临时表。大量的磁盘 I/ O都需要创建临时表、填充记录、从表中选择所需数据并在查询完成后舍弃。为了避免影响性能，临时数据库应该从主数据库中分离出来。重写查询还可以通过创建派生表来减少对临时表的需求。使用派生表直接从另一个 SELECT语句的结果中选择，允许将数据加到内存中而不是当前磁盘上。

NoSQL数据库

NoSQL的优势在于它处理大数据的能力非常迅速。但是在实际使用中，也应该综合参考 NoSQL的缺点，从而决定是否适合你的用例场景。这就是为什么NoSQL通常被理解为「不仅仅是 SQL」，说明了 NoSQL并不总是正确的解决方案，也没必要完全取代 SQL，以下分别列举出五大主要原因。

1.挑剔事务

难以保持 NoSQL条目的一致性。当访问结构化数据时，它并不能完全确保同一时间对不同表的更改都生效。如果某个过程发生崩溃，表可能会不一致。一致事务的典型代表是复式记账法。相应的信贷必须平衡每个借方，反之亦然。如果双方数据不一致则不能输入。NoSQL则可能无法保证「收支平衡」。

2.复杂数据库

NoSQL的支持者往往以高效代码、简单性和 NoSQL的速度为傲。当数据库任务很简单时，所有这些因素都是优势。但当数据库变得复杂，NoSQL会开始分解。此时，SQL则比 NoSQL更好地处理复杂需求，因为 SQL已经成熟，有符合行业标准的接口。而每个 NoSQL设置都有一个唯一的接口。

3.一致联接

当执行 SQL的联接时，由于系统必须从不同的表中提取数据进行键对齐，所以有一个巨大的开销。而 NoSQL似乎是一个空想，因为缺乏联接功能。所有的数据都在同一个表的一个地方。当检索数据时，它会同时提取所有的键值对。问题在于这会创建同一数据的多个副本。这些副本也必须更新，而这种情况下，NoSQL没有功能来确保更新。

4. Schema设计的灵活性

由于 NoSQL不需要 schema，所以在某些情况下也是独一无二的。在以前的数据库模型中，程序员必须考虑所有需要的列能够扩展，能够适应每行的数据条目。在 NoSQL下，条目可以有多种字符串或者完全没有。这种灵活性允许程序员迅速增加数据。但是，也可能存在问题，比如当有多个团体在同一项目上工作时，或者新的开发团队接手一个项目时。开发人员能够自由地修改数据库，也可能会不断实现各种各样的密钥对。

5.资源密集型

NoSQL数据库通常比关系数据库更加资源密集。他们需要更多的 CPU储备和 RAM分配。出于这个原因，大多数共享主机公司都不提供 NoSQL。你必须注册一个 VPS或运行自己的专用服务器。另一方面，SQL主要是在服务器上运行。初期的工作都很顺利，但随着数据库需求的增加，硬件必须扩大。单个大型服务器比多个小型服务器昂贵得多，价格呈指数增长。所以在这种企业计算场景下，使用 NoSQL更为划算，例如那些由谷歌和 Facebook使用的服务器。

软件性能指标有哪些

问题一：衡量一个软件系统性能的常见指标有哪些我参考了下博云软件的观点得出以下几点技术性能指标：1、系统平均无故障时间，2、系统联机响应时间、处理速度和吞吐量，3、系统操作是的灵活性和方便性，4、系统加工数据的准确性，5、系统的可扩充性，6、系统的可维护性。

问题二：软件测试常见性能指标有哪些，并简述其定义 1、响应时间

响应时间指的是“系统响应时间”，定义为应用系统从发出请求开始到客户端接收到响应所消耗的时间。把它作为用户视角的软件性能的主要体现。它包括网络上的传输时间，web服务器上处理时间，APP服务器上处理时间，DB服务器上处理时间，但不包括浏览器上的内容显示时间，即“呈现时间”，这是因为呈现时间在很大程度上取决于客户端的表现。

2、最大并发用户数

有两种理解方式，一种是从业务的角度来模拟真实的用户访问，体现的是业务并发用户数，指在同一时间段内访问系统的用户数量。另一种是从服务器端承受的压力来考虑，这里的“并发用户数”指的是同时向服务器端发出请求的客户数，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数。

3、吞吐量

吞吐量是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。一般来说，吞吐量用请求数/秒或是页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或是处理的业务数/小时等单位来衡量。当然，从网络的角度来说，也可以用字节数/天来考察网络流量。对于交互式应用来说，吞吐量指标反映的是服务器承受的压力。

4、性能计数器

性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。例如，对Windows系统来说，使用内存数（Memory In Usage），进程时间（Total Process Time）等都是常见的计数器。

5、思考时间

思考时间（Think Time），也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think的函数，使得脚本在执行两个操作之间等待一段时间。

6、TPS

TPS:Transaction per second，每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。

7、HPS

点击率：HPS，每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标，WEB应用是请求―响应模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。

问题三：软件技术指标有哪些？ VOL量能指标 MACD指数平滑异同移动平均线 KDJ随机指标 RSI相对强弱指标

问题四：软件性能测试监控的关键指标有哪些性能测试对于Windows的系统资源，一般监控CPU，内存，磁盘。

问题五：常见的服务器性能指标有哪些及简要介绍当前业界常见的服务器性能指标有:

TPC-C

TPC-E

TPC-H

SPECjbb2005

SPECjEnterprise2010

SPECint2006及 SPECint_rate_2006

SPECfp2006及 SPECfp_rate_2006

SAP SD 2-Tier

LINPACK

RPE2

一、TPC(Transaction Processing Performance Council)即联机交易处理性能协会,成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标:为业界提供可信的数据库及交易处理基准测试结果,当前发布主要基准测试为:

TPC-C:数据库在线查询(OLTP)交易性能

TPC-E:数据库在线查询(OLTP)交易性能

TPC-H:商业智能/数据仓库/在线分析(OLAP)交易性能

1.TPC-C测试内容：数据库事务处理测试,模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现.正规 TPC-C测试结果发布必须提供 tpmC值,即每分钟完成多少笔 TPC-C数据库交易(TPC-C Transaction Per Minute),同时要提供性价比$/tpmC。如果把 TPC-C测试结果写成为 tpm, TPM, TPMC, TPCC均不属正规。

2.TPC-E测试内容：数据库事务处理测试，模拟一个证券交易系统。与TPC-C一样，实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现。正规TPC-E测试结果必须提供tpsE值，即每秒钟完成多少笔TPC-E数据库交易（transaction per second），同时提供$/tpsE。测试结果写成其他形式均不属正规。

对比：TPC-E测试较TPC-C测试，在测试模型搭建上增加了应用服务器层，同时增加了数据库结构的复杂性,测试成本相对降低。截止目前，TPC-E的测试结果仅公布有50种左右，且测试环境均为PC服务器和windows操作系统，并无power服务器的测试结果。除此之外，TPC官方组织并未声明TPC-E取代TPC-C，所以，说TPC-E取代TPC-C并没有根据。

问题六：软件技术指标有哪些？请问软件技术指标有哪些呢？各位大虾能否珐合工作实际描述一下？小弟在书本上看到的都是些概念性的说法。谢谢！

问题七：手机性能指标手机性能指的是什么目前主流手机配件都际几公司所定比性智能手机性能重要指标电脑依CPU频率、核数、RAM（运行内存）、ROM（手机存储）速度、GPU（显卡）性能、主屏幕像素、像素密度、摄像像素、软件情况目前业内测试软件测试手机性能关键指标

问题八：软件性能测试指标tps有哪些要求 tps一般要按二八原则满足每天交易量，

举例：被测系统一天工作窗口是8小时，处理了10万笔交易

tps>（100000×80%）/（8×3600×20%）=13.89

问题九：以下指标中哪个是衡量软件性能的指标一台计算机功能的强弱或性能的好坏，不是由某项指标来决定的，而是由它的系统结构、指令系统、硬件组成、软件配置等多方面的因素综合决定的。但对于大多数普通用户来说，可以从以下几个指标来大体评价计算机的性能。 1、CPU的运算速度。运算速度是衡量计算机性能的一项重要指标。通常所说的计算机运算速度（平均运算速度），是指每秒钟所能执行的指令条数，一般用“百万条指令／秒”（mips，Million Instruction Per Second）来描述。同一台计算机，执行不同的运算所需时间可能不同，因而对运算速度的描述常采用不同的方法。常用的有CPU时钟频率（主频）、每秒平均执行指令数(ips)等。微型计算机一般采用主频来描述运算速度，通常显示为X.X GHz。一般说来，主频越高，运算速度就越快。 2、字长。一般说来，计算机在同一时间内处理的一组二进制数称为一个计算机的“字”，而这组二进制数的位数就是“字长”。在其他指标相同时，字长越大计算机处理数据的速度就越快。现在的大多装人都装64位的了。 3、内存的容量。内存储器，也简称主存，是CPU可以直接访问的物理存储器，需要执行的程序与需要处理的数据就是存放在主存中的。内存储器容量的大小反映了计算机即时存储信息的能力。随着操作系统的升级，应用软件的不断丰富及其功能的不断扩展，人们对计算机内存容量的需求也不断提高。目前，常见的内存容量都在1GB以上了。内存容量越大，系统功能就越强大，能处理的数据量就越庞大。 4、外存储器的容量。外存储器容量通常是指硬盘容量（包括内置硬盘和移动硬盘）。外存储器容量越大，可存储的信息就越多，可安装的应用软件就越丰富。目前，硬盘容量一般为300 G至1TB，以后存储容量还会更大。以上只是一些主要性能指标。除了上述这些主要性能指标外，计算机还有其他一些指标，例如，所配置外围设备的性能指标以及所配置系统软件的情况等等。另外，各项指标之间也不是彼此孤立的，在实际应用时，应该把它们综合起来考虑，而且还要遵循“性能价格比”的原则。

问题十：app开发，比较看重的性能指标有哪些博客 app最重要的指标有九个，最重要9个的KPI指标，它们可以评估移动App应用软件是否成功。

1.用途

用户评价一款App应用时，会首先是从它的用途入手，而真正成功的App应用能够解决用户所面临的问题。除了单纯的使用外，还必须了解用户的年龄段，应用的使用频率、时间、方式等。特别的，对受众群体进行特征分析，可以估测不同受众群体使用情况，预测模型转换。了解这些问题后，可以对App应用有更深刻的见解，并且有的放矢进行资源分配，从而获得更大的利润。

2.产品终生价值

对任何一款App应用而言，经得住检验并且可靠耐用，就是对产品终生价值(LTV)最重要的评价标准。简言之，LTV是移动用户相对于非移动用户的价值。如果移动用户比非移动用户更忠诚、使用频率更高，那么这个移动策略就是切实可行的。根据不同的用途来评断“价值”，这样就可以在了解应用对不同用户的价值后，就可以明确哪些功能对用户是重要的，哪些是有待提高的。

3.保留率

一款应用软件不会一直都是最热门的，因此要延长使用寿命就必须重视保留率，特别是在第1、7、30天的保留率。如今，保留率以及成为应用软件的最大的挑战，调查显示，有65%的人会在安装3个月后停止使用。而且早期的保留率预测也能显示市场生产力。另外，应用软件排名也越来越关注保留率。对用户来说保留率是更好的指标，但是只有做的很出色才会有更高的保留率。

4.活跃用户

每个人都可以下载应用软件，但是要想让用户定期使用并不那么容易。月度活跃用户(MAU)、日活跃用户(DAU)

都是评估用户活跃度的关键指标。如果用户喜欢一款App，它们就会经常使用，甚至能到依赖的程度。只有了解这类人群的特质以及他们是如何使用的，才会创造出更受欢迎的App应用，并且把更多的客户转化为活跃客户。

5.使用时间

只打开应用软件与切实使用应用软件是有很大区别的，就像网页访问量与网页浏览时间相比一样。增加使用时间对App应用而言是非常重要的。要想使App应用更加具有用户粘性，就要让它更具吸引力，这样才会有更长的使用时间。想要开发APP可以找汉恩云推。

6.平均用户收益

如果App应用有固定的用户群那是很好的，但可能会创造一款应用软件能以其他方式获取收益。着眼大局要从平均用户收益(ARPU)入手。“收益”来自于

App应用价格、应用内置广告等等，但是当决定使用平均用户收益这个指标，那么请注意，要把的App应用放在多个渠道平台上。

GPShopper市场营销部高级经理Andrea Cohen表示，如果

只是简单的看看用户在App应用里买了些什么，并忽略他们总体花费的增长，这绝对是一个错误。根据她曾在The North

Face和bebe这两个品牌公司的经验，每年用户使用App消费比在线用户多15%，甚至能占到总体收益的25%。

7.App加载/登陆时间

的App应用需要六秒才能登陆?明确的告诉，不会有人愿意花时间用这款App应用的。时间可以说是App应用的本质，

有责任为用户提供更高效的应用加载时间。用户应用加载App应用，登陆新页面，在应用里进行购买交易，所有处理都应该是无缝完成。如果

让用户思索为什么这款App应用的加载时间这么长，他们可能已经用上了竞争对手的App了。

8.用户获取

获取新用户有一个办法，那就是研究一下现有用户是如何找到

开发的App应用的，是通过搜索，付费广告，内置推荐，还是通过口碑相传。人们会因为不同的原因寻找不同的App应用，......>>

好了，文章到此结束，希望可以帮助到大家。