国产精品国产自产拍高清av王其,日本天堂影院在线视频,亚洲欧美激情精品一区二区

blog已經(jīng)轉(zhuǎn)移至github,大家請(qǐng)?jiān)L問(wèn) http://qaseven.github.io/

Oracle 全表掃描及其執(zhí)行計(jì)劃

全表掃描是Oracle訪問(wèn)數(shù)據(jù)庫(kù)表是較為常見(jiàn)的訪問(wèn)方式之一。很多朋友一看到SQL語(yǔ) 句執(zhí)行計(jì)劃中的全表掃描，就要考慮對(duì)其進(jìn)行修理一番。全表掃描的存在，的確存在可能優(yōu)化的余地。但事實(shí)上很多時(shí)候全表掃描也并非是最低效的，完全要看不同的情形與場(chǎng)合，任一方式都是有利有弊的，也就是具體情況要具體分析。本文描述了什么是全表掃描以及何時(shí)發(fā)生全表掃描，何時(shí)全表掃描才低效。

　　本文涉及到的相關(guān)鏈接：

　　高水位線(xiàn)和全表掃描

　　啟用 AUTOTRACE 功能

　　Oracle 測(cè)試常用表BIG_TABLE

　　Oracle db_file_mulitblock_read_count參數(shù)

　　1、什么是全表掃描？

　　全表掃描就是掃表表中所有的行，實(shí)際上是掃描表中所有的數(shù)據(jù)塊，因?yàn)镺racle中最小的存儲(chǔ)單位是Oracle block。

　　掃描所有的數(shù)據(jù)塊就包括高水位線(xiàn)以?xún)?nèi)的數(shù)據(jù)塊，即使是空數(shù)據(jù)塊在沒(méi)有被釋放的情形下也會(huì)被掃描而導(dǎo)致I/O增加。

　　在全表掃描期間，通常情況下，表上這些相鄰的數(shù)據(jù)塊被按順序(sequentially)的方式訪問(wèn)以使得一次I/O可以讀取多個(gè)數(shù)據(jù)塊。

　　一次讀取更多的數(shù)據(jù)塊有助于全表掃描使用更少的I/O，對(duì)于可讀取的數(shù)據(jù)塊被限制于參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT。

　　2、何時(shí)發(fā)生全表掃描？

　　a、表上的索引失效或無(wú)法被使用的情形(如對(duì)謂詞使用函數(shù)、計(jì)算、NULL值、不等運(yùn)算符、類(lèi)型轉(zhuǎn)換)

　　b、查詢(xún)條件返回了整個(gè)表的大部分?jǐn)?shù)據(jù)

　　c、使用了并行方式訪問(wèn)表

　　d、使用full 提示

　　e、統(tǒng)計(jì)信息缺失時(shí)使得Oracle認(rèn)為全表掃描比索引掃描更高效

　　f、表上的數(shù)據(jù)塊小于DB_FILE_MULTIBLOCK_READ_COUNT值的情形可能產(chǎn)生全表掃描

　　3、演示全表掃描的情形

a、準(zhǔn)備演示環(huán)境
scott@ORA11G> select * from v$version where rownum<2;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

--創(chuàng)建表t
scott@ORA11G> CREATE TABLE t
2 AS
3 SELECT rownum AS n, rpad('*',100,'*') AS pad
4 FROM dual
5 CONNECT BY level <= 1000;

Table created.

--添加索引
scott@ORA11G> create unique index t_pk on t(n);

Index created.

scott@ORA11G> alter table t add constraint t_pk primary key(n) using index t_pk;

Table altered.

--收集統(tǒng)計(jì)信息
scott@ORA11G> execute dbms_stats.gather_table_stats('SCOTT','T',cascade=>true);

PL/SQL procedure successfully completed.

scott@ORA11G> set autot trace exp;
scott@ORA11G> select count(*) from t; --->count(*)的時(shí)候使用了索引快速掃描

Execution Plan
----------------------------------------------------------
Plan hash value: 454320086
----------------------------------------------------------------------
| Id | Operation             | Name | Rows | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |     1 |     2   (0)| 00:00:01 |
|   1 | SORT AGGREGATE       |      |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| T_PK | 1000 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------

scott@ORA11G> set autot off;
scott@ORA11G> alter table t move; --->進(jìn)行move table

Table altered.

-->move 之后索引失效，如下所示
scott@ORA11G> @idx_info
Enter value for owner: scott
Enter value for table_name: t

Table Name INDEX_NAME CL_NAM CL_POS STATUS IDX_TYP DSCD
------------- -------------- -------------------- ------ -------- --------------- ----
T T_PK N 1 UNUSABLE NORMAL ASC

