大數據處理 1、資料庫 垂直拆分:根據業務把表放到不同的資料庫,解決表之間的IO競爭 水平拆分:根據某種規則把單表數據分成多張表存儲,解決單表數據量大的問題 索引:根據業務場景創建合理的索引,如果數據量很小建議使用索引(300條以內) 索引使用場景: 動作描述 聚集索引 非聚集索引 主鍵列 是 是 ...
大數據處理
1、資料庫
垂直拆分:根據業務把表放到不同的資料庫,解決表之間的IO競爭
水平拆分:根據某種規則把單表數據分成多張表存儲,解決單表數據量大的問題
索引:根據業務場景創建合理的索引,如果數據量很小建議使用索引(300條以內)
索引使用場景:
動作描述 |
聚集索引 |
非聚集索引 |
主鍵列 |
是 |
是 |
外鍵列 |
是 |
是 |
列經常被分組排序 |
是 |
是 |
返回某範圍內的數據 |
是 |
否 |
一個或極少不同值 |
否 |
否 |
小數目的不同值 |
是 |
否 |
大數目的不同值 |
否 |
是 |
頻繁更新的列 |
否 |
是 |
頻繁修改索引列 |
否 |
是 |
分離活躍數據:把常用的數據和不常用的數據分離,例如活躍用戶和不活躍用戶
讀寫分離:寫用主庫,讀用從庫
其它:表結構優化、SQL語句優化
2、緩存
讀數據時先從緩存中取,命中不到再讀庫
3、集群
使用hadoop做集群,可以同時處理相同的數據
高併發處理
1、硬體
集群:多台伺服器分流 ,靜態資源集群和動態資源集群,需要考慮session同步問題
CDN:使用CDN存放靜態資源
反向代理:用別的伺服器代理處理
2、軟體
動靜分離:靜態資源和動態資源分離,把靜態資源放到單獨的伺服器
頁面緩存:經常訪問的頁面可以做成靜態頁面放到緩存里
縮短請求路徑:縮短請求服務的路徑,便於解析
批量讀取:多個請求合併到一起請求,減少資料庫訪問次數
延遲修改:把多次修改請求先放到緩存中,然後同步到庫
Sql語句優化:
- Where語句中不要出現Null、or、!=、<>、in、not in否則會避開索引進行全表掃描
- 儘量避免在索引過的字元數據中,使用非打頭字母搜索,否則會避開索引進行全表掃如:SELECT * FROM T1 WHERE NAME LIKE ‘%L%’
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’
- 必要時強制查詢優化器使用某個索引,如在 where 子句中使用參數,也會導致全表掃描如:select id from t where num=@num
可以改為強制查詢使用索引:
select id from t with(index(索引名)) where num=@num
- 應儘量避免在 where 子句中對欄位進行表達式操作,這將導致引擎放棄使用索引而進行全表掃描。如:
SELECT * FROM T1 WHERE F1/2=100
應改為:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’
應改為:
SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
應改為:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即:任何對列的操作都將導致表掃描,它包括資料庫函數、計算表達式等等,查詢時要儘可能將操作移至等號右邊。
- 應儘量避免在where子句中對欄位進行函數操作,這將導致引擎放棄使用索引而進行全表掃描。如:
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' - 不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算,否則系統將可能無法正確使用索引。
- 在使用索引欄位作為條件時,如果該索引是複合索引,那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引,否則該索引將不會被使用,並且應儘可能的讓欄位順序與索引順序相一致。
- 很多時候用 exists是一個好的選擇:
elect num from a where num in(select num from b)
用下麵的語句替換:
select num from a where exists(select 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
兩者產生相同的結果,但是後者的效率顯然要高於前者。因為後者不會產生大量鎖定的表掃描或是索引掃描。
如果你想校驗表裡是否存在某條紀錄,不要用count(*)那樣效率很低,而且浪費伺服器資源。可以用EXISTS代替。如:
IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx')
可以寫成:
IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')
經常需要寫一個T_SQL語句比較一個父結果集和子結果集,從而找到是否存在在父結果集中有而在子結果集中沒有的記錄,如:
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用別名a代替
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)
SELECT a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
三種寫法都可以得到同樣正確的結果,但是效率依次降低。
- 儘量使用表變數來代替臨時表。如果表變數包含大量數據,請註意索引非常有限(只有主鍵索引)。
- 避免頻繁創建和刪除臨時表,以減少系統表資源的消耗。
- 在新建臨時表時,如果一次性插入數據量很大,那麼可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果數據量不大,為了緩和系統表的資源,應先create table,然後insert。
- 如果使用到了臨時表,在存儲過程的最後務必將所有的臨時表顯式刪除,先 truncate table ,然後 drop table ,這樣可以避免系統表的較長時間鎖定。
- 臨時表並不是不可使用,適當地使用它們可以使某些常式更有效,例如,當需要重覆引用大型表或常用表中的某個數據集時。但是,對於一次性事件,最好使用導出表。
- 在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ,在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
- 儘量避免大事務操作,提高系統併發能力。
- 儘量避免向客戶端返回大數據量,若數據量過大,應該考慮相應需求是否合理。
- 避免使用不相容的數據類型。例如float和int、char和varchar、binary和varbinary是不相容的。數據類型的不相容可能使優化器無法執行一些本來可以進行的優化操作。例如:
SELECT name FROM employee WHERE salary > 60000
在這條語句中,如salary欄位是money型的,則優化器很難對其進行優化,因為60000是個整型數。我們應當在編程時將整型轉化成為錢幣型,而不要等到運行時轉化。 - 充分利用連接條件,在某種情況下,兩個表之間可能不只一個的連接條件,這時在 WHERE 子句中將連接條件完整的寫上,有可能大大提高查詢速度。
例:
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO
第二句將比第一句執行快得多。 - 使用視圖加速查詢
把表的一個子集進行排序並創建視圖,有時能加速查詢。它有助於避免多重排序 操作,而且在其他方面還能簡化優化器的工作 - 能用DISTINCT的就不用GROUP BY
- 能用UNION ALL就不要用UNION
- 儘量不要用SELECT INTO語句。
SELECT INOT 語句會導致表鎖定,阻止其他用戶訪問該表。 - 儘量避免使用游標,因為游標的效率較差