前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >从Oracle到PostgreSQL:动态性能视图 vs 标准统计视图

从Oracle到PostgreSQL:动态性能视图 vs 标准统计视图

作者头像
数据和云
发布于 2019-06-11 11:00:25
发布于 2019-06-11 11:00:25
1.9K00
代码可运行
举报
文章被收录于专栏:数据和云数据和云
运行总次数:0
代码可运行

从 Oracle 到 PostgreSQL :从 Uptime 到数据库实例运行时间

Oracle数据库的性能视图几乎可以说是最引以为骄傲的功能,在那样细粒度的采样统计强度下,依然保持卓越的性能,基于这些性能数据采样之后形成的AWR,更是Oracle DBA分析数据库性能问题的最重要手段之一。

那么在誉为最接近Oracle的开源数据库PostgreSQL中,如果要诊断性能问题,又有哪些视图可以使用呢?作为Oracle DBA,在学习PostgreSQL的时候,不可避免地会将PostgreSQL和Oracle进行比较。

以下SQL命令,在mydb=#提示符下的均为在PostgreSQL中执行的,在SQL>提示符下的均为在Oracle中执行的。

先看一下在PostgreSQL中存在那些统计信息视图。PostgreSQL中数据字典的命名还是很规范的,所有统计信息基本上都以pg_stat_开头。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
mydb=# select relname from pg_class where relname like 'pg_stat_%';             relname              ---------------------------------- pg_statistic pg_stats pg_stat_all_tables pg_stat_xact_all_tables pg_stat_sys_tables pg_stat_xact_sys_tables pg_stat_user_tables pg_stat_xact_user_tables pg_statio_all_tables pg_statio_sys_tables pg_statio_user_tables pg_statio_all_indexes pg_statio_sys_indexes pg_statio_user_indexes pg_statio_all_sequences pg_statio_sys_sequences pg_statio_user_sequences pg_stat_activity pg_stat_replication pg_stat_database pg_stat_database_conflicts pg_stat_user_functions pg_stat_xact_user_functions pg_stat_archiver pg_stat_bgwriter pg_stat_all_indexes pg_stat_sys_indexes pg_stat_user_indexes pg_statistic_relid_att_inh_index(29 rows)pg_stat_activity

该视图显示了连接入一个Cluster下所有数据库的会话的统计信息,每个会话一行记录,类似于Oracle中的V$SESSION视图。

pg_stat_activity.query字段直接显示了该会话正在执行的SQL或者上次执行的SQL语句文本。在Oracle中检查一个会话正在执行的SQL语句文本,则需要通过V$SESSION和V$SQL视图Join才可以。

pg_stat_activity.pid字段直接显示了该会话在操作系统上的进程ID,这样通过top命令看到的繁忙操作系统进程,可以很简单地通过该字段定位,来作进一步的诊断。在Oracle中则需要通过V$SESSION和V$PROCESS视图Join才可以。

pg_stat_archiver

该视图始终只有一条记录,显示了负责一个cluster下所有数据库的重做日志(PostgreSQL中称为WAL file)归档进程的统计信息,记录项比较简单。last_archived_wal和last_archived_time分别显示了最近一次归档的文件名和最近一次归档时间。

类似于Oracle中的V$ARCHIVE_DEST_STATUS。由于PostgreSQL中的归档实现实在是太简单了,所以几乎跟Oracle没有太多可比性。

pg_stat_bgwriter

该视图始终只有一条记录,显示了负责一个cluster下所有数据库的后台写进程的统计信息,也就是在操作系统中看到的postgres: writer process。该进程每隔bgwriter_delay初始化参数定义的间隔(默认200ms)会唤醒,将Buffer Pool中修改过的页写入到磁盘。跟Oracle的后台进程DBWR非常相仿。

