子查询in、exists、not in、not exists一点补充
子查询的一点补充，之前小鱼写过一篇关于in和exists性能的分析 http://www.dbaxiaoyu.com/archives/2012 其实这个都是子查询，而在最新的oracle 11g中，in和exists基本不太可能产生变化，因为11g的cbo不仅可以unnest展开子查询为表连接，还新增了null-aware
子查询的一点补充，之前小鱼写过一篇关于in和exists性能的分析 http://www.dbaxiaoyu.com/archives/2012
其实这个都是子查询，而在最新的oracle 11g中，in和exists基本不太可能产生变化，因为11g的cbo不仅可以unnest展开子查询为表连接，还新增了null-aware anti join的算法，由于in对null敏感。
而在oracle 11g之前，如果关联列上面没有not null的约束，那么此时not in的写法就无法对子查询进行展开，一般我们会看见形如下面的filter执行计划：
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Tue May 13 10:14:42 2014
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> set autotrace traceonly;
SQL> set linesize 140;
SQL> select * from table02 where object_id not in (select object_id from table01);
Execution Plan
----------------------------------------------------------
Plan hash value: 206984988
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 52376 | 9053K| 3430 (1)| 00:00:42 |
|* 1 | FILTER | | | | | |
| 2 | TABLE ACCESS FULL| TABLE02 | 52408 | 9058K| 154 (2)| 00:00:02 |
|* 3 | TABLE ACCESS FULL| TABLE01 | 50979 | 647K| 2 (0)| 00:00:01 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "TABLE01" "TABLE01"
WHERE LNNVL("OBJECT_ID"
:B1)))
3 - filter(LNNVL("OBJECT_ID"
:B1))
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
14 recursive calls
0 db block gets
17188464 consistent gets
0 physical reads
0 redo size
1403 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
而这个执行成本往往非常高，而如果我们添加一个not null的约束，或者改写下sql或者添加not null约束来取消这个特别消耗成本的filter
1）改写成minus写法：
SQL> select * from table02 a minus
2 select * from table02 where object_id in (select object_id from table01);
Execution Plan
----------------------------------------------------------
Plan hash value: 1546480765
--------------------------------------------------------------------------------
--------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Ti
me |
--------------------------------------------------------------------------------
--------
| 0 | SELECT STATEMENT | | 52408 | 18M| | 4674 (54)| 00
:00:57 |
| 1 | MINUS | | | | | |
|
| 2 | SORT UNIQUE | | 52408 | 9058K| 21M| 2189 (1)| 00
:00:27 |
| 3 | TABLE ACCESS FULL | TABLE02 | 52408 | 9058K| | 154 (2)| 00
:00:02 |
| 4 | SORT UNIQUE | | 52409 | 9724K| 19M| 2484 (1)| 00
:00:30 |
|* 5 | HASH JOIN | | 52409 | 9724K| | 308 (2)| 00
:00:04 |
| 6 | TABLE ACCESS FULL| TABLE01 | 53662 | 681K| | 153 (1)| 00
:00:02 |
| 7 | TABLE ACCESS FULL| TABLE02 | 52408 | 9058K| | 154 (2)| 00
:00:02 |
--------------------------------------------------------------------------------
--------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - access("OBJECT_ID"="OBJECT_ID")
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
13 recursive calls
0 db block gets
2296 consistent gets
0 physical reads
0 redo size
1403 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
1 rows processed
这里逻辑读降了好多，虽然cost感觉好像比上述的filter执行成本还要大，但是sql的相应时间确明显比filter好太多了。
2 给子表和主表增加not null的约束:
SQL> alter table table01 modify object_id not null;
Table altered.
SQL> alter table table02 modify object_id not null;
Table altered.
SQL> select * from table02 where object_id not in (select object_id from table01);
Execution Plan
----------------------------------------------------------
Plan hash value: 35610947
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 190 | 308 (2)| 00:00:04 |
|* 1 | HASH JOIN RIGHT ANTI| | 1 | 190 | 308 (2)| 00:00:04 |
| 2 | TABLE ACCESS FULL | TABLE01 | 53662 | 681K| 153 (1)| 00:00:02 |
| 3 | TABLE ACCESS FULL | TABLE02 | 52408 | 9058K| 154 (2)| 00:00:02 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("OBJECT_ID"="OBJECT_ID")
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
265 recursive calls
0 db block gets
1557 consistent gets
0 physical reads
0 redo size
1403 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
6 sorts (memory)
0 sorts (disk)
1 rows processed
注意这里需要对子表和主表都添加not null约束，不然在10g的cbo下，oracle还是会选择性能较差的filter。
我们看看各个版本优化器对于in和exists处理的变化（Table01和table02的object_id上都有not null约束）
SQL> select /*+ optimizer_features_enable('8.1.7')*/* from table02 b where exists (select 1 from table01 a where a.object_id=b.object_id);
50075 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 206984988
--------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2806 | 485K| 67 |
|* 1 | FILTER | | | | |
| 2 | TABLE ACCESS FULL| TABLE02 | 2806 | 485K| 67 |
|* 3 | TABLE ACCESS FULL| TABLE01 | 561 | 7293 | 67 |
--------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( EXISTS (SELECT 0 FROM "TABLE01" "A" WHERE
"A"."OBJECT_ID"=:B1))
3 - filter("A"."OBJECT_ID"=:B1)
Note
-----
- cpu costing is off (consider enabling it)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
17191469 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
50075 rows processed
SQL> select /*+ optimizer_features_enable('8.1.7')*/* from table02 b where not
exists (select 1 from table01 a where a.object_id=b.object_id);
Execution Plan
----------------------------------------------------------
Plan hash value: 206984988
--------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2806 | 485K| 67 |
|* 1 | FILTER | | | | |
| 2 | TABLE ACCESS FULL| TABLE02 | 2806 | 485K| 67 |
|* 3 | TABLE ACCESS FULL| TABLE01 | 561 | 7293 | 67 |
--------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( NOT EXISTS (SELECT 0 FROM "TABLE01" "A" WHERE
"A"."OBJECT_ID"=:B1))
3 - filter("A"."OBJECT_ID"=:B1)
Note
-----
- cpu costing is off (consider enabling it)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
17191469 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select /*+ optimizer_features_enable('8.1.7')*/* from table02 b where objec
t_id in (select object_id from table01 a);
50075 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2067593584
-------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 31M| 5705M| | 469 |
|* 1 | HASH JOIN | | 31M| 5705M| | 469 |
| 2 | VIEW | VW_NSO_1 | 56115 | 712K| | 251 |
| 3 | SORT UNIQUE | | 56115 | 712K| 2216K| 251 |
| 4 | TABLE ACCESS FULL| TABLE01 | 56115 | 712K| | 67 |
| 5 | TABLE ACCESS FULL | TABLE02 | 56115 | 9699K| | 67 |
-------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("OBJECT_ID"="$nso_col_1")
Note
-----
- cpu costing is off (consider enabling it)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4684 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
50075 rows processed
SQL> select /*+ optimizer_features_enable('8.1.7')*/* from table02 b where objec
t_id not in (select object_id from table01 a);
Execution Plan
----------------------------------------------------------
Plan hash value: 206984988
--------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2806 | 485K| 67 |
|* 1 | FILTER | | | | |
| 2 | TABLE ACCESS FULL| TABLE02 | 2806 | 485K| 67 |
|* 3 | TABLE ACCESS FULL| TABLE01 | 561 | 7293 | 67 |
--------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( NOT EXISTS (SELECT 0 FROM "TABLE01" "A" WHERE
"OBJECT_ID"=:B1))
3 - filter("OBJECT_ID"=:B1)
Note
-----
- cpu costing is off (consider enabling it)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4684 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
这里看出在8i的优化器模式下，in的子查询被展开为表连接了，其余的not in、exists、not exists的子查询并不被选择展开为表连接，而是采用一种filter的关联方式，虽然这里的执行成本初看来filter的cost更小，但是sq的相应时间消耗资源的比例确实天壤之别，很多情况我们并不能以cost值去衡量这个sql性能。
SQL> select /*+ optimizer_features_enable('9.2.0')*/* from table02 b where exis
ts (select 1 from table01 a where a.object_id=b.object_id);
50075 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 268410134
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 50075 | 5183K| | 236 |
|* 1 | HASH JOIN SEMI | | 50075 | 5183K| 5136K| 236 |
| 2 | TABLE ACCESS FULL | TABLE02 | 50076 | 4547K| | 68 |
| 3 | VIEW | VW_SQ_1 | 50075 | 635K| | 68 |
| 4 | TABLE ACCESS FULL| TABLE01 | 50075 | 244K| | 68 |
-----------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("OBJECT_ID"="B"."OBJECT_ID")
Note
-----
- cpu costing is off (consider enabling it)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4684 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
50075 rows processed
SQL> select /*+ optimizer_features_enable('9.2.0')*/* from table02 b where not e
xists (select 1 from table01 a where a.object_id=b.object_id);
Execution Plan
----------------------------------------------------------
Plan hash value: 2991049530
----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5629 | 1044K| | 324 |
|* 1 | HASH JOIN ANTI | | 5629 | 1044K| 10M| 324 |
| 2 | TABLE ACCESS FULL| TABLE02 | 58373 | 9M| | 68 |
| 3 | TABLE ACCESS FULL| TABLE01 | 52744 | 669K| | 68 |
----------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("A"."OBJECT_ID"="B"."OBJECT_ID")
Note
-----
- cpu costing is off (consider enabling it)
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4684 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select /*+ optimizer_features_enable('9.2.0')*/* from table02 b where objec
t_id in (select object_id from table01 a)；
Execution Plan
----------------------------------------------------------
Plan hash value: 1361234999
------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 50075 | 5183K| | 236 |
|* 1 | HASH JOIN SEMI | | 50075 | 5183K| 5136K| 236 |
| 2 | TABLE ACCESS FULL | TABLE02 | 50076 | 4547K| | 68 |
| 3 | VIEW | VW_NSO_1 | 50075 | 635K| | 68 |
| 4 | TABLE ACCESS FULL| TABLE01 | 50075 | 244K| | 68 |
------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("OBJECT_ID"="$nso_col_1")
Note
-----
- cpu costing is off (consider enabling it)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4684 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
50075 rows processed
SQL> select /*+ optimizer_features_enable('9.2.0')*/* from table02 b where objec
t_id not in (select object_id from table01 a);
Execution Plan
----------------------------------------------------------
Plan hash value: 2991049530
----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5629 | 1044K| | 324 |
|* 1 | HASH JOIN ANTI | | 5629 | 1044K| 10M| 324 |
| 2 | TABLE ACCESS FULL| TABLE02 | 58373 | 9M| | 68 |
| 3 | TABLE ACCESS FULL| TABLE01 | 52744 | 669K| | 68 |
----------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("OBJECT_ID"="OBJECT_ID")
Note
-----
- cpu costing is off (consider enabling it)
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4684 consistent gets
0 physical reads
0 redo size
2569714 bytes sent via SQL*Net to client
37210 bytes received via SQL*Net from client
3340 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
看出在9i优化器环境下，in和exists都被展开为表连接，此时cbo走的hash join的连接方式。
由于主表和子表的object_id上有not null的约束，所以这里not in和not exists执行计划也都相同，对于关联数据较多的sql，hash join往往比nested loop高效很多。
oracle 10g的优化器对于in、exists、not in和not exists区别并不大，到了11g的优化器，新增了null aware anti join算法，此时并不需要表中有not null约束，也能走hash join的连接方式。
关于in、exists、not in和not exists一直是很多朋友纠结的问题，小鱼这里简单总结下：
在oracle 8I下，in是可以展开为表连接的，而not in、exists、not exists会选择filter执行计划，如果被驱动表没有高效索引，驱动表数据返回较多，这个执行计划往往存在很严重的性能问题
在oracle 9I到oracle 10g下，in和exists没有多大性能的区别，而not in和not exists则可能有所区别，主要看关联列是否有not null约束，如果没有也只能走filter的执行计划，而有则会选择hash join和filter的中优秀的执行方式
在oracle 11g下，由于新增了null-aware anti join的算法，in和exists基本没有区别了，既可以走hash join也可以走filter。
从此in、exists、not in、not exists的经典问题可能并不绝对了，虽然优化器有诸多的缺陷，但是cbo确实在不断的改进自己，这个是值得庆幸的！
而现在我们来看看返回结果上有什么区别：
SQL> select * from t01;
ID NAME
---------- ----------
1 xiaoyu
2 xiaobai
3
SQL> select * from t02;
ID NAME
---------- ----------
10 xiaoyu
20 xiaotian
SQL> select * from t01 where t01.name in (select name from t02);
ID NAME
---------- ----------
1 xiaoyu
SQL> select * from t01 where exists (select 1 from t02 where t01.name=t02.name);
ID NAME
---------- ----------
1 xiaoyu
来看看not in和not exists：
SQL> select * from t01 where t01.name not in (select name from t02);
ID NAME
---------- ----------
2 xiaobai
SQL> select * from t01 where not exists (select 1 from t02 where t01.name=t02.na
me);
ID NAME
---------- ----------
3
2 xiaobai
看出这里的子查询中in和exists返回结果没有区别，not in的只返回一行数据，而not exists确返回了两行数据，其实我们应该是希望返回两行数据的，那么如果我们再t02表上面添加一个name null的rows来看看
SQL> insert into t02 values(30,null);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from t01 where name in (select name from t02);
ID NAME
---------- ----------
1 xiaoyu
SQL> select * from t01 where exists (select 1 from t02 where t01.name=t02.name);
ID NAME
---------- ----------
1 xiaoyu
SQL> select * from t01 where name not in (select name from t02);
no rows selected
SQL> select * from t01 where not exists (select 1 from t02 where t01.name=t02.na
me);
ID NAME
---------- ----------
3
2 xiaobai
这里看出in和exists对于null处理没有变化，但是not in和not exists就不同了，not exists对于子表的null会直接略掉，也就是认为满足这个not exists的条件，而not in对于子表的null是敏感的，换句话说只要子表有null值，则not in不返回任何结果集。
关于in和exists补充就到此为止了，话说最近手头正有个子查询不展开的案例，该走hash join的走的是filter，整理完后会与大家分享！
原文地址：子查询in、exists、not in、not exists一点补充, 感谢原作者分享。
熱AI工具
Undresser.AI Undress
人工智慧驅動的應用程序，用於創建逼真的裸體照片
AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。
Undress AI Tool
免費脫衣圖片
Clothoff.io
AI脫衣器
Video Face Swap
使用我們完全免費的人工智慧換臉工具，輕鬆在任何影片中換臉！
熱門文章
熱工具
記事本++7.3.1
好用且免費的程式碼編輯器
SublimeText3漢化版
中文版，非常好用
禪工作室 13.0.1
強大的PHP整合開發環境
Dreamweaver CS6
視覺化網頁開發工具
SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)
12306怎麼查詢歷史購票紀錄 查看歷史購票紀錄的方法
Mar 28, 2024 pm 03:11 PM
12306訂票app下載最新版是一款大家非常滿意的出行購票軟體，想去哪裡就去那裡非常方便，軟體內提供的票源非常多，只需要通過實名認證就能在線購票，所有用戶的出行車票機票都可以輕鬆買到，享受不同的優惠折扣。還能提前開啟預約搶票，預約飯店、專車接送都是可以的，有了它想去哪裡就去那裡一鍵購票，出行更加簡單方便，讓大家的出行體驗更舒服，現在小編在線詳細為12306用戶帶來查看歷史購票記錄的方法。 1.打開鐵路12306，點擊右下角我的，點擊我的訂單 2.在訂單頁面點擊已支付。 3.在已支付頁
學信網如何查詢自己的學歷
Mar 28, 2024 pm 04:31 PM
學信網如何查詢自己的學歷？在學信網中是可以查詢到自己的學歷，很多用戶都不知道如何在學信網中查詢到自己的學歷，接下來就是小編為用戶帶來的學信網查詢自己學歷方法圖文教程，感興趣的用戶快來一起看看吧！學信網使用教程學信網如何查詢自己的學歷一、學信網入口：https://www.chsi.com.cn/二、網站查詢：第一步：點選上方學信網位址，進入首頁點選【學歷查詢】；第二步：在最新的網頁中點選如下圖箭頭所示的【查詢】；第三步：之後在新頁面點選【的登陸學信檔案】；第四步：在登陸頁面輸入資料點選【登陸】；
MySQL與PL/SQL的異同比較
Mar 16, 2024 am 11:15 AM
MySQL與PL/SQL是兩種不同的資料庫管理系統，分別代表了關係型資料庫和過程化語言的特性。本文將比較MySQL和PL/SQL的異同點，並附帶具體的程式碼範例進行說明。 MySQL是一種流行的關聯式資料庫管理系統，採用結構化查詢語言(SQL)來管理和操作資料庫。而PL/SQL是Oracle資料庫特有的過程化語言，用於編寫預存程序、觸發器和函數等資料庫物件。相同
如何使用Oracle 查詢表是否被鎖？
Mar 06, 2024 am 11:54 AM
標題：如何使用Oracle查詢表格是否被鎖定？在Oracle資料庫中，表鎖是指當一個事務正在對錶執行寫入操作時，其他事務想要對該表執行寫入操作或對表進行結構改變（如增加列、刪除行等）時會被阻塞。在實際開發過程中，我們經常需要查詢表格是否被鎖，以便更好地排除和處理相關問題。本文將介紹如何使用Oracle語句查詢表格是否被鎖，並給出具體的程式碼範例。要查詢表是否被鎖，我們
蘋果手機怎麼查詢啟動日期
Mar 08, 2024 pm 04:07 PM
使用蘋果手機想要查詢啟動日期，最好的方法是透過手機中的序號來查詢，也可以透過存取蘋果的官網來進行查詢，透過連接電腦查詢，下載第三方軟體查詢。蘋果手機怎麼查詢啟動日期答：序號查詢，蘋果官網查詢，電腦查詢，第三方軟體查詢1、用戶最好的方式就是知道自己手機的序號，開啟設定通用關於本機就可以看到序號。 2.使用序號不僅可以知道自己手機的啟動日期，還可以查看手機版本，手機產地，手機出廠日期等。 3.用戶訪問蘋果的官網找到技術支持，找到頁面底部的服務和維修欄目，裡面查看iPhone的激活信息。 4.用戶
Discuz資料庫位置查詢技巧分享
Mar 10, 2024 pm 01:36 PM
論壇是網路上非常常見的網站形式之一，它為使用者提供了一個分享資訊、交流討論的平台。而Discuz是一款常用的論壇程序，相信很多站長都已經非常熟悉了。在進行Discuz論壇的開發和管理過程中，經常需要查詢資料庫中的資料來進行分析或處理。在這篇文章中，我們將分享一些查詢Discuz資料庫位置的技巧，並提供具體的程式碼範例。首先，我們需要了解Discuz的資料庫結構
如何查詢BitTorrent幣最新價格？
Mar 06, 2024 pm 02:13 PM
查詢BitTorrent幣(BTT)最新價格BTT是TRON區塊鏈上的加密貨幣，用於獎勵BitTorrent網路用戶分享和下載檔案。尋找BTT最新價格的方法如下：選擇一個可靠的價格查詢網站或應用程式。一些常用的價格查詢網站包括：CoinMarketCap:https://coinmarketcap.com/Coindesk:https://www.coindesk.com/幣安:https://www.binance.com/在網站或應用程式中搜尋BTT。查看BTT的最新價格。注意：加密貨幣價格
如何查詢通神幣最新價格？
Mar 21, 2024 pm 02:46 PM
如何查詢通神幣最新價格？通神幣是一種數位貨幣，可用於購買遊戲內物品、服務和資產。它是去中心化的，意味著它不受政府或金融機構的控制。通神幣的交易在區塊鏈上進行，這是一個分散式帳本，記錄了所有通神幣交易的資訊。要查詢通神幣的最新價格，您可以使用以下步驟：選擇一個可靠的價格來查詢網站或應用程式。一些常用的價格查詢網站包括：CoinMarketCap:https://coinmarketcap.com/Coindesk:https://www.coindesk.com/幣安:https://www.bin