b、索引失效導(dǎo)致全表掃描
scott@ORA11G> set autot trace exp;
scott@ORA11G> select count(*) from t;

scott@ORA11G> set autot off;
scott@ORA11G> alter index t_pk rebuild; -->重建索引

Index altered.

scott@ORA11G> @idx_info
Enter value for owner: scott
Enter value for table_name: t

Table Name INDEX_NAME CL_NAM CL_POS STATUS IDX_TYP DSCD
-------------- ---------------- -------------------- ------ -------- --------------- ----
T T_PK N 1 VALID NORMAL ASC

c、返回了整個(gè)表的大部分?jǐn)?shù)據(jù)使用了全表掃描
scott@ORA11G> select count(pad) from t where n<=990;

Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
---------------------------------------------------------------------------
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   105 |     7   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |      |     1 |   105 |            |          |
|* 2 |   TABLE ACCESS FULL| T    |   991 |   101K|     7   (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("N"<=990)

--返回小部分?jǐn)?shù)據(jù)時(shí)，使用的是索引掃描
scott@ORA11G> select count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 4270555908
-------------------------------------------------------------------------------------
| Id | Operation                    | Name | Rows | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |      |     1 |   105 |     3   (0)| 00:00:01 |
|   1 | SORT AGGREGATE              |      |     1 |   105 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| T    |    10 | 1050 |     3   (0)| 00:00:01 |
|* 3 |    INDEX RANGE SCAN          | T_PK |    10 |       |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("N"<=10)

d、使用并行方式訪問(wèn)表時(shí)使用了全表掃描
scott@ORA11G> select /*+ parallel(3) */ count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 3126468333
----------------------------------------------------------------------------------------------------------------
| Id | Operation              | Name     | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |          |     1 |   105 |     3   (0)| 00:00:01 |        |      |            |
|   1 | SORT AGGREGATE        |          |     1 |   105 |            |          |        |      |            |
|   2 |   PX COORDINATOR       |          |       |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000 |     1 |   105 |            |          | Q1,00 | P->S | QC (RAND) |
|   4 |     SORT AGGREGATE     |          |     1 |   105 |            |          | Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR |          |    10 | 1050 |     3   (0)| 00:00:01 | Q1,00 | PCWC |            |
|* 6 |       TABLE ACCESS FULL| T        |    10 | 1050 |     3   (0)| 00:00:01 | Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   6 - filter("N"<=10)
Note
-----
   - Degree of Parallelism is 3 because of hint
--Author : Robinson
--Blog   :http://blog.csdn.net/robinson_0612