在Oracle中没有专门记录DBWR进程的性能视图,V$BGPROCESS视图也同样没有提供类似的信息,但是在V$SYSSTAT却记录了DBWR的统计信息,这部分跟pg_stat_bgwriter中记录的信息相仿。Oracle 11gR2中有超过600项的统计信息记录在V$SYSSTAT视图中。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
SQL> select NAME,VALUE from v$sysstat where upper(name) like '%DBWR%';
NAME                                                                  VALUE---------------------------------------------------------------- ----------flash cache insert skip: DBWR overloaded                                  0DBWR checkpoint buffers written                                     1564210DBWR thread checkpoint buffers written                                    0DBWR tablespace checkpoint buffers written                             2852DBWR parallel query checkpoint buffers written                            0DBWR object drop buffers written                                        324DBWR transaction table writes                                         81619DBWR undo block writes                                               485016DBWR revisited being-written buffer                                       0DBWR lru scans                                                            0DBWR checkpoints                                                       4158DBWR fusion writes                                                        0
12 rows selected.

pg_stat_database

该视图对于每个database显示一行记录,PostgreSQL中的Cluster类似于Oracle的一个Instance,一个Cluster下可以创建多个database。

该视图中记录了每个数据库提交了多少事务,回滚了多少事务,读了多少数据块,查询、插入、更新、删除了多少记录(在PostgreSQL中用Tuple这个奇怪的词表示跟Row相同的概念),产生过多少死锁。总之这是一个数据库级别相对很简单的统计信息。

但是,在Oracle中还真没有与此类似的性能视图,实际上Oracle没有一个视图简单地记录了一个Schema下面总共查询或者DML了多少条记录,但是却有DBA_TAB_MODIFICATIONS这样的视图详细记录每一张表的DML数量。查询了多少数据?可能Oracle认为这个数字是太不重要了,或者说实在是太大了,完全没必要记录。

对于事务级别的统计,同样可以在Oracle的V$SYSSTAT视图中查询包含“ROLLBACK”和“COMMIT”字样的统计值,远比PostgreSQL中记录地要更多样。

pg_stat_all_tables/pg_stat_sys_tables/pg_stat_user_tables

在PostgreSQL的统计信息视图中,all表示一个数据库下所有的表,sys表示所有的系统表,user表示所有用户创建的表,这三个配套的视图我们放在一起看。以下类似的也相同。

该视图对于每张表显示一条记录,显示了一张表上进行过多少全表扫描,多少索引扫描,查询、插入、更新、删除过多少记录,表中现在有多少记录,表的分析时间等。

在Oracle中表的分析信息存储在DBA_TABLES中,而对于每个表上DML的信息如前所述,可以从DBA_TAB_MODIFICATIONS视图中查询,而经历过怎样的IO则又可以从V$SEGSTAT视图中查询。好吧,实际上,在Oracle中根本也不关注一个表上读取过多少记录这样的数字,所以在PostgreSQL中但凡跟Tuple相关的统计值在Oracle中都找不到对应的记录。对于Oracle来说,IO都以Block为单位,所以读取一条记录还是读取一个块,在IO消耗上没有区别。而至于对于返回记录数等的优化,则归结到SQL层面,那则可以通过V$SQLSTAT等一系列视图作更详细的分析。

Oracle在视图层面从Table概念和Segment概念上做了详细的区分,看似复杂,实际清晰而且详尽,而在PostgreSQL中则混为一谈了,当然在PostgreSQL中通过后面会谈到的pg_statio_系列视图又对表和索引上的IO统计信息进行了记录。

pg_stat_xact_all_tables/pg_stat_xact_sys_tables/pg_stat_xact_user_tables

该系列视图与上述相仿,只是增加了xact前缀,xact表示transaction,统计的是当前会话对于表操作的信息,这部分信息通常还没有更新到pg_stat_all_tables视图中。

在Oracle中由于性能数据的抓取粒度是如此之细,所以并未区分当前会话还是已经结束的会话,要知道V$SEGSTAT中的信息几乎是real-time在更新的。所以,在Oracle中无需此类视图。

pg_stat_all_indexes/pg_stat_sys_indexes/pg_stat_user_indexes

该视图对于每个索引显示一条记录,显示的信息如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
mydb=# select * from pg_stat_all_indexes where relname='t1';    relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch -------+------------+------------+---------+--------------+----------+--------------+--------------- 24604 |      24613 | public     | t1      | t1_index     |        3 |        58960 |         47817(1 row)

可见记录的信息非常简单,就是一个索引上进行过多少次扫描,通过这个索引扫描读取了多少记录,返回了多少记录。

