2. 程式人生 > >hint不當索引，影像多表連線方式，最終導致SQL執行緩慢

hint不當索引，影像多表連線方式，最終導致SQL執行緩慢

阿新 • • 發佈：2019-01-06

需求：一個SQL執行特別慢，無法返回結果，需要進行優化，最終返回結果即可。

 

一、SQL分析

 

二、嘗試執行，觀測執行計劃

 

三、修改SQL

 

四、問題總結

 

一、SQL分析

1）SQL文字，執行時間，執行使用者
使用者brjljk sql執行時間，2935分鐘
sql_text
select c.hphm,
       c.ccdjrq,
       c.clpp1,
       c.clxh,
       c.zt,
       c.syr,
       c.wfsj,
       c.wfxw,
       c.dsr,
       c.xxly,
       c.syq,
       c.wfsj1,
       d.wfnr,
       e.dlmc,
       c.xxly1,
       c.dsr1
  
 
from (select /*+ index(b idx_violation_wfsj)*/
         a.hphm,
         a.ccdjrq,
         a.clpp1,
         a.clxh,
         a.zt,
         a.syr,
         a.wfsj,
         a.wfxw,
         a.dsr,
         a.xxly,
         a.syq,
         b.wfsj   wfsj1,
         b.wfxw   wfxw1,
         b.wfdd   wfdd1,
         b.xxly   xxly1,
         b.dsr    dsr1
          
 
from sjs20181022 a
         right join trff_app.vio_violation b
            on a.hphm = b.hphm
         where a.wfsj <> b.wfsj
           and (b.wfsj < add_months(a.wfsj, 12) and
               b.wfsj > add_months(a.wfsj, -12))
           and a.wfsj > to_date('2018-08-01', 'yyyy-mm-dd')
           and a.wfsj 
 
< to_date('2018-09-01', 'yyyy-mm-dd')
         order by a.hphm, a.wfsj, b.wfsj) c,
       trff_app.vio_codewfdm d,
       trff_app.frm_roaditem e
 where c.wfxw1 = d.wfxw
   and c.wfdd1 = e.dldm

2）查詢會話等待事件

SQL> select sid,serial#,event,sql_id,status,(sysdate-logon_time)*86400 as "s",

last_call_et,username,inst_id,MACHINE from gv$session where status='ACTIVE' and username is not null;

SID SERIAL# EVENT SQL_ID STATUS s LAST_CALL_ET USERNAME INST_ID MACHINE
---------- ---------- ------------------------------ ------------- -------- ---------- -------
1776 28345 db file sequential read 2vcdzpaknk46s ACTIVE 180100 176352 BRJLJK 1 xx

 

3)查詢sql文字

SQL> select sql_text from v$sqlarea where sql_id ='&a';
SQL> select sql_text from v$sqltext where sql_id ='2vcdzpaknk46s';
SQL> select sql_text from v$sqlstats where sql_id ='2vcdzpaknk46s';

4）查詢執行計劃

select * from table(dbms_xplan.display_cursor('&sql',null,'PEEKED_BINDS'));

SQL> select * from table(dbms_xplan.display_awr('2vcdzpaknk46s',null));

------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 129M(100)| |
| 1 | SORT ORDER BY | | 309 | 56238 | 129M (1)|432:58:14 |
| 2 | HASH JOIN | | 309 | 56238 | 129M (1)|432:58:14 |
| 3 | HASH JOIN | | 309 | 50985 | 129M (1)|432:58:13 |
| 4 | HASH JOIN | | 309 | 37389 | 129M (1)|432:58:13 |
| 5 | TABLE ACCESS FULL | SJS20181022 | 10455 | 847K| 891 (2)| 00:00:11 |
| 6 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 144M| 5226M| 129M (1)|432:57:51 |
| 7 | INDEX FULL SCAN | IDX_VIOLATION_WFSJ | 144M| | 583K (1)| 01:56:47 |
| 8 | TABLE ACCESS FULL | VIO_CODEWFDM | 1069 | 47036 | 13 (0)| 00:00:01 |
| 9 | TABLE ACCESS FULL | FRM_ROADITEM | 5212 | 88604 | 22 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------

5）查詢SQL等待事件

select count(*),event,count(distinct session_id) from gv$active_session_history
where sql_id='2vcdzpaknk46s' group by event;
COUNT(*) EVENT COUNT(DISTINCTSESSION_ID)
---------- ------------------------------ -------------------------
27652 db file sequential read 1
22 gc cr block 2-way 1
258 gc cr disk read 1
293 1

 