e、使用full提示時(shí)使用了全表掃描
scott@ORA11G> select /*+ full(t) */ count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
---------------------------------------------------------------------------
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   105 |     7   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |      |     1 |   105 |            |          |
|* 2 |   TABLE ACCESS FULL| T    |    10 | 1050 |     7   (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("N"<=10)

f、統(tǒng)計(jì)信息缺失導(dǎo)致全表掃描的情形
scott@ORA11G> exec dbms_stats.delete_table_stats('SCOTT','T');

PL/SQL procedure successfully completed.

scott@ORA11G> select count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
---------------------------------------------------------------------------
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    65 |     7   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |      |     1 |    65 |            |          |
|* 2 |   TABLE ACCESS FULL| T    |    10 |   650 |     7   (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("N"<=10)
Note
-----
   - dynamic sampling used for this statement (level=2)

--上面的執(zhí)行計(jì)劃使用了全表掃描，而且提示使用了動(dòng)態(tài)采樣，也就是缺乏統(tǒng)計(jì)信息
--表上的數(shù)據(jù)塊小于DB_FILE_MULTIBLOCK_READ_COUNT值的情形可能產(chǎn)生全表掃描的情形不演示

　4、全表掃描何時(shí)低效？

--先來(lái)做幾個(gè)實(shí)驗(yàn)
a、演示表上的相關(guān)信息
scott@ORA11G> @idx_info
Enter value for owner: scott
Enter value for table_name: big_table

Table Name Index Name CL_NAM CL_POS Status IDX_TYP DSCD
------------------------- ------------------------- --------- ------ -------- --------------- ----
BIG_TABLE BIG_TABLE_PK ID 1 VALID NORMAL ASC

scott@ORA11G> @idx_stat
Enter value for input_table_name: big_table
Enter value for owner: scott

                                                     AVG LEAF BLKS AVG DATA BLKS
BLEV IDX_NAME        LEAF_BLKS   DST_KEYS       PER KEY       PER KEY CLUST_FACT LAST_ANALYZED         TB_BLKS    TB_ROWS
---- -------------- ---------- ---------- ------------- ------------- ---------- ------------------ ---------- ----------
   1 BIG_TABLE_PK          208     100000             1             1       1483 20130524 10:45:51        1515     100000

--數(shù)據(jù)庫(kù)參數(shù)設(shè)置
scott@ORA11G> show parameter optimizer_index_

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
scott@ORA11G> show parameter optimizer_mode

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_mode string ALL_ROWS

b、查詢(xún)返回20%數(shù)據(jù)行的情形
scott@ORA11G> alter system flush buffer_cache;
scott@ORA11G> select sum(object_id),avg(object_id) from big_table where id between 20000 and 40000;

Execution Plan
----------------------------------------------------------
Plan hash value: 3098837282                             -- 執(zhí)行計(jì)劃中，使用了索引范圍掃描
---------------------------------------------------------------------------------------------
| Id | Operation                    | Name         | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |    18 |   341   (0)| 00:00:05 |
|   1 | SORT AGGREGATE              |              |     1 |    18 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| BIG_TABLE    | 20046 |   352K|   341   (0)| 00:00:05 |
|* 3 |    INDEX RANGE SCAN          | BIG_TABLE_PK | 20046 |       |    43   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("ID">=20000 AND "ID"<=40000)
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
        351 consistent gets
        351 physical reads
          0 redo size
        427 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

scott@ORA11G> alter system flush buffer_cache;
scott@ORA11G> select /*+ full(big_table) */ sum(object_id),avg(object_id) from big_table where id between 20000 and 40000;

Execution Plan
----------------------------------------------------------
Plan hash value: 599409829                ---- 使用了提示執(zhí)行為全表掃描
--------------------------------------------------------------------------------
| Id | Operation          | Name      | Rows | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |     1 |    18 |   413   (1)| 00:00:05 |
|   1 | SORT AGGREGATE    |           |     1 |    18 |            |          |
|* 2 |   TABLE ACCESS FULL| BIG_TABLE | 20046 |   352K|   413   (1)| 00:00:05 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ID"<=40000 AND "ID">=20000)
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
       1486 consistent gets
       1484 physical reads
          0 redo size
        427 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

--注意對(duì)比上面兩次操作中的consistent gets與physical reads

c、查詢(xún)返回30%數(shù)據(jù)行的情形
scott@ORA11G> alter system flush buffer_cache;
scott@ORA11G> select sum(object_id),avg(object_id) from big_table where id between 20000 and 50000;

Execution Plan
----------------------------------------------------------
Plan hash value: 599409829             --->盡管返回?cái)?shù)據(jù)的總行數(shù)為30%，而此時(shí)優(yōu)化器使用了全表掃描
--------------------------------------------------------------------------------
| Id | Operation          | Name      | Rows | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |     1 |    18 |   413   (1)| 00:00:05 |
|   1 | SORT AGGREGATE    |           |     1 |    18 |            |          |
|* 2 |   TABLE ACCESS FULL| BIG_TABLE | 30012 |   527K|   413   (1)| 00:00:05 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ID"<=50000 AND "ID">=20000)
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
       1486 consistent gets
       1484 physical reads
          0 redo size
        427 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

--下面使用提示來(lái)強(qiáng)制優(yōu)化器走索引掃描
scott@ORA11G> alter system flush buffer_cache;
scott@ORA11G> select /*+ index(big_table big_table_pk) */ sum(object_id),avg(object_id)
2 from big_table where id between 20000 and 50000;

Execution Plan
----------------------------------------------------------
Plan hash value: 3098837282
---------------------------------------------------------------------------------------------
| Id | Operation                    | Name         | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |    18 |   511   (1)| 00:00:07 |
|   1 | SORT AGGREGATE              |              |     1 |    18 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| BIG_TABLE    | 30012 |   527K|   511   (1)| 00:00:07 |
|* 3 |    INDEX RANGE SCAN          | BIG_TABLE_PK | 30012 |       |    64   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("ID">=20000 AND "ID"<=50000)
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
        526 consistent gets
        526 physical reads
          0 redo size
        427 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

