數據庫實驗報告

　題目: 查詢優化 姓名: 李軍毅 日期:2016-5-14 實驗目的 1. 明確查詢優化的重要性; 2. 理解代數優化與物理優化方法; 3. 學習在查詢中使用較優的方法。

　實驗平臺 1. OS: Windows XP 2. DBMS: SQLServer2008、VC6、0(或者 visio studio) 3. IDE: Eclipse 實驗用時: 兩次上機 實驗內容

　 一、 數據庫的恢復操作( 導入數據)

　 1. 在【程序】中打開 Microsoft SQL Server Management Studio 。新建數據庫“ Foodma rtII ”

　2. 在數據庫 FoodmartII 上右鍵單擊, , 選擇【任務】【導入數據】。

　3. 在“導入與導出向導”對話框中, , 數據源選擇“ Microsoft Access ”, , 單擊“文

　件名”后面的【瀏覽】按鈕, , 按您的存儲路徑找到 Foodmart 、 mdb 文件。單擊【下一步】。

　4 4 、在“選擇目標”部分, , 注意目標數據庫的名稱應為剛才建立的“ FoodmartII。

　”。

　5 5 、選擇復制一個或多個數據庫表。

　6 6 、在接下來的對話框中選擇可能用到的數據表, , 根據需要勾選。單擊【下一步】并“立即執行”, , 成功導入數據后可以瞧到如下對話框。單擊【關 閉】按鈕。的 觀察數據庫引擎中的 FoodmartII, 瞧一瞧數據庫中有哪些表, , 表中有哪些數據, , 就是否包含索引, , 就是否建立了視圖？

　二、理解索引對查詢的影響 1 1 、新建查詢, , 在查詢窗口中輸入一個查詢命令。