在Oracle中,由于索引是Segment的一种,因此类似的统计信息都可以从V$SEGSTAT中获取。

pg_statio_all_tables/pg_statio_sys_tables/pg_statio_user_tables

pg_statio_all_indexes/pg_statio_sys_indexes/pg_statio_user_indexes

这两部分放在一起描述,具有statio前缀的视图显示的是表或索引在数据块级别的IO统计信息,而stat前缀的视图(如前面看到的)则显示的是表或索引在记录级别的IO统计信息。以pg_statio_all_indexes为例:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
mydb=# select * from pg_statio_all_indexes where relname='t1'; relid | indexrelid | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit -------+------------+------------+---------+--------------+---------------+-------------- 24604 |      24613 | public     | t1      | t1_index     |           150 |          453(1 row)

显示了读取过多少个数据块,这些读取中有多少数据块是直接命中缓存的。

在Oracle中是我们提到了多次的V$SEGSTAT视图。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
pg_statio_all_sequences/pg_statio_sys_sequences/pg_statio_user_sequences

PostgreSQL对sequence上的IO独立给出了一系列视图,PostgreSQL中的sequence跟Oracle中的sequence概念基本一致,为存储序列号等的字段生成序列值。

该视图对于每个序列显示一条记录,显示的信息如下:

mydb=# select * from pg_statio_all_sequences;

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
 relid | schemaname |   relname    | blks_read | blks_hit -------+------------+--------------+-----------+---------- 24614 | public     | users_id_seq |         1 |        3(1 row)

非常简单,显示了读取过多少个数据块,多少数据块的读取是直接命中缓存的。

在Oracle中,由于序列是系统自身对象的一部分,因此如果要诊断跟序列相关的问题,通常要依赖等待事件,比如“enq: SQ – contention”或者“row cache lock”,另外在V$ROWCACHE视图中存储了与序列相关的整体统计值。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
SQL> select PARAMETER,GETS,GETMISSES from v$rowcache where PARAMETER='dc_sequences';
PARAMETER                              GETS  GETMISSES-------------------------------- ---------- ----------dc_sequences                           2145         54pg_stat_user_functions/pg_stat_xact_user_functions

有xact前缀和没有前缀的区别在前面描述pg_stat_xact_all_tables系列视图时已经提过,因此放在一起描述。

该视图对于每个指定要跟踪的用户自定义函数显示一条记录,这通过初始化参数track_functions来控制,默认不开启任何跟踪,视图结构如下:

mydb=# \d pg_stat_user_functions

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
 View "pg_catalog.pg_stat_user_functions"   Column   |       Type       | Modifiers ------------+------------------+----------- funcid     | oid              |  schemaname | name             |  funcname   | name             |  calls      | bigint           |  total_time | double precision |  self_time  | double precision | 

calls字段记录了对于用户函数进行过多少次调用;

total_time字段记录了运行这个函数总共消耗了多长时间(毫秒为单位),包括调用其它函数的时间;

self_time字段记录了运行这个函数本身消耗了多长时间(毫秒为单位),不包括调用其它函数的时间。

Oracle中没有类似的视图,Oracle的关于函数或者存储过程的执行统计信息,都是详细到其中每一条SQL语句的,实际上如果像PostgreSQL这样能有一个函数或者存储过程级别的性能统计值,也是极好的。

pg_stat_replication

在设置了复制的环境中,该视图对于每个WAL sender进程(WAL sender进程负责将本机的重做日志发送到远端复制环境)显示一条记录,显示内容大致如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
postgres=# select pid,application_name,client_addr,state,sent_location,replay_location from pg_stat_replication;  pid  | application_name |  client_addr   |   state   | sent_location | replay_location -------+------------------+----------------+-----------+---------------+----------------- 27855 | walreceiver      | 192.168.56.105 | streaming | 0/50188CE8    | 0/50188CE8(1 row)

每个视图中都能直接显示操作系统进程ID,实在是很方便的事情。在操作系统上可以直接查看pid=27855的进程。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[root@pg1-enmotech-com ~]# ps -ef|grep 2785|grep postgrespostgres 27855  1119  0 00:45 ?        00:00:00 postgres: wal sender process postgres 192.168.56.105(57046) streaming 0/50188CE8

