婷婷综合国产,91蜜桃婷婷狠狠久久综合9色 ,九九九九九精品,国产综合av

主頁 > 知識庫 > Oracle中的半聯(lián)結(jié)和反聯(lián)結(jié)詳解

Oracle中的半聯(lián)結(jié)和反聯(lián)結(jié)詳解

熱門標簽:地圖標注怎么保存 高德地圖標注公司名字大全 七日殺a19.5全地圖標注 騰訊地圖標注要費用嗎 車瑪仕極限運動場所地圖標注 廣東營銷智能外呼系統(tǒng)商家 N個你智能電銷機器人 電渠外呼系統(tǒng) 外呼電話系統(tǒng)用卡嗎

當(dāng)兩張表進行聯(lián)結(jié)的時候,如果表1中的數(shù)據(jù)行是否出現(xiàn)在結(jié)果集中需要根據(jù)表2中出現(xiàn)或不出現(xiàn)至少一個相匹配的數(shù)據(jù)行來判斷,這種情況就會發(fā)生半聯(lián)結(jié);而反聯(lián)結(jié)便是半聯(lián)結(jié)的補集,它們會作為數(shù)據(jù)庫中常見的聯(lián)結(jié)方法如NESTED LOOPS,MERGE SORT JOIN,HASH JOIN的選項出現(xiàn)。

實際上半聯(lián)結(jié)和反聯(lián)結(jié)本身也可以被認同是兩種聯(lián)結(jié)方法;在CBO優(yōu)化模式下,優(yōu)化器能夠根據(jù)實際情況靈活的轉(zhuǎn)換執(zhí)行語句從而實現(xiàn)半聯(lián)結(jié)和反聯(lián)結(jié)方法,畢竟沒有什么SQL語法可以顯式的調(diào)用半聯(lián)結(jié)和反聯(lián)結(jié),它們只是SQL語句滿足某些條件時優(yōu)化器可以選擇的選項而已,不過仍然有必要深入這兩種選項在特定情況下帶來的性能優(yōu)勢。

半聯(lián)結(jié)

半聯(lián)結(jié)通常都發(fā)生在使用含有IN和EXISTS的相關(guān)子查詢的時候,=ANY的用法與IN相同,所以也會出現(xiàn)發(fā)生半聯(lián)結(jié)的情況;不過也是有例外的,在11gR2版本中,優(yōu)化器不會為任何包含在OR分支中的子查詢選擇半聯(lián)結(jié),這也是現(xiàn)在官檔中唯一明確標識的限制條件,來看幾種發(fā)生場景:

復(fù)制代碼 代碼如下:

-- 使用IN關(guān)鍵字的相關(guān)子查詢 => 發(fā)生NESTED LOOPS半聯(lián)結(jié)
SQL> select department_name
  2  from hr.departments dept
  3  where department_id in (select department_id from hr.employees emp);

11 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 2605691773

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    10 |   190 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS SEMI |                   |    10 |   190 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("DEPARTMENT_ID"="DEPARTMENT_ID")

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         11  consistent gets
          0  physical reads
          0  redo size
        742  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         11  rows processed

-- 使用EXISTS關(guān)鍵字的相關(guān)子查詢 => 發(fā)生NESTED LOOPS半聯(lián)結(jié)
SQL> select department_name
  2  from hr.departments dept where exists
  3  (select null from hr.employees emp where emp.department_id = dept.department_id);

11 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 2605691773

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    10 |   190 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS SEMI |                   |    10 |   190 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("EMP"."DEPARTMENT_ID"="DEPT"."DEPARTMENT_ID")

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         11  consistent gets
          0  physical reads
          0  redo size
        742  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         11  rows processed

-- 謂語中使用了OR分支中的EXISTS子查詢 => 禁用半聯(lián)結(jié)
SQL> select department_name
  2  from hr.departments dept
  3  where 1=2 OR exists
  4  (select null from hr.employees emp where emp.department_id = dept.department_id);

11 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 440241596

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    27 |   432 |     4   (0)| 00:00:01 |
|*  1 |  FILTER            |                   |       |       |            |          |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |     2 |     6 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( EXISTS (SELECT 0 FROM "HR"."EMPLOYEES" "EMP" WHERE
              "EMP"."DEPARTMENT_ID"=:B1))
   3 - access("EMP"."DEPARTMENT_ID"=:B1)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         35  consistent gets
          0  physical reads
          0  redo size
        742  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         11  rows processed

