MySQL百萬級數據庫優化方案

首先聲明是轉的,感受寫的很細,原文連接:http://simpleframework.net/blog/v/7881.htmlhtml


1.對查詢進行優化,應儘可能避免全表掃描,首先應考慮在 where 及 order by 涉及的列上創建索引。mysql

2.應儘可能避免在 where 子句中對字段進行 null 值判斷,不然將致使引擎放棄使用索引而進行全表掃描,如:sql

select id from t where num is null安全

能夠在num上設置默認值0,確保表中num列沒有null值,而後這樣查詢:併發

select id from t where num=0ide

3.應儘可能避免在 where 子句中使用!=或<>操做符,不然將引擎放棄使用索引而進行全表掃描。函數

4.應儘可能避免在 where 子句中使用 or 來鏈接條件,不然將致使引擎放棄使用索引而進行全表掃描,如:性能

select id from t where num=10 or num=20測試

能夠這樣查詢:大數據

select id from t where num=10

union all

select id from t where num=20

5.in 和 not in 也要慎用,不然會致使全表掃描,如:

select id from t where num in(1,2,3)

對於連續的數值,能用 between 就不要用 in 了:

select id from t where num between 1 and 3

6.下面的查詢也將致使全表掃描:

select id from t where name like ‘%abc%’

若要提升效率,能夠考慮全文檢索。

7.若是在 where 子句中使用參數,也會致使全表掃描。由於SQL只有在運行時纔會解析局部變量,但優化程序不能將訪問計劃的選擇推遲到運行時;它必須在編譯時進行選擇。然 而,若是在編譯時創建訪問計劃,變量的值仍是未知的,於是沒法做爲索引選擇的輸入項。以下面語句將進行全表掃描:

select id from t where num=@num <mailto:num=@num>

能夠改成強制查詢使用索引:

select id from t with(index(索引名)) where num=@num <mailto:num=@num>

8.應儘可能避免在 where 子句中對字段進行表達式操做,這將致使引擎放棄使用索引而進行全表掃描。如:

select id from t where num/2=100

應改成:

select id from t where num=100*2

9.應儘可能避免在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′

10.不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算,不然系統將可能沒法正確使用索引。

11.在使用索引字段做爲條件時,若是該索引是複合索引,那麼必須使用到該索引中的第一個字段做爲條件時才能保證系統使用該索引,不然該索引將不會 被使用,而且應儘量的讓字段順序與索引順序相一致。

12.不要寫一些沒有意義的查詢,如須要生成一個空表結構:

select col1,col2 into #t from t where 1=0

這類代碼不會返回任何結果集,可是會消耗系統資源的,應改爲這樣:

create table #t(…)

13.不少時候用 exists 代替 in 是一個好的選擇:

select num from a where num in(select num from b)

用下面的語句替換:

select num from a where exists(select 1 from b where num=a.num)

14.並非全部索引對查詢都有效,SQL是根據表中數據來進行查詢優化的,當索引列有大量數據重複時,SQL查詢可能不會去利用索引,如一表中有 字段sex,male、female幾乎各一半,那麼即便在sex上建了索引也對查詢效

率起不了做用。

15.索引並非越多越好,索引當然能夠提升相應的 select 的效率,但同時也下降了 insert 及 update 的效率,由於 insert 或 update 時有可能會重建索引,因此怎樣建索引須要慎重考慮,視具體狀況而定。一個表的索引數最好不要超過6個,若太多則應考慮一些不常使用到的列上建的索引是否有 必要。

16.應儘量的避免更新 clustered 索引數據列,由於 clustered 索引數據列的順序就是表記錄的物理存儲順序,一旦該列值改變將致使整個表記錄的順序的調整,會耗費至關大的資源。若應用系統須要頻繁更新 clustered 索引數據列,那麼須要考慮是否應將該索引建爲 clustered 索引。

17.儘可能使用數字型字段,若只含數值信息的字段儘可能不要設計爲字符型,這會下降查詢和鏈接的性能,並會增長存儲開銷。這是由於引擎在處理查詢和連 接時會逐個比較字符串中每個字符,而對於數字型而言只須要比較一次就夠了。

18.儘量的使用 varchar/nvarchar 代替 char/nchar ,由於首先變長字段存儲空間小,能夠節省存儲空間,其次對於查詢來講,在一個相對較小的字段內搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ,用具體的字段列表代替「*」,不要返回用不到的任何字段。

20.儘可能使用表變量來代替臨時表。若是表變量包含大量數據,請注意索引很是有限(只有主鍵索引)。

21.避免頻繁建立和刪除臨時表,以減小系統表資源的消耗。

22.臨時表並非不可以使用,適當地使用它們可使某些例程更有效,例如,當須要重複引用大型表或經常使用表中的某個數據集時。可是,對於一次性事件, 最好使用導出表。

23.在新建臨時表時,若是一次性插入數據量很大,那麼可使用 select into 代替 create table,避免形成大量 log ,以提升速度;若是數據量不大,爲了緩和系統表的資源,應先create table,而後insert。

24.若是使用到了臨時表,在存儲過程的最後務必將全部的臨時表顯式刪除,先 truncate table ,而後 drop table ,這樣能夠避免系統表的較長時間鎖定。

25.儘可能避免使用遊標,由於遊標的效率較差,若是遊標操做的數據超過1萬行,那麼就應該考慮改寫。

26.使用基於遊標的方法或臨時表方法以前,應先尋找基於集的解決方案來解決問題,基於集的方法一般更有效。