从操作系统的ps命令中看到实际上已经将视图中的这些字段内容更新到了该进程描述中,在进程描述中会更新一些很有用的信息(比如server进程的状态,是等待还是空闲等),这也是PostgreSQL非常方便的一个地方。

在Oracle中与PostgreSQL的复制相类似的功能是Physical Data Guard,在DG中重做日志的传输是通过归档路径来完成的,因此类似的信息可以从V$ARCHIVE_DEST_STATUS和V$MANAGED_STANDBY视图中获取。

pg_stat_database_conflicts

该视图仅对于Standby数据库有效,对于每个数据库显示一条记录,显示内容如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
postgres=# select * from pg_stat_database_conflicts; datid |  datname  | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock -------+-----------+------------------+------------+----------------+-----------------+----------------     1 | template1 |                0 |          0 |              0 |               0 |              0 13051 | template0 |                0 |          0 |              0 |               0 |              0 13056 | postgres  |                0 |          0 |              0 |               0 |              0 16384 | mydb      |                0 |          0 |              0 |               0 |              0 24587 | mydb_bak  |                0 |          0 |              0 |               0 |              0(5 rows)

由于PostgreSQL的机制,在备库上的查询会跟一些诸如删除表空间、删除数据库、vacuum cleanup的操作相冲突,为了不让备库的WAL replay操作延时太久,PostgreSQL内建了强制取消当前备库上运行的查询以避免跟应用重做日志这样更重要的动作相冲突的机制。而该视图则是记录由于不同原因取消掉的查询的次数。对于每个数据库显示一条记录。

Oracle中不会出现这样的问题,因此也没有相应的视图。

总结