從結(jié)果集來看,我們很容易聯(lián)想到內(nèi)聯(lián)結(jié),那為什么半聯(lián)結(jié)通常來說會獲得更高的性能呢?這實際也是半聯(lián)結(jié)優(yōu)化的關(guān)鍵,拿NESTED LOOPS來舉例,在NESTED LOOPS聯(lián)結(jié)中,驅(qū)動表被讀取后需要逐個的進入內(nèi)層循環(huán)來進行匹配工作,并且只有當(dāng)外層循環(huán)的數(shù)據(jù)行與內(nèi)層循環(huán)中的每一行數(shù)據(jù)匹配運算完成后才會結(jié)束一個結(jié)果集的獲取;而相對而言,半聯(lián)結(jié)的區(qū)別在于數(shù)據(jù)集1中的每一條記錄只返回一次,而不管數(shù)據(jù)集2中有幾條匹配的記錄,因此,半聯(lián)結(jié)會在找到子查詢中匹配到的第一條數(shù)據(jù)后立即結(jié)束處理從而提高性能。

對于某些需要利用半聯(lián)結(jié)來提高性能的場景,可以通過手動的方式控制半聯(lián)結(jié)的執(zhí)行計劃,使用SEMIJOIN和NO_SEMIJOIN提示分別可以指定優(yōu)化器使用和禁用半聯(lián)結(jié)。

復(fù)制代碼 代碼如下:

-- 使用NO_SEMIJOIN提示禁用半聯(lián)結(jié)
SQL> select department_name
  2  from hr.departments dept
  3  where department_id in (select /*+ no_semijoin */department_id from hr.employees emp);

11 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3372191744

------------------------------------------------------------------------------------------
| Id  | Operation            | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                   |   106 |  1802 |     4  (25)| 00:00:01 |
|   1 |  VIEW                | VM_NWVW_2         |   106 |  1802 |     4  (25)| 00:00:01 |
|   2 |   HASH UNIQUE        |                   |   106 |  2544 |     4  (25)| 00:00:01 |
|   3 |    NESTED LOOPS      |                   |   106 |  2544 |     3   (0)| 00:00:01 |
|   4 |     TABLE ACCESS FULL| DEPARTMENTS       |    27 |   567 |     3   (0)| 00:00:01 |
|*  5 |     INDEX RANGE SCAN | EMP_DEPARTMENT_IX |     4 |    12 |     0   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("DEPARTMENT_ID"="DEPARTMENT_ID")

Statistics
----------------------------------------------------------
        506  recursive calls
          0  db block gets
        188  consistent gets
          7  physical reads
          0  redo size
        742  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
         10  sorts (memory)
          0  sorts (disk)
         11  rows processed

除此之外,我們還可以使用_always_semi_join隱藏參數(shù)選擇半聯(lián)結(jié)的聯(lián)結(jié)類型,有關(guān)_always_semi_join參數(shù)的可選值:

復(fù)制代碼 代碼如下:

SQL> SELECT
  2           PARNO_KSPVLD_VALUES     pvalid_par#,
  3           NAME_KSPVLD_VALUES      pvalid_name,
  4           VALUE_KSPVLD_VALUES     pvalid_value,
  5           DECODE(ISDEFAULT_KSPVLD_VALUES, 'FALSE', '', 'DEFAULT' ) pvalid_default
  6   FROM
  7           X$KSPVLD_VALUES
  8   WHERE
  9           LOWER(NAME_KSPVLD_VALUES) LIKE '%'||LOWER(nvl('pname',name_kspvld_values))||'%'
 10   ORDER BY
 11           pvalid_par#,
 12           pvalid_default,
 13           pvalid_Value
 14   /

  PAR# PARAMETER                                          VALUE                          DEFAULT
------ -------------------------------------------------- ------------------------------ -------
  1705 _always_semi_join                                  CHOOSE
       _always_semi_join                                  HASH
       _always_semi_join                                  MERGE
       _always_semi_join                                  NESTED_LOOPS
       _always_semi_join                                  OFF

該參數(shù)的默認值為choose,表示選用半聯(lián)結(jié)的類型由優(yōu)化器來決定,下面來使用_always_semi_join參數(shù)將上面的NESTED LOOPS半聯(lián)結(jié)改變?yōu)镠ASH JOIN半聯(lián)結(jié):

復(fù)制代碼 代碼如下:

-- 默認發(fā)生NESTED LOOPS SEMI
SQL> select department_name
  2  from hr.departments dept
  3  where department_id in (select department_id from hr.employees emp);

11 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 2605691773

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    10 |   190 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS SEMI |                   |    10 |   190 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("DEPARTMENT_ID"="DEPARTMENT_ID")

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         11  consistent gets
          0  physical reads
          0  redo size
        742  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         11  rows processed