27.與臨時表同樣,遊標並非不可以使用。對小型數據集使用 FAST_FORWARD 遊標一般要優於其餘逐行處理方法,尤爲是在必須引用幾個表才能得到所需的數據時。在結果集中包括「合計」的例程一般要比使用遊標執行的速度快。若是開發時 間容許,基於遊標的方法和基於集的方法均可以嘗試一下,看哪種方法的效果更好。

28.在全部的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ,在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每一個語句後向客戶端發送 DONE_IN_PROC 消息。

29.儘可能避免大事務操做,提升系統併發能力。

30.儘可能避免向客戶端返回大數據量,若數據量過大,應該考慮相應需求是否合理。



轉載2:你可能不知道的MySQL

前言:

實驗的數據表以下定義:
mysql> desc tbl_name;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| uid   | int(11)      | NO   |     | NULL    |       |
| sid   | mediumint(9) | NO   |     | NULL    |       |
| times | mediumint(9) | NO   |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

存儲引擎是MyISAM,裏面有10,000條數據。
1、」\G」的做用

mysql> select * from tbl_name limit 1;
+--------+--------+-------+
| uid    | sid    | times |
+--------+--------+-------+
| 104460 | 291250 |    29 |
+--------+--------+-------+
1 row in set (0.00 sec)

mysql> select * from tbl_name limit 1\G;
*************************** 1. row ***************************
  uid: 104460
  sid: 291250
times: 29
1 row in set (0.00 sec)

有時候,操做返回的列數很是多,屏幕不能一行顯示完,顯示折行,試試」\G」,把列數據逐行顯示(」\G」挽救了我,之前看explain語句橫向顯示不全折行看起來巨費勁,還要把數據和列對應起來)。

2、」Group by」的」隱形殺手」

mysql> explain select uid,sum(times) from tbl_name group by uid\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using temporary; Using filesort
1 row in set (0.00 sec)

mysql> explain select uid,sum(times) from tbl_name group by uid order by null\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using temporary
1 row in set (0.00 sec)

默認狀況下,Group by col會對col字段進行排序,這就是爲何第一語句裏面有Using filesort的緣由,若是你不須要對col字段進行排序,加上order by null吧,要快不少,由於filesort很慢的。

3、大批量數據插入

最高效的大批量插入數據的方法:

load data infile '/path/to/file' into table tbl_name;

若是沒有辦法先生成文本文件或者不想生成文本文件,能夠一次插入多行:

insert into tbl_name values (1,2,3),(4,5,6),(7,8,9)...

注意一條sql語句的最大長度是有限制的。若是還不想這樣,能夠試試MySQL的prepare,應該都會比硬生生的逐條插入要快許多。

若是數據表有索引,建議先暫時禁用索引:

alter table tbl_name disable keys;

插入完畢以後再激活索引:

alter table tbl_name enable keys;

對MyISAM表尤爲有用。避免每插入一條記錄系統更新一下索引。

4、最快複製表結構方法

mysql> create table clone_tbl select * from tbl_name limit 0;
Query OK, 0 rows affected (0.08 sec)

只會複製表結構,索引不會複製,若是還要複製數據,把limit 0去掉便可。

5、加引號和不加引號區別

給數據表tbl_name添加索引:

mysql> create index uid on tbl_name(uid);

測試以下查詢:

mysql> explain select * from tbl_name where uid = '1081283900'\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ref
possible_keys: uid
          key: uid
      key_len: 4
          ref: const
         rows: 143
        Extra:
1 row in set (0.00 sec)

咱們在整型字段的值上加索引,是能夠用到索引的,網上很多人誤傳在整型字段上加引號沒法使用索引。修改uid字段類型爲varchar(12):

mysql> alter table tbl_name change uid uid varchar(12) not null;

測試以下查詢:

mysql> explain select * from tbl_name where uid = 1081283900\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: uid
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using where
1 row in set (0.00 sec)

咱們在查詢值上不加索引,結果索引沒法使用,注意安全。

6、前綴索引

有時候咱們的表中有varchar(255)這樣的字段,並且咱們還要對該字段建索引,通常沒有必要對整個字段建索引,創建前8~12個字符的索引應該就夠了,不多有連續8~12個字符都相等的字段。

爲何?更短的索引意味索引更小、佔用CPU時間更少、佔用內存更少、佔用IO更少和很更好的性能。

7、MySQL索引使用方式

MySQL在一個查詢中只能用到一個索引(5.0之後版本引入了index_merge合併索引,對某些特定的查詢能夠用到多個索引,具體查考[中文] [英文]),因此要根據查詢條件創建聯合索引,聯合索引只有第一位的字段在查詢條件中能才能使用到。

若是MySQL認爲不用索引比用索引更快的話,那麼就不會用索引。

mysql> create index times on tbl_name(times);
Query OK, 10000 rows affected (0.10 sec)
Records: 10000  Duplicates: 0  Warnings: 0

mysql> explain select * from tbl_name where times > 20\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: ALL
possible_keys: times
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using where
1 row in set (0.00 sec)

mysql> explain select * from tbl_name where times > 200\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: tbl_name
         type: range
possible_keys: times
          key: times
      key_len: 3
          ref: NULL
         rows: 1599
        Extra: Using where
1 row in set (0.00 sec)

數據表中times字段絕大多數都比20大,因此第一個查詢沒有用索引,第二個纔用到索引。

相關文章
相關標籤/搜索