　2 2 、在【查詢】菜單中選擇【顯示估計的查詢計劃】, , 注意觀察查詢窗口下面的執行計劃窗口。執行該查詢( ( 使用工具欄上的“執行”按鈕或者【查詢】菜單上的“執行”命令 ), 觀察右側【屬性】窗口中“返回的行數”“占用時間”等關鍵信息。

　3 3為 、為 Customer 立 表建立索引。建立 Customer_id 列的非聚集索引。執行查詢, ,在【 屬性】窗口中觀察查詢時間。

　三、 分析查詢條件對查詢執行的影響 1 1 、新建查詢, , 輸入查詢命令, , 再按上面的步驟, , 觀察“估計的查詢計劃”與“占用時間”時間等信息, , 比較查詢條件對查詢執行的影響。

　2 2 、觀察查詢命令, ,在 在 emplyee 立 表建立 salary 列的非聚集索引。再次觀察上面這個查詢命令的查詢計劃與執行情況。

　四、 分析連接條件對連接操作的影響 1 1 、對比下面查詢的查詢計劃與查詢執行情況

　2 2 、在 employee 表上對 employee_id 列建立聚集索引、觀察查詢計劃與執行情況的變化、

　五、 視圖的使用 1. 執行下面的查詢命令, , 觀察 查詢計劃與執行情況。

　2. 建立視圖“ cust_prod_sales ”, ,由 由 product,customer , sales_fact_1998 三

　個表組成, , 其中包含查詢常用的列( (詢 選取的列可以多于查詢 Q51), 再執行下面的查詢, , 比較兩個查詢的執行情況。

　六、 查詢優化測試 1. 數據準備, , 導入 TPCH 數據集。數據導入方法同前面 Footmark 的導入類似。

　2. 對以下查詢進行優化, , 寫出您的優化方法 、

　實際執行這個查詢 , 記錄您的執行時間( ( 毫秒) ) 、

　實驗中出現的問題 實驗內容

　 一、數據庫的恢復操作( 導入數據)

　 1 1 、在【程序】中打開 Microsoft SQL Server Management Studio 。新建數據庫“ FoodmartII ”

　打開 Microsoft SQL Server Management Studio, 如圖: :

　 新建數據庫“ FoodmartII ”, , 如圖: :

　 2. 在數據庫 FoodmartII 上右鍵單擊, , 選擇【任務】【導入數據】。

　如圖: :

　 3. 在“導入與導出向導”對話框中, , 數據源選擇“ Microsoft Access ”, , 單擊“文件名”后面的【瀏覽】按鈕, , 按您的存儲路徑找到 Foodmart、 、 mdb 文件。單擊【下一步】。

　如圖, , 選擇“ Microsoft Access ”, , 找到 Foodmart 、 mdb 文件: :

　 4. 在“選擇目標”部分, , 注意目標數據庫的名稱應為剛才建立的“ FoodmartII。

　”。

　如圖, , 選擇我剛剛建立的“ FoodmartII ”數據庫: :

　 5. 選擇復制一個或多個數據庫表。

　如圖, , 勾選“復制一個或多個數據庫表”: :

　 在接下來的對話框中選擇可能用到的數據表, , 根據需要勾選。我選擇了全部的數據表, , 并單擊下一步, , 如圖: :

　 單擊【下一步】后, , 選擇“立即執行”, , 如圖: :

　 如下圖, 可瞧到導入成功, 單擊【關閉】按鈕:

　觀察數據庫引擎中的 FoodmartII, 我們可以瞧到數據庫中有哪些表, , 例如t account 表y ,category 表y ,currency 表等, , 如圖: :

　 我們點擊 y cureency 表中的索引, , 可以瞧到初始時并沒有任何索引, , 如圖: :

　 右鍵 y cuurency 表, , 選擇“編輯前 0 200 行”, , 可以瞧到表中的數據, , 如圖: :

　 二、理解索引對查詢的影響 1 1 、新建查詢, , 在查詢窗口中輸入一個查詢命令。

　select customer_id from customer where customer_id>6000 2. 在【查詢】菜單 中選擇【顯示估計的查詢計劃】, , 注意觀察查詢窗口下面的執行計劃窗口。

　如圖, 表掃描占100%:

　 執行該查詢( ( 使用工具欄上的“執行”按鈕或者【查詢】菜單上的“執行”命令 ),觀察右側【屬性】窗口中“返回的行數”“占用時間”等關鍵信息。

　如圖, , 我們可以瞧到返回的行數為 1 4281 行, , 占用的時間大約為 2 2 秒多: :

　 3.為 為 Customer 表建立索引。建立 Customer_id 列的非聚集索引, , 如下圖所示。

　輸入命令: :

　create index ID_nonclus

　 on customer(customer_id); 建立非聚集索引: : 在 在 r customer 表中查瞧索引, , 可以瞧到我們已經建立好的非聚集索引, , 如圖: :

　 建立好索引后, , 仍使用如下查詢命令: :

　select customer_id

　from customer where customer_id>6000 在菜單欄中的“查詢”下點擊“顯示估計的執行計劃”, , 觀察新的查詢計劃, , 如圖, , 新的執行計劃索引查找占 100%:

　 執行該查詢, , 在【屬性】窗口中觀察查詢時間。如圖, , 我們可以瞧到, , 建立好索引再進行查詢, , 占用時間減少到不足 1 1 秒: :

　三、分析查詢條件對查詢執行的影 響 1 1 、新建查詢, , 輸入查詢命令, , 再按上面的步驟, , 觀察“估計的查詢計劃”與“占用時間”時間等信息, , 比較查詢條件對查詢執行的影響。

　Q1:

　 select customer_id

　 from customer

　 where customer_id=2621; 初始情況下未建立索引, , 輸入命令后, , 在菜單欄中的“查詢”項下選擇“顯示估計的執行計劃”, , 表掃描占 100%:

　 然后點擊執行, , 在屬性欄中可以瞧到, ,為 返回的行數為 1,為 占用的時間為 7 7 秒多, , 如圖: :

　 然后建立非聚集索引, , 在新建查詢中輸入上述命令, , 選擇“顯示估 計的執行計劃”, ,如圖, , 索引查找占 100%:

　 ” 點擊“執行”, , 在屬性欄中可以瞧到, , 返回的行數為 1, 占用的時間為 2 2 秒多, , 如圖: :

　 再把 where 條件分別改寫為: : customer_id> 2621 與

　customer_id<> 2621, 觀察她們有什么異同。總結查詢命令書寫的經驗。

　Q2:

　 select customer_id

　from customer

　where customer_id>2621; 顯示估計的執行計劃, , 表掃描占 100%:

　 點擊“執行”, , 在屬性 欄中可以瞧到, , 返回的行數為 0 7650 行, , 占用的時間為 3 3 秒多, , 如圖: :

　 建立非聚集索引后, , 顯示估計的執行計劃, , 可以瞧到, , 索引查找占 100%:

　 點擊“執行”后, , 在屬性欄中可以瞧到返回的行數為 0 7650 行, , 占用的時間為 2 2 秒多, , 如圖: :

　 Q3:

　select customer_id

　from customer

　 where customer_id!=2621; 這里我使用的就是 != 而不就是 <>, 顯示估計的執行計劃, , 表掃描占 100%, 如圖: :

　 點擊“執行”, , 在屬性欄中可以瞧到, , 返 回的行數為 0 10260 行, , 占用時間為 3 3 秒多, ,如圖: :

　建立索引后, , 顯示估計的執行計劃, , 可以瞧到, , 索引掃描占100%:

　點擊“執行”, , 屬性欄中可以瞧到, , 返回的行數為 0 10260 行, , 占用的時間為 2 2 秒多, ,如圖: :

　可以知道, , 不等于操作符就是永遠用不到索引的, , 索引只能告訴什么存在于表中, ,而不能告訴什么不存在于表中, , 當數據庫遇到“！= = ”, , “ <> ”時, , 會轉而用全表掃描, ,對 對 0 a<>0 的條件應寫為 a<0 or a>0 、

　2. 觀察下面的查詢命令: :

　 select full_name,salary

　from employee

　where salary>30000; 在未建立索引的情況顯示估計的執行計劃, , 表掃描占 100%, 如圖: :

　 返回行數為 8 8 行, , 時間大約 3 3 秒多, , 如圖: :

　 在 在 emplyee 立 表建立 salary 列的非聚集索引。再次觀察上面這個查詢命令的查詢計劃與執行情況。D RID 查找占 87%, 索引查找占 13%, 如圖: :

　 執行后, , 返回行數為 8, 占用時間為 2 2 秒多, , 如圖: :

　 （1 1 ）

　請寫出您對以上內容的分析或得到的經驗。

　盡量少用不等于查詢條件

　當需要查找的數據特別多時, , 使用全表掃描或許比索引掃描還要好

　( ( 2) 試一試 , 您還能得到哪些查詢命令書寫的經驗 ? ( 不同查詢語句導致不同查詢計劃) )

　 量 當插入的數據為數據表的記錄數量 10% 以上時, 首先需要刪除該表的索引來提高數據的插入效率, 當數據全部插入后再建立索引。

　避免在索引列上使用函數或計算, 在where 子句中, 如果索引列就是函數的一部分, 優化器將不使用索引而使用全表掃描, 舉例: 低效:select * from table where salary*12>25000 高效:select * from table where salary>25000/12

　索引列上用>= 替代>, 舉例: 高效:select * from table where Deptno>=4 低效:select * from table where Deptno>3 四、分析連接條件對連接操作的影響 1 1 、對比下面查詢的查詢計劃與查詢執行情況

　Q41: Select employee、employee_id,full_name,employee、salary,pay_date,

　 salary_paid from employee,salary 顯示估計的執行計劃, , 如圖, , 嵌套循環 96%, , 表假脫機 4%:

　 Q42: select employee、employee_id,full_name,employee、salary,pay_date, salary_paid

　from employee,salary where employee、employee_id=salary、employee_id 顯示估計的執行計劃, , 哈希匹配 50%, 表掃描各占 41%與 與 9%:

　 點擊“執行”, , 返回行數為 2 21252 行, , 占用時間 3 3 秒多: :

　 Q43: Select employee、employee_id,full_name,employee、salary,pay_date,salary_paid from employee,salary where employee、employee_id>salary、employee_id 顯示估計的執行計劃, , 嵌套循環占 73%, 索引假脫機 27%:

　 但就是, 點擊“執行”, 因為數據溢出, 無法完成。

　2.在 在 employee 對 表上對 employee_id 列建立聚集索引、觀察查詢計劃與執行情況的變化、

　create CLUSTERED index ID_clus on employee(employee_id); 如圖: :

　Q41: select employee、employee_id,full_name,employee、salary,pay_date, salary_paid from employee,salary 顯示估計的執行計劃, , 嵌套循環占 96%, 表假脫機 4%:

　 Q42: select employee、employee_id,full_name,employee、salary,pay_date, salary_paid from employee,salary where employee、employee_id=salary、employee_id 顯示估計的執行計劃, , 哈希匹配 50%, 聚集索引掃描 9%, 表掃描 41%:

　 點擊“執行”, , 返回行數為 2 21252 行, , 占用時間為 0 0 、0 320 秒: :

　 Q43: select employee、employee_id,full_name,employee、salary,pay_date,salary_paid

　from employee,salary where employee、employee_id>salary、employee_id 顯示估計的執行計劃, , 嵌套循環 73%, 索引假脫機 27%:

　 同樣因為數據溢出無法完成執行。

　分析以上內容, , 總結您的查詢優化經驗。

　索引分為聚集索引與非聚集索引兩種。

　聚集索引就就是物理索引, , 也就就是數據的物理存儲順序, , 聚集索引的葉子節點就就是數據行本身, , 含有聚集索引的表, , 它的數據行的組織方式, , 就是跟聚集索引的順序就是一致的, , 一張表里, , 只能有一個聚集索引, , 決定著數據行的組織方式。

　非聚集索引就是邏輯索引, , 它跟數據的組織順序就是毫無關系的, , 用一系列指針來指向數據行, , 從而描述數據行的位置。

　聚集 索引的最大優勢就就是大范圍數據查詢有著較高的速率, , 能以最快的速度縮小查詢范圍, , 以最快的速度進行字段排序。聚集索引字段選擇優先級: : 時間字段 >> 會進行大范圍查詢的列 >> 具有唯一值的有實際意義的字段 >> 自增列ID 。

　1 1 、時間字段: : 若表里面有時間列, , 并且時間就是按照數據插入順序增長時

　( ( 時間無需唯一即可有重復值, , 哪怕就是大范圍重復 ), 建議采用時間列作為聚集索引的第一選擇。理由: : 聚集索引有一個巨大的優勢就就是進行大范圍數據查找, ,而且這個優勢會隨著數據量的增加而越來越明顯, , 一般來說我們需要進行大數據量范圍查詢時都會用時間 列圍作為篩選條件, , 由于聚集索引不存在書簽查找而且可以進行連續掃描, , 因此查詢速度會非?？臁r間列數據最好就是順序插入的這樣可以盡量減少磁盤碎片, , 就是數據存儲相對集中, , 便于連續數據讀取。

　2 2 、會進行大范圍查詢的列: : 若表里面沒有時間字段或者時間字段不適合做聚集索引, , 可以選擇那些在建表時就明確知道會經常進行大范圍數據篩選的列, ,而且最好就是選擇性較低的列( ( 即有較多重復值的列, , 性別這種列不算啦 ), 如有必要可以使用組合索引。理由: : 聚集索引在數據查詢的優勢主要在于范圍數據查找, , 把聚集索引弄成唯一的把這個大好優勢給白白浪費了 。

　3 3 、具有唯一值的有實際意義的字段: :件 若找不到適合條件 1 1 、2 2 的列, , 那還就是乖乖的把聚集索引列建立在唯一列上吧, , 最好找那種有實際意義的具有唯一性的列, , 比如訂單表可以用訂單號作聚集索引, , 訂單明細表使用訂單號與產品編號做聯合聚集索引。理由: : 找不到合適的時間字段與較低選擇性字段的話, , 把主鍵建成聚集索引就是我們大多情況下的選擇。

　這里建議把唯一性的聚集索引順便建成主鍵, , 與編碼時方法、變量命名一樣, ,推薦列名自解釋, , 即瞧到列名就知道它就就是主鍵, , 省得您再去猜, , 比如訂單表您來個自增 D ID 列做主鍵, , 再建一個 e OrderCode 列 做訂單號, , 用這個表時您得懷疑個 這個 e OrderCode 就是不就是唯一的呢, , 有沒有建立唯一約束呢, , 同理在訂單明細表來個自增列 D ID 也會產生如此疑問, , 產生疑問還就是小事, , 若就是您忘記了在應該唯一的列上建立約束, , 沒準哪天程序控制不好給您個巨大的驚喜。

　4. 自增列 ID: 前面3 3 中條件都找不到合適的列了還就是使用我們的神器自增列 列 D ID 吧, , 自增列 D ID 也就是我們使用最多的主鍵( ( 順便也就成聚集索引了 ), 而且能較好滿足我們大多數需求。自增 D ID 列堪稱無所不能t ,int 類型只占用 4 4 個字節完全滿足窄索引要求, , 絕對的順序存儲可以有效降低索引碎片, , 完 全符合我們的見表習慣, , 有用沒用來個自增 D ID 列做主鍵總就是沒錯的。

　與聚集索引不同, , 非聚集索引可以建立多個, , 這也給我們帶來了很大的靈活, ,畢竟聚集索引就那么一個不可能靠它滿足所有需求, , 更多的我們得依賴非聚集索引。但就是, , 建立索引就是有代價的, , 任何涉及到索引列的數據修改都會導致索引的修改, , 索引越多數據的曾、刪、改的額外代價也就越大。對于非聚集索引來說, , 我們的目標就是用盡可能少的索引覆蓋盡可能多的查詢。

　非聚集索引的列選擇順序( ( 組合索引 ): 經常被使用為查詢條件列 >> 具有較高選擇性的列( ( 選擇性越高越好, , 唯一最好 )>> 經常排序的列

　1 1 、經常被使用為查詢條件列: : 我們的查詢千變萬化, , 建立索引時要首先考慮有哪些列被經常性的用于各種查詢, , 把使用頻率較高的列作為組合索引的第一列( ( 先導列 ), 若一個查詢中沒有用到組合索引中的先導列, , 多數情況下這個索引就不會被使用, , 因此為了盡可能多的復用組合索引把使用較多的查詢列作為組合索引的第一列吧。( ( 關于這點對于聚集索引的組合索引同樣適用) )

　2 2 、具有較高選擇性的列: : 這點很簡單盡量使用高選擇性列作為先導列, , 如果可以通過第一個條件過濾( ( 隨便什么判定邏輯= = 、> > 、< < 、 like), 只要 能大幅減少數據范圍, , 就把它作為先導列。

　3 3件 、條件 1 1 、2 2 、3 3 都確定不了時那就用經常被排序的列吧, , 我們的很多操作都需要先進行排序才可以進行進一步查詢, , 比如 e group by,like 等操作都就是要先進行排序操作才可以完成下一步查詢。

　五、視圖的使用 1 1 、執行下面的查詢命令, , 觀察查詢計劃與執行情況。

　Q51: select lname,fname,brand_name,product_name from sales_fact_1998,product,customer where customer、customer_id=sales_fact_1998、customer_id and product、product_id=sales_fact_1998、product_id and sales_fact_1998、customer_id=9143 顯示估計的執行計劃, , 哈希匹配 7%, 表掃描 67%, 嵌套循環 1%, 表掃描 23%, 表掃描2%:

　 點擊“執行”, , 返回的行數為 7 147 行, , 占用時間為 2 2 秒多: :

　 2. 建立視圖“ cust_prod_sales ”, ,由 由 product,customer , sales_fact_1998 三個 表組成, , 其中包含查詢常用的列( ( 選取的列可以多于查詢 Q51), 再執行下面的查詢。

　建立視圖: :

　create view cust_prod_sales

　as select lname,fname,brand_name,product_name,customer、customer_id from sales_fact_1998,product,customer; 輸入查詢命令: Q52: select lname,fname,brand_name,product_name from cust_prod_sales where customer_id=9143 顯示估計的執行計劃, , 嵌套循環 98%, 行計數假脫機 2%:

　 同樣因為數據溢出, 無法完成執行。

　請寫出您對以上內容的分析與得到的經驗。

　建立普通的視圖對查詢并沒有太大的作用, 因為對視圖的查詢最終也要轉化為對基本表的查詢, 視圖的使用只就是可以把表隱藏起來, 但就是, 在視圖上建立索引卻可以加快查詢速度, 但會增加開銷。

　六、查詢優化測試 1 1 、數據準備, , 導入 TPCH 數據集。數據導入方法同前面 Footmark 的導入類似。

　立 建立 TPCH 數據庫, 如圖:

　右鍵單擊 H TPCH 數據庫, , 選擇任務中的導入數據庫: :

　 導入數據時, , “數據源”選擇“平面文件”, , 通過瀏覽指定文件夾與文件名( ( 類型選擇”所有文件” ), 如圖: :

　 單擊左側“數據源”列表中“列”項目, , 指定”

　列分隔符”為“豎線”, , 單擊”重置列”按鈕, , 觀察”預覽行”窗口顯示的數據格式就是否正確。如下圖: :

　 如下圖, , 導入 R CUSTOMER 表: :

　 導入成功: 在管理欄中可以瞧到 R CUSTOMER 表的各列名及其屬性: :

　 導入 M LINEITEM 表: :

　 導入成功: :

　 在管理欄中可以瞧到 M LINEITEM 表的各列名及其屬性: :

　 導入 NAN TION 表: :

　 導入成功:

　在管理欄中可以瞧到 N NATION 表的各列名及其屬性: :

　 導入 R ORDER 表: :

　 導入成功:

　 在管理欄中可以瞧到 R ORDER 表的各列名及其屬性: :

　 導入 T PART 表: :

　 導入成功:

　在管理欄中可以瞧到 T PART 表的各列名及其屬性: :

　 導入 P PARTSUPP 表: :

　 導入成功:

　 在管理欄中可以瞧到 P PARTSUPP 表的各列名及其屬性: :

　 導入 N REGION 表: :

　 導入成功:

　在管理欄中可以瞧到 N REGION 表的各列名及其屬性: :

　 導入 R SUPPLIER 表: :

　 導入 成功:

　 在管理欄中可以瞧到 R SUPPLIER 表的各列名及其屬性: :

　 2. 對以下查詢進行優化, , 寫出您的優化方法、

　實際執行這個查詢 , 記錄您的執行時間( ( 毫秒) ) 、

　Q1: select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty,

　sum(l_extendedprice) as sum_base_price, sum(l_extendedprice*(1-l_discount)) as sum_disc_price, sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_order from lineitem where l_shipdate <= "1998-12-01" group by l_returnflag, l_linestatus order by l_returnflag, l_linestatus; 首先在未對表進行任何操作的情況下執行,為 返回行數為 4 行,為 占用時間為 6 秒多:

　 然后, ,在 在 m lineitem 表的 s l_returnflag,l_linestatus 列上建立非聚集索引: :

　create index lndex_l on lineitem(l_returnflag,l_linestatus); 執行查詢, , 返回行數為4 4 列, , 占用時間為5 5 秒多: :

　對這個查詢, 我嘗試了建立臨時表, 建立聚集索引的方法,。

　均會導致總時間更多。

　Q2:

　select n_name, sum(l_extendedprice * (1 - l_discount)) as revenue from customer,orders,lineitem,supplier,nation,region where c_custkey = o_custkey and l_orderkey = o_orderkey and l_suppkey = s_suppkey and c_nationkey = s_nationkey and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = "ASIA" and o_orderdate >= "1994-01-01" and o_orderdate < "1995-01-01" group by n_name order by revenue desc; 執行查詢, , 返回行數為5 5 行, , 占用時間為3 3 秒多: :

　 然后在各表上建立索引: create index index_c on customer(c_custkey,c_nationkey); create index index_o on orders(o_custkey,o_orderkey,o_orderdate); create index index_l on lineitem(l_orderkey,l_suppkey); create index index_s on supplier(s_suppkey,s_nationkey); create index index_n on nation(n_nationkey,n_regionkey); create index index_r on region(r_regionkey,r_name);

　執行查詢, , 返回行數為5 5 行, , 占用時間為1 1 秒多: :

　 Q3: select 100、00 * sum(case when p_type like "PROMO%" then l_extendedprice*(1-l_discount) else 0 end) / sum(l_extendedprice * (1 - l_discount)) as promo_revenue from lineitem,part where l_partkey = p_partkey

　and l_shipdate >= "1995-09-01" and l_shipdate < "1995-10-1" 執行查詢, , 返回行數為1 1 行, , 占用時間為2 2 秒多: :

　 然后在各表的相應列上建立索引: create index index_l On lineitem(l_extendedprice,

　l_discount,

　l_partkey,

　l_shipdate

　) create index index_p On part(p_type,

　p_partkey

　) 執行查詢, , 返回行數為1 1 行, , 占用時間不到1 1秒: :

　實驗中出 現的問題 1. 在導入數據表, , 修改列名及屬性時, , 字符串類型默認為寬度 50, 忘記修改, , 導致數據導入失敗

　2. 不知道如何建立臨時表, , 后經過查詢得知

　3. 有幾個查詢因為數據溢出導致執行無法完成

推薦訪問： 概論 優化 實驗