-- session級別修改參數(shù)
SQL> alter session set "_always_semi_join"=merge;

Session altered.

-- 發(fā)生MERGE JOIN SEMI
SQL> select department_name
  2  from hr.departments dept
  3  where department_id in (select department_id from hr.employees emp);

11 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 954076352

--------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                   |    10 |   190 |     4  (25)| 00:00:01 |
|   1 |  MERGE JOIN SEMI             |                   |    10 |   190 |     4  (25)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPARTMENTS       |    27 |   432 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | DEPT_ID_PK        |    27 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT UNIQUE                |                   |   107 |   321 |     2  (50)| 00:00:01 |
|   5 |    INDEX FULL SCAN           | EMP_DEPARTMENT_IX |   107 |   321 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("DEPARTMENT_ID"="DEPARTMENT_ID")
       filter("DEPARTMENT_ID"="DEPARTMENT_ID")

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          5  consistent gets
          1  physical reads
          0  redo size
        742  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
         11  rows processed
-- 從trace來看優(yōu)化器的選擇還是非常可靠的。。

反聯(lián)結(jié)

從本質(zhì)上來說,反聯(lián)結(jié)和半聯(lián)結(jié)很多相似的因素,反聯(lián)結(jié)的發(fā)生通常是在使用含有NOT IN,NOT EXISTS的相關(guān)子查詢的時候,同樣,如果子查詢謂語OR分支中,反聯(lián)結(jié)也會被禁用,它和半聯(lián)結(jié)主要的不同點還是在返回數(shù)據(jù)的匹配方式上,它是會返回在子查詢中沒有匹配到的數(shù)據(jù)行,不過其優(yōu)化的原理是一致的,通過在子查詢中找到第一條匹配記錄而立即停止處理來提高效率,一下是發(fā)生的集中場景:

復(fù)制代碼 代碼如下:

SQL> set autotrace traceonly
-- NOT IN 觸發(fā)反聯(lián)結(jié)
SQL> select department_name
  2  from hr.departments
  3  where department_id not in
  4  (select department_id from hr.employees where department_id is not null);

16 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3082375452

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS ANTI |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("DEPARTMENT_ID"="DEPARTMENT_ID")
       filter("DEPARTMENT_ID" IS NOT NULL)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         12  consistent gets
          6  physical reads
          0  redo size
        985  bytes sent via SQL*Net to client
        535  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         16  rows processed

-- EXISTS觸發(fā)反聯(lián)結(jié)
SQL> select department_name
  2  from hr.departments dept
  3  where not exists
  4  (select null from hr.employees emp where emp.department_id = dept.department_id);

16 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3082375452

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS ANTI |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("EMP"."DEPARTMENT_ID"="DEPT"."DEPARTMENT_ID")

Statistics
----------------------------------------------------------
          3  recursive calls
          0  db block gets
         13  consistent gets
          0  physical reads
          0  redo size
        985  bytes sent via SQL*Net to client
        535  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         16  rows processed


從上面的例子可以看出minus和outer join操作都可以巧妙的實現(xiàn)同樣的結(jié)果,不過從執(zhí)行計劃來看,minus操作顯然沒有反聯(lián)結(jié)操作優(yōu)化,而使用outer join雖然發(fā)生了反聯(lián)結(jié)優(yōu)化,但是由于使用了帶空值的虛擬記錄來匹配數(shù)據(jù)行,不便于理解,因此實際還是不建議使用的。

如果想要手動控制反聯(lián)結(jié)的執(zhí)行計劃,這里也有一些hint和參數(shù)可以使用,常用的hint有:

1.ANTIJOIN-進行反聯(lián)結(jié),優(yōu)化器決定聯(lián)結(jié)類型
2.USE_ANTI-老版本的提示,和ANTIJOIN功能一致
3.[NL_AJ] | [HASH_AJ] | [MERGE_AJ]-指定發(fā)生反聯(lián)結(jié)的類型(10g開始被棄用,不過仍然可以生效)

在參數(shù)控制方面,也有個和_always_semi_join非常相同的_always_anti_join參數(shù),用法完全一致;還有參數(shù)_optimizer_null_aware_antijoin,_optimizer_outer_to_anti_enable用于控制對含空值和外聯(lián)結(jié)的反聯(lián)結(jié)轉(zhuǎn)換。

復(fù)制代碼 代碼如下:

-- 使用hint顯式指定反聯(lián)結(jié)類型
SQL> select department_name
  2  from hr.departments dept
  3  where not exists (select /*+ hash_aj */ null from hr.employees emp
  4  where emp.department_id = dept.department_id);