6）查詢執行計劃最慢的步驟（failed）

select count(*),sql_plan_line_id
from gv$active_session_history
where sql_id='2vcdzpaknk46s'
group by sql_plan_line_id
order by 2;

--生產環境10.2.0.5，11g才有的欄位

7）表碎片

表碎片會導致全表掃描更消耗資源，本次慢不是由於全表掃描的問題

 

8）資料量

通過dba_tables,num_rows,dba_segments,bytes查詢得到資訊如下

a表 hash join 驅動表，30萬條記錄

B表 hash join 被驅動表，1億條記錄，表100G大小

 

 

 

二、嘗試執行，觀測執行計劃

 

1）確認優化重點四個表中，從執行計劃看，重點為
| 6 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 144M| 5226M| 129M (1)|432:57:51 |
| 7 | INDEX FULL SCAN | IDX_VIOLATION_WFSJ | 144M| | 583K (1)| 01:56:47 |
該SQL是a +b 的集合，轉換為c最後與其它表進行關聯查詢

2）對a+b表的查詢進行優化及測試

思路A，是否由於時間取值範圍導致的問題
 and (b.wfsj < add_months(a.wfsj, 12) and
               b.wfsj > add_months(a.wfsj, -12))
           and a.wfsj > to_date('2018-08-01', 'yyyy-mm-dd')
           and a.wfsj < to_date('2018-09-01', 'yyyy-mm-dd')

explain plan for select a.hphm,a.wfsj,b.wfsj from BRJLJK.sjs20181022 a right join trff_app.vio_violation

b on a.hphm=b.hphm where b.wfsj > to_date('2017-01-01','yyyy-mm-dd')

and b.wfsj <to_date('2019-01-01','yyyy-mm-dd') and a.wfsj>to_date('2018-08-01','yyyy-mm-dd')

and a.wfsj<to_date('2018-09-01','yyyy-mm-dd') order by a.hphm,a.wfsj, b.wfsj;

1* select * from table(dbms_xplan.display())

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------
Plan hash value: 1015943026

-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 18958 | 629K| 115K (1)| 00:23:12 |
| 1 | SORT ORDER BY | | 18958 | 629K| 115K (1)| 00:23:12 |
|* 2 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 2 | 34 | 13 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 18958 | 629K| 115K (1)| 00:23:12 |
|* 4 | INDEX FAST FULL SCAN | SJS20181022_IND_HPHM | 10455 | 173K| 277 (2)| 00:00:04 |
|* 5 | INDEX RANGE SCAN | IDX_VIOLATION_HPHM | 12 | | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

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

