1、反例
SELECT * FROM user
2、正例
SELECT id,username,tel FROM user
3、理由
注意:為節(jié)省時(shí)間,下面的樣例字段都用*代替了。
1、反例
SELECT * FROM user WHERE id=1 OR salary=5000
2、正例
(1)使用union all
SELECT * FROM user WHERE id=1
UNION ALL
SELECT * FROM user WHERE salary=5000
(2)分開兩條sql寫
SELECT * FROM user WHERE id=1
SELECT * FROM user WHERE salary=5000
3、理由
or
可能會(huì)使索引失效,從而全表掃描;or
沒有索引的salary
這種情況,假設(shè)它走了id
的索引,但是走到salary
查詢條件時(shí),它還得全表掃描;mysql
是有優(yōu)化器的,出于效率與成本考慮,遇到or
條件,索引還是可能失效的;1、正例
primary key
優(yōu)先使用數(shù)值類型int
,tinyint
mysql
推薦使用tinyint
2、理由
1、反例
`address` char(100) DEFAULT NULL COMMENT '地址'
2、正例
`address` varchar(100) DEFAULT NULL COMMENT '地址'
3、理由
varchar
變長字段按數(shù)據(jù)內(nèi)容實(shí)際長度存儲(chǔ),存儲(chǔ)空間小,可以節(jié)省存儲(chǔ)空間;char
按聲明大小存儲(chǔ),不足補(bǔ)空格;1、char
的長度是固定的,而varchar2
的長度是可以變化的。
比如,存儲(chǔ)字符串“101”
,對于char(10)
,表示你存儲(chǔ)的字符將占10個(gè)字節(jié)(包括7個(gè)空字符),在數(shù)據(jù)庫中它是以空格占位的,而同樣的varchar2(10)
則只占用3個(gè)字節(jié)的長度,10只是最大值,當(dāng)你存儲(chǔ)的字符小于10時(shí),按實(shí)際長度存儲(chǔ)。
2、char
的效率比varchar2
的效率稍高。
3、何時(shí)用char
,何時(shí)用varchar2
?
char
和varchar2
是一對矛盾的統(tǒng)一體,兩者是互補(bǔ)的關(guān)系,varchar2
比char
節(jié)省空間,在效率上比char
會(huì)稍微差一點(diǎn),既想獲取效率,就必須犧牲一點(diǎn)空間,這就是我們在數(shù)據(jù)庫設(shè)計(jì)上常說的“以空間換效率”。
varchar2
雖然比char
節(jié)省空間,但是假如一個(gè)varchar2
列經(jīng)常被修改,而且每次被修改的數(shù)據(jù)的長度不同,這會(huì)引起“行遷移”現(xiàn)象,而這造成多余的I/O,是數(shù)據(jù)庫設(shè)計(jì)中要盡力避免的,這種情況下用char
代替varchar2
會(huì)更好一些。char
中還會(huì)自動(dòng)補(bǔ)齊空格,因?yàn)槟?code>insert到一個(gè)char
字段自動(dòng)補(bǔ)充了空格的,但是select
后空格沒有刪除,因此char
類型查詢的時(shí)候一定要記得使用trim
,這是寫本文章的原因。
如果開發(fā)人員細(xì)化使用rpad()
技巧將綁定變量轉(zhuǎn)換為某種能與char
字段相比較的類型(當(dāng)然,與截?cái)?code>trim數(shù)據(jù)庫列相比,填充綁定變量的做法更好一些,因?yàn)閷α袘?yīng)用函數(shù)trim
很容易導(dǎo)致無法使用該列上現(xiàn)有的索引),可能必須考慮到經(jīng)過一段時(shí)間后列長度的變化。如果字段的大小有變化,應(yīng)用就會(huì)受到影響,因?yàn)樗仨毿薷淖侄螌挾取?/p>
正是因?yàn)橐陨显?,定寬的存?chǔ)空間可能導(dǎo)致表和相關(guān)索引比平常大出許多,還伴隨著綁定變量問題,所以無論什么場合都要避免使用char類型。
1、反例
SELECT * FROM user WHERE age IS NOT NULL
2、正例
SELECT * FROM user WHERE age>0
3、理由
is null
或者 is not null
就會(huì)不走索引了,這個(gè)跟mysql
版本以及查詢成本都有關(guān);mysql
優(yōu)化器發(fā)現(xiàn),走索引比不走索引成本還要高,就會(huì)放棄索引,這些條件 !=,<>,is null,is not null
經(jīng)常被認(rèn)為讓索引失效;null
值,換成默認(rèn)值,很多時(shí)候讓走索引成為可能,同時(shí),表達(dá)意思也相對清晰一點(diǎn);1、反例
SELECT * FROM user WHERE salary!=5000
SELECT * FROM user WHERE salary<>5000
2、理由
!=
和<>
很可能會(huì)讓索引失效where
子句中使用!=
或<>
操作符,否則引擎將放棄使用索引而進(jìn)行全表掃描三種連接如果結(jié)果相同,優(yōu)先使用inner join,如果使用left join左邊表盡量小。
為什么?
1、反例
先分組,再過濾
select job, avg(salary) from employee
group by job
having job ='develop' or job = 'test';
2、正例
先過濾,后分組
select job,avg(salary) from employee
where job ='develop' or job = 'test'
group by job;
3、理由
可以在執(zhí)行到該語句前,把不需要的記錄過濾掉
truncate table
在功能上與不帶 where
子句的 delete
語句相同:二者均刪除表中的全部行。但 truncate table
比 delete
速度快,且使用的系統(tǒng)和事務(wù)日志資源少。
delete
語句每次刪除一行,并在事務(wù)日志中為所刪除的每行記錄一項(xiàng)。truncate table
通過釋放存儲(chǔ)表數(shù)據(jù)所用的數(shù)據(jù)頁來刪除數(shù)據(jù),并且只在事務(wù)日志中記錄頁的釋放。
truncate table
刪除表中的所有行,但表結(jié)構(gòu)及其列、約束、索引等保持不變。新行標(biāo)識(shí)所用的計(jì)數(shù)值重置為該列的種子。如果想保留標(biāo)識(shí)計(jì)數(shù)值,請改用 DELETE。如果要?jiǎng)h除表定義及其數(shù)據(jù),請使用 drop table
語句。
對于由 foreign key
約束引用的表,不能使用 truncate table
,而應(yīng)使用不帶 where
子句的 DELETE 語句。由于 truncate table
不記錄在日志中,所以它不能激活觸發(fā)器。
truncate table
不能用于參與了索引視圖的表。
1、降低寫錯(cuò)SQL的代價(jià)
清空表數(shù)據(jù)可不是小事情,一個(gè)手抖全沒了,刪庫跑路?如果加limit,刪錯(cuò)也只是丟失部分?jǐn)?shù)據(jù),可以通過binlog日志快速恢復(fù)的。
2、SQL效率很可能更高
SQL中加了limit 1
,如果第一條就命中目標(biāo)return
, 沒有limit
的話,還會(huì)繼續(xù)執(zhí)行掃描表。
3、避免長事務(wù)
delete
執(zhí)行時(shí),如果age
加了索引,MySQL會(huì)將所有相關(guān)的行加寫鎖和間隙鎖,所有執(zhí)行相關(guān)行會(huì)被鎖住,如果刪除數(shù)量大,會(huì)直接影響相關(guān)業(yè)務(wù)無法使用。
4、數(shù)據(jù)量大的話,容易把CPU打滿
如果你刪除數(shù)據(jù)量很大時(shí),不加 limit限制一下記錄數(shù),容易把cpu
打滿,導(dǎo)致越刪越慢。
5、鎖表
一次性刪除太多數(shù)據(jù),可能造成鎖表,會(huì)有l(wèi)ock wait timeout exceed的錯(cuò)誤,所以建議分批操作。
UNION
在進(jìn)行表鏈接后會(huì)篩選掉重復(fù)的記錄,所以在表鏈接后會(huì)對所產(chǎn)生的結(jié)果集進(jìn)行排序運(yùn)算,刪除重復(fù)的記錄再返回結(jié)果。實(shí)際大部分應(yīng)用中是不會(huì)產(chǎn)生重復(fù)的記錄,最常見的是過程表與歷史表UNION
。如:
select username,tel from user
union
select departmentname from department
這個(gè)SQL在運(yùn)行時(shí)先取出兩個(gè)表的結(jié)果,再用排序空間進(jìn)行排序刪除重復(fù)的記錄,最后返回結(jié)果集,如果表數(shù)據(jù)量大的話可能會(huì)導(dǎo)致用磁盤進(jìn)行排序。推薦方案:采用UNION ALL
操作符替代UNION
,因?yàn)?code>UNION ALL操作只是簡單的將兩個(gè)結(jié)果合并后就返回。
1、多條提交
INSERT INTO user (id,username) VALUES(1,'哪吒編程');
INSERT INTO user (id,username) VALUES(2,'妲己');
2、批量提交
INSERT INTO user (id,username) VALUES(1,'哪吒編程'),(2,'妲己');
3、理由
默認(rèn)新增SQL有事務(wù)控制,導(dǎo)致每條都需要事務(wù)開啟和事務(wù)提交,而批量處理是一次事務(wù)開啟和提交,效率提升明顯,達(dá)到一定量級,效果顯著,平時(shí)看不出來。
1、表連接不宜太多,一般5個(gè)以內(nèi)
2、索引不宜太多,一般5個(gè)以內(nèi)
insert
或update
時(shí)有可能會(huì)重建索引,如果數(shù)據(jù)量巨大,重建將進(jìn)行記錄的重新排序,所以建索引需要慎重考慮,視具體情況來定;1、反例
SELECT * FROM user WHERE DATE_ADD(birthday,INTERVAL 7 DAY) >=NOW();
2、正例
SELECT * FROM user WHERE birthday >= DATE_ADD(NOW(),INTERVAL 7 DAY);
3、理由
使用索引列上內(nèi)置函數(shù),索引失效。
排序時(shí)應(yīng)按照組合索引中各列的順序進(jìn)行排序,即使索引中只有一個(gè)列是要排序的,否則排序性能會(huì)比較差。
create index IDX_USERNAME_TEL on user(deptid,position,createtime);
select username,tel from user where deptid= 1 and position = 'java開發(fā)' order by deptid,position,createtime desc;
實(shí)際上只是查詢出符合 deptid= 1 and position = 'java開發(fā)'
條件的記錄并按createtime降序排序,但寫成order by createtime desc性能較差。
1、創(chuàng)建復(fù)合索引
ALTER TABLE employee ADD INDEX idx_name_salary (name,salary)
2、滿足復(fù)合索引的最左特性,哪怕只是部分,復(fù)合索引生效
SELECT * FROM employee WHERE NAME='哪吒編程'
3、沒有出現(xiàn)左邊的字段,則不滿足最左特性,索引失效
SELECT * FROM employee WHERE salary=5000
4、復(fù)合索引全使用,按左側(cè)順序出現(xiàn) name,salary,索引生效
SELECT * FROM employee WHERE NAME='哪吒編程' AND salary=5000
5、雖然違背了最左特性,但MySQL執(zhí)行SQL時(shí)會(huì)進(jìn)行優(yōu)化,底層進(jìn)行顛倒優(yōu)化
SELECT * FROM employee WHERE salary=5000 AND NAME='哪吒編程'
6、理由
復(fù)合索引也稱為聯(lián)合索引,當(dāng)我們創(chuàng)建一個(gè)聯(lián)合索引的時(shí)候,如(k1,k2,k3),相當(dāng)于創(chuàng)建了(k1)、(k1,k2)和(k1,k2,k3)三個(gè)索引,這就是最左匹配原則。
聯(lián)合索引不滿足最左原則,索引一般會(huì)失效。
模糊查詢,程序員最喜歡的就是使用like
,但是like
很可能讓你的索引失效。
1、反例
select * from citys where name like '%大連' (不使用索引)
select * from citys where name like '%大連%' (不使用索引)
2、正例
select * from citys where name like '大連%' (使用索引) 。
3、理由
like '…%’
,是會(huì)使用索引的;like '%...’
無法直接使用索引,但可以利用reverse + function index
的形式,變化成 like '…%’
;1、type
2、Extra常用關(guān)鍵字
GROUP BY
和ORDER BY
子句時(shí);1、設(shè)計(jì)表的時(shí)候,所有表和字段都添加相應(yīng)的注釋。
2、SQL書寫格式,關(guān)鍵字大小保持一致,使用縮進(jìn)。
3、修改或刪除重要數(shù)據(jù)前,要先備份。
4、很多時(shí)候用 exists 代替 in 是一個(gè)好的選擇
5、where后面的字段,留意其數(shù)據(jù)類型的隱式轉(zhuǎn)換。
未使用索引
SELECT * FROM user WHERE NAME=110
(1) 因?yàn)椴患訂我?hào)時(shí),是字符串跟數(shù)字的比較,它們類型不匹配;
(2)MySQL會(huì)做隱式的類型轉(zhuǎn)換,把它們轉(zhuǎn)換為數(shù)值類型再做比較;
6、盡量把所有列定義為NOT NULL
NOT NULL
列更節(jié)省空間,NULL
列需要一個(gè)額外字節(jié)作為判斷是否為 NULL
的標(biāo)志位。NULL
列需要注意空指針問題,NULL
列在計(jì)算和比較的時(shí)候,需要注意空指針問題。
7、偽刪除設(shè)計(jì)
8、數(shù)據(jù)庫和表的字符集盡量統(tǒng)一使用UTF8
(1)可以避免亂碼問題;
(2)可以避免,不同字符集比較轉(zhuǎn)換,導(dǎo)致的索引失效問題;
9、select count(*) from table;
這樣不帶任何條件的count會(huì)引起全表掃描,并且沒有任何業(yè)務(wù)意義,是一定要杜絕的。
10、避免在where中對字段進(jìn)行表達(dá)式操作
(1)SQL解析時(shí),如果字段相關(guān)的是表達(dá)式就進(jìn)行全表掃描 ;
(2)字段干凈無表達(dá)式,索引生效;
11、關(guān)于臨時(shí)表
(1)避免頻繁創(chuàng)建和刪除臨時(shí)表,以減少系統(tǒng)表資源的消耗;
(2)在新建臨時(shí)表時(shí),如果一次性插入數(shù)據(jù)量很大,那么可以使用 select into 代替 create table,避免造成大量 log;
(3)如果數(shù)據(jù)量不大,為了緩和系統(tǒng)表的資源,應(yīng)先create table,然后insert;
(4)如果使用到了臨時(shí)表,在存儲(chǔ)過程的最后務(wù)必將所有的臨時(shí)表顯式刪除。先 truncate table ,然后 drop table ,這樣可以避免系統(tǒng)表的較長時(shí)間鎖定;
12、索引不適合建在有大量重復(fù)數(shù)據(jù)的字段上,比如性別,排序字段應(yīng)創(chuàng)建索引
13、去重distinct過濾字段要少
cpu
時(shí)間高于不帶distinct
的語句distinct
,數(shù)據(jù)庫引擎就會(huì)對數(shù)據(jù)進(jìn)行比較,過濾掉重復(fù)數(shù)據(jù)cpu
時(shí)間14、盡量避免大事務(wù)操作,提高系統(tǒng)并發(fā)能力
15、所有表必須使用Innodb
存儲(chǔ)引擎
Innodb
「支持事務(wù),支持行級鎖,更好的恢復(fù)性」,高并發(fā)下性能更好,所以呢,沒有特殊要求(即Innodb
無法滿足的功能如:列存儲(chǔ),存儲(chǔ)空間數(shù)據(jù)等)的情況下,所有表必須使用Innodb
存儲(chǔ)引擎。
16、盡量避免使用游標(biāo)
因?yàn)橛螛?biāo)的效率較差,如果游標(biāo)操作的數(shù)據(jù)超過1萬行,那么就應(yīng)該考慮改寫。
聯(lián)系客服