16 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3587451639

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    17 |   323 |     5  (20)| 00:00:01 |
|*  1 |  HASH JOIN ANTI    |                   |    17 |   323 |     5  (20)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|   3 |   INDEX FULL SCAN  | EMP_DEPARTMENT_IX |   107 |   321 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("EMP"."DEPARTMENT_ID"="DEPT"."DEPARTMENT_ID")

Statistics
----------------------------------------------------------
        566  recursive calls
          0  db block gets
        193  consistent gets
          0  physical reads
          0  redo size
        985  bytes sent via SQL*Net to client
        535  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
         12  sorts (memory)
          0  sorts (disk)
         16  rows processed

-- 使用_optimizer_null_antijoin參數(shù)關(guān)閉反聯(lián)結(jié)中的空值考慮選項-即返回空值的情況不使用反聯(lián)結(jié)
SQL> alter session set "_optimizer_null_aware_antijoin"=false;

Session altered.

SQL> select department_name
  2  from hr.departments
  3  where department_id not in (select department_id from hr.employees);

no rows selected

Execution Plan
----------------------------------------------------------
Plan hash value: 3416340233

----------------------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |    26 |   416 |    30   (0)| 00:00:01 |
|*  1 |  FILTER            |             |       |       |            |          |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| EMPLOYEES   |     2 |     6 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( NOT EXISTS (SELECT 0 FROM "HR"."EMPLOYEES" "EMPLOYEES"
              WHERE LNNVL("DEPARTMENT_ID">:B1)))
   3 - filter(LNNVL("DEPARTMENT_ID">:B1))

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        172  consistent gets
          0  physical reads
          0  redo size
        343  bytes sent via SQL*Net to client
        513  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

標簽:棗莊 玉樹 長沙 贛州 大興安嶺 來賓 蘇州 遼寧