2 - filter("B"."WFSJ">TO_DATE(' 2017-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"B"."WFSJ"<TO_DATE(' 2019-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
4 - filter("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
5 - access("A"."HPHM"="B"."HPHM")

 

 

select * from table(dbms_xplan.display_cursor('004nmwuabm1qr',null,'PEEKED_BINDS'))

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
SQL_ID 004nmwuabm1qr, child number 0
-------------------------------------
select a.hphm, a.ccdjrq, a.clpp1, a.clxh, a.zt,
a.syr, a.wfsj, a.wfxw, a.dsr, a.xxly,
a.syq, b.wfsj wfsj1, b.wfxw wfxw1, b.wfdd wfdd1,
b.xxly xxly1, b.dsr dsr1 from BRJLJK.sjs20181022 a right join
trff_app.vio_violation b on a.hphm=b.hphm where (b.wfsj < add_months(a.wfsj, 12) and
b.wfsj >add_months(a.wfsj, -12)) and a.wfsj>to_date('2018-08-01','yyyy-mm-dd') and
a.wfsj<to_date('2018-09-01','yyyy-mm-dd') order by a.hphm,a.wfsj, b.wfsj

Plan hash value: 3321285990

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 136K(100)| |
| 1 | SORT ORDER BY | | 309 | 37389 | 136K (1)| 00:27:23 |
|* 2 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 1 | 38 | 13 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 309 | 37389 | 136K (1)| 00:27:23 |
|* 4 | TABLE ACCESS FULL | SJS20181022 | 10455 | 847K| 891 (2)| 00:00:11 |
|* 5 | INDEX RANGE SCAN | IDX_VIOLATION_HPHM | 12 | | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

2 - filter(("B"."WFSJ"<ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),12) AND
"B"."WFSJ">ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),-12)))
4 - filter(("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
 AND
"A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
5 - access("A"."HPHM"="B"."HPHM")


32 rows selected.

 

結論A的考慮是錯誤的，add_months並不會導致執行計劃消耗更多的資源

 

思路B：多表連線的問題？ 讓sql從hash join 轉換為nest loop試試，本次sql 取消hint即可，
為了不增加伺服器負擔，
使用explain plan for 方式

SQL> explain plan for select a.hphm,a.wfsj,b.wfsj from BRJLJK.sjs20181022 a
 right join trff_app.vio_violation b on a.hphm=b.hphm 
where (b.wfsj < add_months(a.wfsj, 12) and b.wfsj >add_months(a.wfsj, -12))
 and a.wfsj>to_date('2018-08-01','yyyy-mm-dd')
 and a.wfsj<to_date('2018-09-01','yyyy-mm-dd') order by a.hphm,a.wfsj, b.wfsj;

Explained.

SQL> select * from table(dbms_xplan.display());

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------
Plan hash value: 1015943026
---------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 309 | 10506 | 115K (1)| 00:23:12 |
| 1 | SORT ORDER BY | | 309 | 10506 | 115K (1)| 00:23:12 |
|* 2 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 1 | 17 | 13 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 309 | 10506 | 115K (1)| 00:23:12 |
|* 4 | INDEX FAST FULL SCAN | SJS20181022_IND_HPHM | 10455 | 173K| 277 (2)| 00:00:04 |
|* 5 | INDEX RANGE SCAN | IDX_VIOLATION_HPHM | 12 | | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------

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

2 - filter("B"."WFSJ"<ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),12) AND
"B"."WFSJ">ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),-12))
4 - filter("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
5 - access("A"."HPHM"="B"."HPHM")

21 rows selected.

 

發現nest loop 方式挺快的，繼續測試（上述測試只測試3個欄位）

使用原SQLa+b的兩個表SQL不做變動，執行測試，發現執行計劃未改變；

使用需要優化的SQL文字，刪除hint，進行explain plan for 進行測試，執行計劃未改變

　　

 

　　

　　

 

三、修改SQL

刪除Hint，讓SQL走nest loop 方式，10s內返回結果
SQL> select c.hphm,
        c.ccdjrq,
        c.clpp1,
        c.clxh,
        c.zt,
        c.syr,
        c.wfsj,
        c.wfxw,
        c.dsr,
        c.xxly,
        c.syq,
        c.wfsj1,
        d.wfnr,
        e.dlmc,
        c.xxly1,
        c.dsr1
   from (select 
          a.hphm,
          a.ccdjrq,
          a.clpp1,
          a.clxh,
          a.zt,
          a.syr,
          a.wfsj,
          a.wfxw,
          a.dsr,
          a.xxly,
          a.syq,
          b.wfsj   wfsj1,
          b.wfxw   wfxw1,
          b.wfdd   wfdd1,
          b.xxly   xxly1,
          b.dsr    dsr1
           from BRJLJK.sjs20181022 a
          right join trff_app.vio_violation b
             on a.hphm = b.hphm
          where a.wfsj <> b.wfsj
            and (b.wfsj < add_months(a.wfsj, 12) and
                b.wfsj > add_months(a.wfsj, -12))
            and a.wfsj > to_date('2018-08-01', 'yyyy-mm-dd')
            and a.wfsj < to_date('2018-09-01', 'yyyy-mm-dd')
          order by a.hphm, a.wfsj, b.wfsj) c,
        trff_app.vio_codewfdm d,
        trff_app.frm_roaditem e
  where c.wfxw1 = d.wfxw
    and c.wfdd1 = e.dldm;
52519 rows selected.
Elapsed: 00:00:05.08

Execution Plan
----------------------------------------------------------
Plan hash value: 2181500870

-----------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                    |   309 | 56238 |   136K  (1)| 00:27:24 |
|   1 |  SORT ORDER BY                 |                    |   309 | 56238 |   136K  (1)| 00:27:24 |
|*  2 |   HASH JOIN                    |                    |   309 | 56238 |   136K  (1)| 00:27:24 |
|*  3 |    HASH JOIN                   |                    |   309 | 50985 |   136K  (1)| 00:27:23 |
|*  4 |     TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION      |     1 |    38 |    13   (0)| 00:00:01 |
|   5 |      NESTED LOOPS              |                    |   309 | 37389 |   136K  (1)| 00:27:23 |
|*  6 |       TABLE ACCESS FULL        | SJS20181022        | 10455 |   847K|   891   (2)| 00:00:11 |
|*  7 |       INDEX RANGE SCAN         | IDX_VIOLATION_HPHM |    12 |       |     3   (0)| 00:00:01 |
|   8 |     TABLE ACCESS FULL          | VIO_CODEWFDM       |  1069 | 47036 |    13   (0)| 00:00:01 |
|   9 |    TABLE ACCESS FULL           | FRM_ROADITEM       |  5212 | 88604 |    22   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

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

   2 - access("B"."WFDD"="E"."DLDM")
   3 - access("B"."WFXW"="D"."WFXW")
   4 - filter("A"."WFSJ"<>"B"."WFSJ" AND "B"."WFSJ"<ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),
              12) AND "B"."WFSJ">ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),-12))
   6 - filter("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   7 - access("A"."HPHM"="B"."HPHM")

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     211168  consistent gets
        108  physical reads
        116  redo size
    3555229  bytes sent via SQL*Net to client
      39003  bytes received via SQL*Net from client
       3503  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
      52519  rows processed

　　

 

　　

四、問題總結

 

1）使用Nest loop方式，被驅動表及時迴圈查詢30萬次，比想象中的快很多很多
2）本次sql未優化前走hash join方式的原因是，hint 索引是時間列，
而Nest loop方式需要驅動表的查詢結果輸出身份證，被驅動表拿著身份證，
去被驅動表中索取記錄；驅動表在本次執行計劃無變化，被驅動表從時間欄位索引，轉換走
IDX_VIOLATION_HPHM， 也就是說，由於索引的選擇度的問題，Oracle認為 hash join的連線方式
優於  date索引（hint）找到對應的rowid,然後找到hphm欄位值
3）今後，在使用hint前，通過測試，選擇合適的hint

　　

　　

　　

 

 

　　

相關推薦

hint不當索引，影像多表連線方式，最終導致SQL執行緩慢

需求：一個SQL執行特別慢，無法返回結果，需要進行優化，最終返回結果即可。   一、SQL分析   二、嘗試執行，觀測執行計劃   三、修改SQL   四、問題總結   一、SQL分析 1）SQL文字，執行時間，執行使用者 使用者b

django model filter 條件過濾，及多表連線查詢、反向查詢，某欄位的distinct

1.多表連線查詢：當我知道這點的時候頓時覺得django太NX了。   class A(models.Model):     name = models.CharField(u'名稱')   class B(models.Model):    aa = models.Fo

django ORM model filter 條件過濾，及多表連線查詢、反向查詢，某欄位的distinct

版權歸作者所有，任何形式轉載請聯絡作者。 作者：petanne（來自豆瓣） 來源：https://www.douban.com/note/301166150/ 1.多表連線查詢：感覺django太NX了。   class A(models.Model):     name

Oracle笛卡爾積，分組，多表連線

一  oracle的單行函式        轉換函式        to_date(日期字串,日期格式)  字串的格式必須由第二個引數來判斷                           日期格式 ：                           年 yyyy，

多表連線查詢（內，外，交叉連線）

連線查詢實際上是通過各個表之間共同列的關聯性來查詢資料的,它是關係資料庫查詢最主要的特徵. select 表1.欄位名1，表2.欄位名2，...  from 表1，表2 where 連線條件 SQL-92標準所定義的FROM子句的連線語法格式為：  FROM 表名 join_type 表名 [ON (連線條

SQL----多張表連線查詢，只查出符合條件的資料

SELECT M.*,S.NAME SERVERNAME,W.Name WARENAME from m_system_desktopapp M,base_server S,base_ware W

資料庫的多表連線，自連線，樹狀結構查詢

1.左連線（left join）例如：select * from a left join b on (a.id= b.id and a.level = '1' ) =========>a 表資料全部顯示2.右連線（right join）例如：select * from 

Oracle多表連線,提高效率，效能優化

執行路徑:ORACLE的這個功能大大地提高了SQL的執行效能並節省了記憶體的使用:我們發現,單表資料的統計比多表統計的速度完全是兩個概念.單表統計可能只要0.02秒,但是2張表聯合統計就可能要幾十表了.這是因為ORACLE只對簡單的表提供高速緩衝(cache buffering) ,這個功能並不適用於多表連線

表單驗證，與多語言支持，CI

加載 load for 控制器 cati 驗證 pan conf span 表單驗證將漢化包，復制到application文件夾下的language，然後在config.php中，將語音改為simplified-chinese,和漢化包文件夾的名字一致。 對於隨漢化包帶來

asp.net mvc項目實戰遇見問題及解決方式----ajax請求500錯誤，請求多表數據

導航欄 asp 遇見 mvc 方式 出現 .net alac 利用 ajax請求出現500錯誤——但是想實現的功能是，把一個頁面分成了兩份，點擊右邊導航欄，利用ajax請求，請求數據，在右邊出現相應頁面，當時使用的是partialAction然後出現了這個500錯誤，主要就

Kettle案例總結一—多表連線(記錄集連線)

Kettle是一款國外開源的ETL工具，純java編寫，可以在Window、Linux、Unix上執行，資料抽取高效穩定。 Kettle這個ETL工具集，它允許你管理來自不同資料庫的資料，通過提供一個圖形化的使用者環境來描述你想做什麼，而不是你想怎麼做。 Kettle中有兩種

資料庫sql語句多表連線查詢+group by分組的使用

參考自：https://blog.csdn.net/fly_fly_fly_pig/article/details/81325116 平時用sql查詢經常遇到的問題，這次搜到了一個博主的文章，解決了問題。但是其中的深層原因還沒有想清楚，本文需要完善。 更正前 CREATE VIE

詳解MySQL的多表連線查詢

前期準備工作 在這裡我準備了一個簡單的省市縣的mysql資料庫，進行簡單的案例分析 create table province( pro_id int primary key, pro_name varchar(10) ); insert into provinc

17、多表連線查詢

學習目標： 1、掌握自然連線、左外連線、右外連線和全連線的概念 2、掌握Oracle對自然連線、左外連線、右外連線和全連線的語法的支援 3、熟練掌握多表連線查詢 學習過程： 有時候我們需要從多張表中獲取資料，select語句支援一次性查詢多張表，這些表在記憶體中會做一個“乘法”操

多表連線查詢、子查詢

多表連線查詢 當我們在資料庫的查詢中，可能我們需要的兩個或多個欄位並不存在與一張表中，我們可以通過多表連線查詢的方式進行查詢（雖然我們可以寫不同的幾個語句分開進行查詢，但是這樣會極大的增加我們的程式碼量並且效率較低）。當我們要查詢不同表內的資料時，我們需要將兩個表通過一個欄位來進行連線（一般為主

Mybatis-plus多表關聯查詢，多表分頁查詢

學習plus真的覺得寫程式碼真的越來越舒服了。昨天開始接觸吧，只要學會了多表關聯查詢。plus就能隨意搭配使用了。 關於怎麼搭建的就自行了去研究了哦。這裡直接進入主題。 我用的是springboot+mybatis-plus。新專案我打算以後都是這樣了。   配置一個分頁外掛！ im

MySQL多表連線查詢

多表查詢：當查詢結果來自多張資料表的時，就需要用到連線查詢。 多表連線查詢：會出現笛卡爾積的現象：a表有m行，b表有n行，查詢結果=m*n行，消除笛卡爾積現象就必須加上關聯條件，關聯條件的個數=n個表-1。 多表連線查詢按照能分類為： 1、內連線：      

Django高階進階03--模型的多表連線

Django框架學習03— 一.知識回顧 1.模型 (1)欄位型別 ·AutoField·一個根據實際ID自動增長的IntegerField，通常不指定。如果不指定，一個主鍵欄位將自動新增到模型中 ·CharField(max_length=

Linq 多表連線查詢join

在查詢語言中，通常需要使用聯接操作。在 LINQ 中，可以通過 join 子句實現聯接操作。join 子句可以將來自不同源序列，並且在物件模型中沒有直接關係(資料庫表之間沒有關係)的元素相關聯，唯一的要求是每個源中的元素需要共享某個可以進行比較，以判斷是否相等的值。 在 LINQ&nb

Oracle多表查詢練習，詳細解題步驟（含執行結果）

CREATE TABLE STUDENT (SNO VARCHAR(3) NOT NULL, SNAME VARCHAR(4) NOT NULL, SSEX VARCHAR(2) NOT NULL, SBIRTHDAY DATE, CLASS NUMBER NO