一个大数据量表访问优化--联动下拉框查询优化
問題描述
有一數據表(產品標簽表,每個產品一個唯一的SN,每月100萬左右),查詢界面上有2個聯動下拉框,【規格】____,【批次】______
用戶選擇一個規格后(目前200來個規格),列出該規格下達過的生產計劃的批次。
原有方式
規格列表
select 規格 from 標簽表 group by 規格
根據規格獲取批次
select 批次 From 標簽表 Where 規格=‘某一規格’ group by 批次
由于要進行全表掃描,當數據到50萬以上時速度就明顯慢下來了,而到200萬時上面任意一個查詢都要1分鐘左右。
?
解決方案
方案1:建立索引
組合“規格,批次”建立一個索引(批次單獨建立了聚集索引)。
問題,因為一條記錄對應一個索引條目,所以這個方案需要很多額外的空間,另外原來表上已經有3個索引了,過多的索引會導致更新與插入性能下降,并且死鎖風險會提高,作為流水線上使用的模塊,性是有要求的。
方案2:建立一張規格批次對應表,記錄規格跟批次的對關系
由于規格200來個并且比較穩定,批次一月也就100來個,而且這100個批次只分配給二三十個批次所以這兩者的組合一個月也就1500-2000條左右。
考慮使用規格批次對應表后,進一步就是確定怎么維護對應表的數據,
方式一,就是每次生產任務分解生成標簽的同時更新規格批次對應表(即標簽表記錄的增刪改時做對應的操作)。考慮那個任務分解代碼已經夠糾結了,不打算大量修改程序代碼。
方式二,數據庫建立個作業,定期增量更新
生產任務會做調整(刪除或更改),不過變動幾率不高,而且多數改動都在上班時間內任務下達后1-2小時內修改(隔天的基本已經在執行狀態或已經完成了)
所以作業安排在晚上12點進行,而作業執行點之后標簽表新增記錄的規格與批次的對應關系則沒包括在對應表中,因此下拉框的查詢結果來自兩部,作業執行點前的規格批次對應關系來自對應表,而作業執行點后規格批次對應關系則直接查詢標簽表,由于每次作業執行點都記錄當前統計時最大的記錄ID號,因此查詢標簽表時會使用如下的查詢語句:
Select? 批次 From 標簽表 Where 規格='某一規格' And Id>xxxx ,由于在Id上建了索引,而每天心記錄在3,4萬條,所以這個查詢在執行時間上基本穩定。
完成的代碼類似下面:
注意點:
上面采用了動態SQL來執行包含"?Id>='+cast(@MaxLbLId as nvarchar(50))+" 的語句來獲取標簽表中的規格批次對應關系,如果不采用動態SQL,直接使用
Id>@MaxLblId的條件,那么由于是存儲過程MSSQL查詢優化器不清楚MaxLblId可能是多少,而忽略Id上已建的索引,而進行全表掃描。
兩者的執行過程如下圖:
(靜態SQL語句)
(動態SQL語句)
作業任務代碼:
?
轉載于:https://www.cnblogs.com/wdfrog/archive/2013/03/03/2941302.html
總結
以上是生活随笔為你收集整理的一个大数据量表访问优化--联动下拉框查询优化的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 用python扩展snmp
- 下一篇: Ubuntu 12.04安装Micros