巨人網(wǎng)絡(luò)通訊聲明:本文標題《Oracle中的半聯(lián)結(jié)和反聯(lián)結(jié)詳解》,本文關(guān)鍵詞  Oracle,中的,半,聯(lián)結(jié),和,反,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《Oracle中的半聯(lián)結(jié)和反聯(lián)結(jié)詳解》相關(guān)的同類信息!
  • 本頁收集關(guān)于Oracle中的半聯(lián)結(jié)和反聯(lián)結(jié)詳解的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章
    婷婷综合国产,91蜜桃婷婷狠狠久久综合9色 ,九九九九九精品,国产综合av
    国产精品久久久久天堂| 欧美videos中文字幕| 91黄色免费看| 国产精品视频在线看| 喷白浆一区二区| 911国产精品| 日韩电影网1区2区| 欧美日韩国产小视频| 偷拍日韩校园综合在线| 色综合久久精品| 亚洲欧美日韩国产综合| 国产成人在线免费| 中文字幕在线不卡视频| 国产91丝袜在线播放0| 一区二区三区在线影院| 国产精品18久久久久| 精品国精品国产| 国产成人免费视| ●精品国产综合乱码久久久久| 9色porny自拍视频一区二区| 国产亚洲精品bt天堂精选| 成人免费看黄yyy456| 亚洲欧洲综合另类| 精品视频123区在线观看| 一区2区3区在线看| 久久色成人在线| 99re这里只有精品视频首页| 日本不卡在线视频| 国产色婷婷亚洲99精品小说| 99精品国产99久久久久久白柏| 亚洲电影第三页| 久久蜜桃一区二区| 色8久久精品久久久久久蜜| 极品少妇xxxx偷拍精品少妇| 亚洲自拍另类综合| 国产午夜三级一区二区三| 色婷婷av一区二区三区之一色屋| 老司机午夜精品| 一区二区久久久久| 亚洲国产精品t66y| 欧美大片在线观看一区二区| 在线观看亚洲一区| 99精品国产99久久久久久白柏| 国内成人精品2018免费看| 午夜精品久久一牛影视| 亚洲久本草在线中文字幕| 久久精品人人做人人综合| 欧美一区二区三区免费观看视频| 色94色欧美sute亚洲线路二| www.欧美色图| 国产精品一二三四区| 另类小说一区二区三区| 丝袜美腿亚洲一区| 午夜国产精品影院在线观看| 亚洲精品国产视频| 亚洲日本丝袜连裤袜办公室| 中文字幕国产精品一区二区| 精品国产乱码久久久久久久| 日韩无一区二区| 欧美大片国产精品| 日韩一级大片在线| 欧美一区二区三区性视频| 69精品人人人人| 欧美精品国产精品| 欧美日韩国产一级二级| 欧美精选一区二区| 日韩美女在线视频| 亚洲欧美偷拍另类a∨色屁股| 欧美精品一区二区三区蜜桃| 91精品国产一区二区三区| 欧美日韩久久久久久| 色av成人天堂桃色av| 91传媒视频在线播放| 在线观看www91| 欧美日韩一区 二区 三区 久久精品| 国产69精品一区二区亚洲孕妇| 乱一区二区av| thepron国产精品| 99re亚洲国产精品| 欧美少妇一区二区| 91精品国产综合久久精品麻豆| 欧美精品粉嫩高潮一区二区| 欧美成人三级在线| 亚洲国产精品二十页| 亚洲欧美视频在线观看视频| 三级久久三级久久| 美女网站在线免费欧美精品| 国产精品综合av一区二区国产馆| 粉嫩一区二区三区性色av| 色婷婷综合久久久中文一区二区| 在线观看国产精品网站| 日韩午夜激情av| 国产精品久久久久三级| 午夜精品福利一区二区蜜股av| 精品一区二区三区在线视频| caoporn国产精品| 91麻豆精品国产91久久久| 久久精品亚洲麻豆av一区二区| 亚洲欧美欧美一区二区三区| 秋霞电影网一区二区| 99精品视频在线观看| 精品久久一区二区| 一区二区三区精品在线观看| 韩国理伦片一区二区三区在线播放| 不卡一区二区三区四区| 欧美日韩免费一区二区三区视频| 久久久精品蜜桃| 日韩va欧美va亚洲va久久| 成人久久18免费网站麻豆| 色综合欧美在线视频区| 日韩一区二区三区电影在线观看| 国产精品久久夜| 国产在线不卡一区| 欧美嫩在线观看| 精品乱人伦小说| 日本中文字幕一区二区有限公司| av一区二区三区四区| 天天色图综合网| 成人av网站免费| 国产亚洲一区二区三区四区 | 国产女主播视频一区二区| 一区二区三区在线观看动漫| 国产精品自在在线| 久久蜜桃一区二区| 紧缚捆绑精品一区二区| 欧美日韩一区国产| 一区二区三区四区乱视频| eeuss鲁片一区二区三区在线观看| 久久五月婷婷丁香社区| 久久精品国产精品亚洲红杏| 欧美日韩免费视频| 国产精品污www在线观看| 久久精品国产在热久久| 91日韩在线专区| 国产精品私人自拍| 成人一区二区三区视频在线观看| 欧美色精品在线视频| 亚洲欧美电影一区二区| 成人高清视频免费观看| 欧美视频一区二区三区在线观看| 国产嫩草影院久久久久| 国产精品456| 国产日韩欧美a| 国产成人综合亚洲网站| 中文字幕精品在线不卡| 国产成都精品91一区二区三| 欧美一区二区私人影院日本| 蜜臀av性久久久久蜜臀av麻豆| 欧美日韩综合不卡| 五月天激情综合| 日韩欧美国产精品| 激情五月婷婷综合| 精品成人佐山爱一区二区| 国产乱理伦片在线观看夜一区| 2欧美一区二区三区在线观看视频| 老司机午夜精品| 国产性做久久久久久| 91免费观看视频| 一区二区三区美女| 日韩欧美精品在线视频| 国产超碰在线一区| 亚洲少妇最新在线视频| 欧美日韩国产首页在线观看| 久久精品噜噜噜成人av农村| 中文字幕欧美区| 欧美日韩精品一区二区三区蜜桃| 久久精品99国产精品| 国产欧美日本一区二区三区| 欧美日韩综合在线免费观看| 国产精品亚洲а∨天堂免在线| 亚洲欧洲三级电影| 在线观看不卡一区| 免费视频最近日韩| 亚洲欧美日本在线| 2023国产精品| 久久精品人人做人人爽97| 成人av动漫网站| 免费人成网站在线观看欧美高清| 久久蜜臀中文字幕| 欧美精品一卡二卡| jiyouzz国产精品久久| 天天色天天操综合| 欧美激情在线一区二区| 91视频国产观看| 精品一区二区三区av| 亚洲欧洲精品一区二区精品久久久 | 精品电影一区二区三区| 日本国产一区二区| 国产一区高清在线| 一区二区三区精品视频在线| 久久久午夜电影| 6080午夜不卡| 在线视频你懂得一区二区三区| 国产精品一二三四| 免费在线观看精品| 五月激情综合婷婷| 亚洲精品视频自拍| 中文字幕一区二区三区精华液| 精品久久久久久久久久久院品网| 日本高清不卡aⅴ免费网站|