--注意觀察每一次測(cè)試時(shí)所耗用的物理讀與邏輯讀
--從上面的測(cè)試可以看出，當(dāng)表上所返回的數(shù)據(jù)行數(shù)接近于表上的30%時(shí)，Oracle 傾向于使用全表掃描
--而對(duì)于表上所返回的數(shù)據(jù)行數(shù)接近于表上的30%的情形，我們給與索引提示，此時(shí)比全表掃描更高效，即全表掃描是低效的
--筆者同時(shí)測(cè)試了數(shù)據(jù)返回總行數(shù)接近80%的情形以及創(chuàng)建了一個(gè)百萬(wàn)記錄的進(jìn)行對(duì)比測(cè)試
--大致結(jié)論，如果查詢(xún)所返回的數(shù)據(jù)的總行數(shù)僅僅是表上數(shù)據(jù)的百分之八十以下，而使用了全表掃描，即可認(rèn)為該全表掃描是低效的
--注：
--具體情況需要具體分析，如果你的表是千萬(wàn)級(jí)的，返回總數(shù)據(jù)的百分之零點(diǎn)幾都會(huì)導(dǎo)致很大的差異
--其次，表上的索引應(yīng)具有良好的聚簇因子，如不然，測(cè)試的結(jié)果可能有天壤之別
--最后，上面所描述的返回總行數(shù)應(yīng)與執(zhí)行結(jié)果返回的行數(shù)有差異，是指多少行參與了sum(object_id)

　5、小表的全表掃描是否高效？

--使用scott下dept表，僅有4行數(shù)據(jù)
scott@ORA11G> select * from dept where deptno>10;

3 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 2985873453            --->執(zhí)行計(jì)劃選擇了索引掃描
---------------------------------------------------------------------------------------
| Id | Operation                   | Name    | Rows | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |     3 |    60 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| DEPT    |     3 |    60 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | PK_DEPT |     3 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("DEPTNO">10)
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
          4 consistent gets                      -->使用了4次邏輯讀
          0 physical reads
          0 redo size
        515 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed

-->下面強(qiáng)制使用全表掃描
scott@ORA11G> select /*+ full(dept) */ * from dept where deptno>10;

3 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3383998547
--------------------------------------------------------------------------
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     3 |    60 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DEPT |     3 |    60 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("DEPTNO">10)
Statistics
----------------------------------------------------------
          1 recursive calls
          0 db block gets
          4 consistent gets         -->此時(shí)的邏輯讀同樣為4次
          0 physical reads
          0 redo size
        515 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed

--下面來(lái)看看count(*)的情形
scott@ORA11G> select count(*) from dept;

1 row selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3051237957               --->執(zhí)行計(jì)劃選擇了索引全掃描
--------------------------------------------------------------------
| Id | Operation        | Name    | Rows | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT |         |     1 |     1   (0)| 00:00:01 |
|   1 | SORT AGGREGATE |         |     1 |            |          |
|   2 |   INDEX FULL SCAN| PK_DEPT |     4 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
          1 consistent gets            -->邏輯讀僅為1次
          0 physical reads
          0 redo size
        335 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

-->下面強(qiáng)制使用全表掃描
scott@ORA11G> select /*+ full(dept) */ count(*) from dept;

1 row selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 315352865
-------------------------------------------------------------------
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     3   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| DEPT |     4 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
          3 consistent gets     -->使用了3次邏輯讀
          0 physical reads
          0 redo size
        335 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

--對(duì)于小表，從上面的情形可以看出，使用索引掃描也是比全表掃描高效
--因此，建議始終為小表建立索引

posted on 2013-06-07 10:10 順其自然EVO 閱讀(285) 評(píng)論(0) 編輯收藏所屬分類(lèi): 數(shù)據(jù)庫(kù)

新用戶(hù)注冊(cè) 刷新評(píng)論列表


只有注冊(cè)用戶(hù)登錄后才能發(fā)表評(píng)論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問(wèn) 管理
相關(guān)文章: MySQL數(shù)字輔助表 PLSQL Developer鮮為人知的快捷鍵淘寶分布式配置管理服務(wù)Diamond iOS開(kāi)發(fā)之FMDB AlwaysOn可用性組功能測(cè)試(2)-SQL Server群集故障轉(zhuǎn)移 SQL Server 2008 (R2) 單機(jī)版安裝的先決條件 AlwaysOn可用性組功能測(cè)試(2)-SQL Server群集故障轉(zhuǎn)移聊聊Oracle外鍵約束的幾個(gè)操作選項(xiàng) SQL優(yōu)化中索引列使用函數(shù)之靈異事件利用binlog進(jìn)行數(shù)據(jù)庫(kù)的還原

qileilove

Oracle 全表掃描及其執(zhí)行計(jì)劃

導(dǎo)航

統(tǒng)計(jì)

常用鏈接

留言簿(55)

隨筆分類(lèi)

隨筆檔案

文章分類(lèi)

文章檔案

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