当然,PostgreSQL中除了这些统计信息视图之外,还有不少类似于pg_tables,pg_users这样与Oracle中的数据字典视图相仿的视图,另外还有比如pg_locks这样用于记录锁信息的诊断视图。但是仅仅用一篇文章的长度就可以将所有的统计信息视图全部介绍完毕,PostgreSQL确实是很简洁的数据库。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-06-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数据和云 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
高通要哭了!传苹果将砸10亿美元收购英特尔手机基带芯片业务
据知情人士透露,苹果公司正在就收购英特尔公司的智能手机基带芯片业务进行高级谈判,此举对于苹果掌控其核心部件至关重要。
新智元
2019/07/26
3600
高通要哭了!传苹果将砸10亿美元收购英特尔手机基带芯片业务
防患高通效仿华为,苹果10亿美元收购英特尔手机基带业务!打造5G备胎,加强自主可控
有人说这是苹果自研基带之心不死,也能当作苹果为5G种下备胎计划,或者会是苹果加强关键供应链自主可控的重要一步。
量子位
2019/07/30
4290
英特尔彻底退出5G基带芯片市场:相关业务将出售给两家中企
3月27日消息,据外媒More Than Moore报道,继2019年将与手机相关的5G基带业务出售给了苹果之后,近期英特尔又计划将与笔记本电脑业务相关的5G基带技术转让给两家中国企业——联发科和广和通,交易预计在5月底前完成,英特尔将在7月底前彻底退出5G基带市场。
芯智讯
2023/04/11
3850
英特尔彻底退出5G基带芯片市场:相关业务将出售给两家中企
英特尔宣布完成向苹果出售调制解调器业务的交易
今天,英特尔正式宣布,它已经完成了以10亿美元将智能手机调制解调器业务出售给苹果的交易,其中包括知识产权、设备以及约2200名英特尔员工。
镁客网
2019/12/05
3510
高通与苹果宣布“复合”,英特尔黯然退场 | 极客头条
为期两年的苹果高通“诉讼之争”经历了各种推波助澜愈演愈烈,俨然到了最为关键的白热化阶段,没成想,在刚刚正式进入美国司法庭审环节的两天后却被强势叫停了!
AI科技大本营
2019/05/06
3800
高通与苹果宣布“复合”,英特尔黯然退场 | 极客头条
手机基带芯片的故事
美国时间2019年4月16日,英特尔宣布放弃5G基带Modem业务。iPhone回归高通的消息放出,高通股票一小时内暴涨近25%。
镁客网
2019/05/15
6570
手机基带芯片的故事
苹果为解决信号问题,巨资收购英特尔基带产品线,这下高通尴尬了
美国时间周四(7月25日),苹果公司宣布将以10亿美元(合计人民币69亿元)收购英特尔智能手机调制解调器部门的多数股权,预计预计该交易将在第四季度完成。届时苹果公司将获得英特尔该部门超过2200名工程师、调制解调器知识产权和其他相关设备。
悲了伤的白犀牛
2019/07/30
3640
苹果或将采用高通屏下指纹方案,5G iPhone基带由三星、高通共同提供
据台湾媒体今日报道,苹果未来的iPhone手机可能将会采用高通独家的超声波屏幕指纹识别方案。
镁客网
2019/05/07
4950
苹果或将采用高通屏下指纹方案,5G iPhone基带由三星、高通共同提供
三战三败,英特尔的移动困局
最近是全球半导体企业的多事之秋。摩尔定律的践行者英特尔,在今年于移动业务上“迎来”了第三次失败。三战三败移动市场的英特尔到底陷入了什么怪圈?
镁客网
2019/05/23
5700
禁售iPhone再升级!高通寻求美国禁止进口苹果,5G大战英特尔躺枪
昨天,高通说服美国贸易委员会(ITC),考虑对使用英特尔芯片的iPhone手机下进口禁令,试图让苹果低头。
新智元
2018/12/27
4440
禁售iPhone再升级!高通寻求美国禁止进口苹果,5G大战英特尔躺枪
“果粉”不用担心手机信号差了!外媒称苹果2020年新款iPhone将使用高通基带
自从苹果公司与高通交恶,抛弃使用高通基带之后,iPhone手机信号差就成为消费者“吐槽”的核心点。不过明年“果粉”或许不用担心这一问题了。今日据外媒报道,2020年新款iPhone将会换回高通基带,全面取消当前使用的英特尔基带。
镁客网
2019/11/28
4940
困难重重,苹果将放弃自研5G基带芯片?
11月30日消息,外媒wccftech援引消息人士报道称,熟悉苹果5G基带芯片部门的消息人士表示,苹果公司将停止5G基带芯片的开发。这代表着苹果公司在基带芯片领域的努力无法获得回报,并认为关闭该部门是合适的。
芯智讯
2023/12/04
1820
困难重重,苹果将放弃自研5G基带芯片?
2026年才能推出?苹果自研5G基带芯片再度延后!
11月17日消息,据彭博社引述知情人士消息报道称,苹果现在可能无法实现在2025年春季前开发出5G基带芯片的目标,并进一步地将发布时间延迟到了2025年底或2026年初,这也是苹果与高通续约的最后一年。
芯智讯
2023/11/20
1760
2026年才能推出?苹果自研5G基带芯片再度延后!
苹果与高通复合,英特尔退出,5G赛场谁是顶级玩家?
今日凌晨,苹果和高通联合发布声明,表示双方已经达成协议,放弃在全球层面的所有法律诉讼,签署至少六年的专利许可协议和多年的芯片组供应协议。该协议已在 2019 年 4 月 1 日生效,并有两年的延期选项。
大数据文摘
2019/04/25
4250
苹果与高通复合,英特尔退出,5G赛场谁是顶级玩家?
“芯片门”持续发酵,苹果或选择英特尔代工iPhone7芯片
根据苹果发布的数据,iPhone6s发布后刷新了此前历代iPhone的出货记录,首周销量就突破1000万部。但最近爆出的“芯片门”事件使这家智能手机巨头受到越来越多消费者的质疑,持续下滑的销量迫使它不
镁客网
2018/05/25
3720
苹果欲收购英特尔调制解调器业务,加快芯片自研速度
据外媒报道,苹果正在和英特尔洽谈,意欲收购英特尔位于德国的调制解调器芯片业务,从而加快其自研芯片的步伐。
镁客网
2019/06/20
4070
苹果欲收购英特尔调制解调器业务,加快芯片自研速度
【终结者出场】英特尔拟收购博通,高通究竟落入谁手?
博通收购高通案又有了新变局:担心博通与高通的合并将对其构成威胁,英特尔正在考虑收购博通。这场集合了态度反复、政府介入、董事长离职、国家安全几乎所有商业元素的世纪收购案越来越精彩,还有没有新的“门口野蛮人”?我们拭目以待。 博通收购高通一案,变数又起。 据《华尔街日报》周五的一则报道显示,个人电脑和服务器芯片公司英特尔正在考虑收购博通,原因是英特尔担心博通与高通的合并将对其构成威胁,“如果博通成功竞购高通公司的股份,它可能会收购博通公司。”消息人士称。 对此,英特尔在一份声明中表示,它不会评论与收购有
新智元
2018/03/13
7430
【终结者出场】英特尔拟收购博通,高通究竟落入谁手?
那些营收超百亿美元的半导体厂商之四 —— 走下神坛的英特尔
脱口秀艺人杨笠在广告中为英特尔笔记本电脑产品代言:“英特尔的眼光太高了,比我挑对象的眼光都高。”广告发布后,不少男网友发文抵制,表示今后弃用英特尔产品。很快英特尔删除了相关广告,并在22日通过媒体做出回应。
AI 电堂
2021/04/16
4510
那些营收超百亿美元的半导体厂商之四 —— 走下神坛的英特尔
博通要花1000亿美元收购高通,半导体史上最大收购案更像是炒作
据美国彭博社引述知情人士称,博通正在和顾问伙伴洽谈这一收购,收购计划将在未来几天之内宣布。 据彭博社和《华尔街日报》报道,美国半导体公司博通拟斥资1000亿美元收购另外一家半导体巨头高通,如果这笔收购最终能够达成,那将是整个半导体行业历史上最大的一笔收购案。其中,博通计划以现金加股票的方式,按照每股70美元的价格收购高通,据美国彭博社引述知情人士称,博通正在和顾问伙伴洽谈这一收购,收购计划将在未来几天之内宣布。 听到这条消息,镁客君第一反应是居然是高通被收购,而不是高通收购其他公司。收购消息爆出来以后,高通
镁客网
2018/05/30
4120
半导体老牌贵族做不好的移动处理器,为什么华为、高通可以无往不利
如今高通、海思、三星、联发科以及展锐,圈出了各自的一亩三分地,并且以5G为中心,展开新一轮的竞争。
镁客网
2019/06/20
9090
半导体老牌贵族做不好的移动处理器,为什么华为、高通可以无往不利
推荐阅读
高通要哭了!传苹果将砸10亿美元收购英特尔手机基带芯片业务
3600
防患高通效仿华为,苹果10亿美元收购英特尔手机基带业务!打造5G备胎,加强自主可控
4290
英特尔彻底退出5G基带芯片市场:相关业务将出售给两家中企
3850
英特尔宣布完成向苹果出售调制解调器业务的交易
3510
高通与苹果宣布“复合”,英特尔黯然退场 | 极客头条
3800
手机基带芯片的故事
6570
苹果为解决信号问题,巨资收购英特尔基带产品线,这下高通尴尬了
3640
苹果或将采用高通屏下指纹方案,5G iPhone基带由三星、高通共同提供
4950
三战三败,英特尔的移动困局
5700
禁售iPhone再升级!高通寻求美国禁止进口苹果,5G大战英特尔躺枪
4440
“果粉”不用担心手机信号差了!外媒称苹果2020年新款iPhone将使用高通基带
4940
困难重重,苹果将放弃自研5G基带芯片?
1820
2026年才能推出?苹果自研5G基带芯片再度延后!
1760
苹果与高通复合,英特尔退出,5G赛场谁是顶级玩家?
4250
“芯片门”持续发酵,苹果或选择英特尔代工iPhone7芯片
3720
苹果欲收购英特尔调制解调器业务,加快芯片自研速度
4070
【终结者出场】英特尔拟收购博通,高通究竟落入谁手?
7430
那些营收超百亿美元的半导体厂商之四 —— 走下神坛的英特尔
4510
博通要花1000亿美元收购高通,半导体史上最大收购案更像是炒作
4120
半导体老牌贵族做不好的移动处理器,为什么华为、高通可以无往不利
9090
相关推荐
高通要哭了!传苹果将砸10亿美元收购英特尔手机基带芯片业务
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档