您好,登錄后才能下訂單哦!
本篇文章給大家分享的是有關MySQL中怎么保證數據庫的效率,小編覺得挺實用的,因此分享給大家學習,希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
第一范式:1NF - 確保原子性
是對屬性的原子性約束,要求屬性(列)具有原子性,不可再分解;(只要是關系型數據庫都滿足 1NF)
第二范式:2NF - 確保表中每列都和主鍵相關
是對記錄的唯一性約束,要求記錄有唯一標識,即實體的唯一性;
先滿足1NF,然后每張表要有主鍵,并且確保每一列都和主鍵相關,而不是主鍵的一部分(主要針對聯合主鍵)。換言之,一個表中只保存一種數據而不是多種數據。
錯誤示范:
商品訂單信息錯誤設計
正確示范:
商品訂單信息正確設計
第三范式:3NF - 確保每列都和主鍵直接相關,而不是間接相關
3NF 是對字段冗余性的約束,它要求字段沒有冗余。
第三范式需要確保數據表中的每一列數據都和主鍵直接相關,而不能間接相關。不能傳遞依賴,如非主鍵列A依賴非主鍵列B,非主鍵列B依賴主鍵。
關鍵字段 -> 非關鍵字段x -> 非關鍵字段y
案例1:
比如在設計一個訂單數據表的時候,可以將客戶編號作為一個外鍵和訂單表建立相應的關系。而不可以在訂單表中添加關于客戶其它信息(比如姓名、所屬公司等)字段。如下這兩個表所示的設計就是一個滿足第三范式的數據庫表。
案例2:
假定學生關系表為 Student (學號、姓名、年齡、所在學院、學院地點、學院電話),關鍵字為單一關鍵字“學號”,因為存在如下決定關系:
(學號)-> (姓名、年齡、所在學院、學院地點、學院電話)
復制代碼
即存在非關鍵字段“學院地點”、“學院電話”對關鍵字段“學號”的傳遞函數依賴。 它也會存在數據冗余,更新異常、插入異常和刪除異常的情況。正確應把學生關系表分為如下兩個表:
學生:(學號、姓名、年齡、所在學院)
學院:(學院、地點、電話)
范式化優缺點
范式化的優點:
鴻蒙官方戰略合作共建——HarmonyOS技術社區
重復數據少,不冗余;
維護更新快;
范式化的表更小,可在內存中運行。
范式化的缺點:
查詢的時候經常需要很多關聯,增加查詢的代價。也可能使一些索引策略失效,因為范式化將列放在不同的表中,而這些列在一個表中本可以屬于同一個索引。
反范式化的優缺點
反范式化的優點:
鴻蒙官方戰略合作共建——HarmonyOS技術社區
避免關聯,幾乎所有數據可以在一張表中顯示。
可以設計有效的索引。
反范式化的缺點:
冗余數據多,更小維護麻煩,刪除數據時也容易丟失重要信息。
數據表設計的建議
沒有冗余的數據庫設計可以做到,但是,沒有冗余的數據庫未必是最好的數據庫,有時為了提高運行效率,就必須降低范式標準,適當保留冗余數據。具體做法:在概念數據模型設計時遵守第三范式,降低范式標準的工作放到物理數據模型設計時考慮。降低范式就是增加字段,允許冗余。
另外,《阿里巴巴Java開發手冊》,數據庫的表設計允許適當冗余,以提升SQL查詢的性能,避免表的關聯查詢。
適度冗余,減少join的關聯
冗余更新頻率不高,但是查詢頻率極高的字段。如訂單中的商品名稱、微博發帖中的用戶昵稱。
大表水平拆分
舉例說明:在一個論壇系統里,管理員經常會發一些帖子,這些帖子要求在每個分類列表里都要置頂。
設計方案一:在發帖表里增加一列用來標示是否是管理員發帖,這樣在每個分類列表展示時就需要對發帖表查詢兩次,一次是置頂帖,一次是普通帖,然后將兩次結果合并。如果發帖表內容較大時,查詢置頂帖的性能開銷會比較大。
設計方案二:將置頂帖存放在一個單獨的置頂表里。因為置頂帖數量相比會很少,但訪問頻率很高,這樣從發帖表里分拆開來,訪問的性能開銷會少很多。
合適的數據類型
如果數據量一樣,但數據類型更小的話,數據存放同樣的數據就會占用更少的空間,這樣檢索同樣的數據所帶來的IO 消耗自然會降低,性能也就很自然的得到提升。此外,MySQL 對不同類型的數據,處理方式也不一樣,比如在運算或者排序操作中,越簡單的數據類型操作性能越高,所以對于要頻繁進行運算或者排序的字段盡量選擇簡單的數據類型。
SQL語句優化
SQL語句優化
SQL優化的一般步驟
鴻蒙官方戰略合作共建——HarmonyOS技術社區
通過show status命令了解各種SQL的執行頻率;
定位執行效率較低的SQL語句-(重點select);
通過explain分析低效率的SQL;
確定問題并采取相應的優化措施。
-- select語句分類
Select
Dml數據操作語言(insert update delete)
dtl 數據事物語言(commit rollback savepoint)
Ddl數據定義語言(create alter drop..)
Dcl(數據控制語言) grant revoke
-- Show status 常用命令
--查詢本次會話
Show session status like 'com_%'; //show session status like 'Com_select'
--查詢全局
Show global status like 'com_%';
-- 給某個用戶授權
grant all privileges on *.* to 'abc'@'%';
--為什么這樣授權 'abc' 表示用戶名 '@' 表示host, 查看一下mysql->user表就知道了
--回收權限
revoke all on *.* from 'abc'@'%';
--刷新權限[也可以不寫]
flush privileges;
SQL語句優化-show參數
MySQL客戶端連接成功后,通過使用 show [session|global] status 命令可以提供服務器狀態信息。其中的session來表示當前的連接的統計結果,global來表示自數據庫上次啟動至今的統計結果。默認是session級別的。
show status like 'Com_%';
其中, Com_XXX 表示 XXX 語句所執行的次數。 重點注意:Com_select,Com_insert,Com_update,Com_delete 通過這幾個參數,可以了解到當前數據庫的應用是以插入更新為主還是以查詢操作為主,以及各類的SQL大致的執行比例是多少。
還有幾個常用的參數便于用戶了解數據庫的基本情況。 Connections:試圖連接MySQL服務器的次數 Uptime:服務器工作的時間(單位秒) Slow_queries:慢查詢的次數 (默認是慢查詢時間10s)
show status like 'Connections'; show status like 'Uptime'; show status like 'Slow_queries';
查詢MySQL的慢查詢時間
show variables like 'long_query_time';
修改MySQL慢查詢時間
set long_query_time=2;
SQL語句優化-定位慢查詢
上面我們介紹了獲取MySQL數據庫的一些運行狀態是如何查詢
比如當前MySQL運行的時間: show status like 'Uptime';
一共執行了多少次: select/update/delete.. / : show status like 'Com_%';
當前連接數
定位慢查詢
如何從一個項目中快速定位執行速度慢的語句(定位慢查詢)
show variables like '%query%';
slow_query_log 默認是off關閉的,使用時,需要改為on 打開
slow_query_log_file 記錄的是慢日志的記錄文件
long_query_time 默認是10S,每次執行的sql達到這個時長,就會被記錄
查看慢查詢狀態
Slow_queries 記錄的是慢查詢數量 當有一條sql執行一次比較慢時,這個vlue就是1 (記錄的是本次會話的慢sql條數)
show status like '%slow_queries%';
注意:
1. 如何打開慢查詢 : SET GLOBAL slow_query_log = ON;
2. 將默認時間改為1S: SET GLOBAL long_query_time = 1;
(設置完需要重新連接數據庫,PS:僅在這里改的話,當再次重啟數據庫服務時,所有設置又會自動恢復成默認值,永久改變需去my.ini中改)
SQL語句優化-Explain工具
使用EXPLAIN關鍵字可以模擬優化器執行SQL語句,分析你的查詢語句或是結構的性能瓶頸 在 select 語句之前增加 explain 關鍵字,MySQL 會在查詢上設置一個標記,執行查詢會返回執行計劃的信息,而不是執行這條SQL。
注意:如果 from 中包含子查詢,仍會執行該子查詢,將結果放入臨時表中
Explain分析示例
DROP TABLE IF EXISTS `actor`;
CREATE TABLE `actor` (
`id` int(11) NOT NULL,
`name` varchar(45) DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `actor` (`id`,`name`,`update_time`) VALUES (1,'a','2020-09-16 14:26:11'), (2,'b','2020-09-16 14:26:11'), (3,'c','2020-09-16 14:26:11');
DROP TABLE IF EXISTS` film`;
CREATE TABLE`film`(
`id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`),
KEY `idx_name` (`name`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `film`(`id`,`name`) VALUES (3,'film0'),(1,'film1'),(2,'film2');
DROP TABLE IF EXISTS `film_actor`;
CREATE TABLE`film_actor`(
`id` int(11) NOT NULL,
`film_id` int(11) NOT NULL,
`actor_id` int(11) NOT NULL,
`remark` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_film_actor_id` (`film_id`,`actor_id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO`film_actor`(`id`,`film_id`,`actor_id`)VALUES(1,1,1), (2,1,2),(3,2,1);
explain select * from actor;
查詢中的每個表會輸出一行,如果有兩個表通過join連接查詢,那么會輸出兩行。每一列具體的說明在后面進行說明。
Explain 兩個變種
1.explain extended
會在 explain 的基礎上額外提供一些查詢優化的信息。緊隨其后通過 show warnings 命令可以得到優化后的查詢語句,從而看出優化器優化了什么。額外還有 filtered 列,是一個半分比的值,rows * filtered/100 可以估算出將要和 explain 中前一個表進行連接的行數(前一個表指 explain 中的id值比當前表id值小的表)。
explain extended select * from film where id = 1;
show warnings;
2.explain partitions
相比 explain 多了個 partitions 字段,如果查詢是基于分區表的話,會顯示查詢將訪問的分區。
Explain中的列
接下來我們將展示 explain 中每個列的信息。
id 列
id 列的編號是 select 的序列號,有幾個 select 就有幾個 id,并且id的順序是按 select 出現的順序遞增的。id列越大執行優先級越高,id相同則從上往下執行,id為 NULL 最后執行。
select_type 列
select_type 表示對應行是簡單還是復雜的查詢。
simple :簡單查詢。查詢不包含子查詢和union
explain select * from film where id = 2;
primary :復雜查詢中最外層的 select
subquery :包含在 select 中的子查詢(不在 from 子句中)
derived :包含在 from 子句中的子查詢。MySQL 會將結果存放在一個臨時表中,也稱為派生表(derived的英文含義)
用下面這個例子來了解 primary、subquery、derived類型。
explain select (select 1 from actor where id = 1) from (select * from film where id = 1) der;
未關閉MySQL5.7新特性對衍生表的合并優化,如下:
#關閉mysql5.7新特性對衍 生表的合并優化 set session optimizer_switch='derived_merge=off';
#還原默認配置 set session optimizer_switch='derived_merge=on';
union :在 union 中的第二個和隨后的 select
explain select 1 union all select 1;
table 列
這一列表示 explain 的一行正在訪問哪個表。 當 from 子句中有子查詢時,table列是 格式,表示當前查詢依賴 id=N 的查 詢,于是先執行 id=N 的查詢。 當有 union 時,UNION RESULT 的 table 列的值為<union1,2>,1和2表示參與 union 的 select 行id。
type 列
這一列表示關聯類型或訪問類型,即MySQL決定如何查找表中的行,查找數據行記錄的大概范圍。
依次從最優到最差分別為:
system > const > eq_ref > ref > range > index > ALL
一般來說,得保證查詢達到 range 級別,最好達到 ref。
NULL:MySQL 能夠在優化階段分解查詢語句,在執行階段用不著再訪問表或索引。例如:在索引列中選取最小值,可以單獨查找索引來完成,不需要在執行時訪問表。
explain select min(id) from film;
system、const :MySQL 能對查詢的某部分進行優化并將其轉化成一個常量(可以看 show warnings 的)。用于 primary key 或 unique key 的所有列與常數比較時,所以表最多有一個匹配行,讀取1次,速度比較快。system 是 const 的特例,表里只有一條元組匹配時為 system。
explain extended select * from (select * from film where id = 1) tmp;
show warnings;
eq_ref :primary key 或 unique key 索引的所有部分被連接使用,最多只會返回一條符合條件的記錄。這可能是在 const 之外最好的連接類型了,簡單的 select 查詢不會出現這種 type。
explain select * from film_actor left join film on film_actor.film_id = film.id;
ref :相比 eq_ref ,不使用唯一索引,而是使用普通索引或者唯一性索引的部分前綴,索引要和某個值相比較,可能會找到多個符合條件的行。
(1)簡單 select 查詢,name 是普通索引(非唯一索引)
explain select * from film where name = 'film1';
(2)關聯表查詢, idx_film_actor_id 是 film_id 和 actor_id 的聯合索引,這里使用到了 film_actor 的左邊前綴 film_id 部分。
explain select film_id from film left join film_actor on film.id = film_actor.film_id;
range : 范圍掃描通常出現在 in()、betwwen、>、<、>= 等操作中。使用一個索引來檢索給定范圍的行。
explain select * from actor where id > 1;
index :掃描全表索引,通過比 ALL 快一些。
explain select * from film;
ALL :即全表掃描,意味著MySQL需要從頭到尾去查找所需要的行。通常情況下這需要增加索引來進行優化了。
explain select * from actor;
possible_keys 列
這一列顯示查詢可能使用哪些索引來查找。 explain 時可能出現 possible_keys 有列,而 key 顯示 NULL 的情況,這種情況是因為表中數據不多,mysql認為索引對此查詢幫助不大,選擇了全表查詢。 如果該列是NULL,則沒有相關的索引。在這種情況下,可以通過檢查 where 子句看是否可以創造一個適當的索引來提高查詢性能,然后用 explain 查看效果。
key 列
這一列顯示mysql實際采用哪個索引來優化對該表的訪問。 如果沒有使用索引,則該列是 NULL。如果想強制mysql使用或忽視possible_keys列中的索 引,在查詢中使用 force index、ignore index。
key_len 列
這一列顯示了mysql在索引里使用的字節數,通過這個值可以算出具體使用了索引中的哪些 列。 舉例來說,film_actor的聯合索引 idx_film_actor_id 由 film_id 和 actor_id 兩個int列組成, 并且每個int是4字節。通過結果中的key_len=4可推斷出查詢使用了第一個列:film_id列來執 行索引查找。
explain select * from film_actor where film_id = 2;
key_len計算規則如下:
字符串
char(n): n字節長度
varchar(n): 2字節存儲字符串長度,如果是utf-8,則長度 3n +2
數值類型
tinyint: 1字節
smallint: 2字節
int: 4字節
bigint: 8字節
時間類型
date: 3字節
timestamp: 4字節
datetime: 8字節
如果字段允許為 NULL,需要1字節記錄是否為 NULL
索引最大長度是768字節,當字符串過長時,mysql會做一個類似左前綴索引的處理,將前半部分的字符提取出來做索引。
ref 列
這一列顯示了在key列記錄的索引中,表查找值所用到的列或常量,常見的有:const(常 量),字段名(例:film.id)
rows 列
這一列是mysql估計要讀取并檢測的行數,注意這個不是結果集里的行數。
Extra 列
這一列展示的是額外信息。常見的重要值如下:
(1)Using index :使用覆蓋索引
explain select film_id from film_actor where film_id = 1;
(2)Using where :使用 where 語句來處理結果,查詢的列未被索引覆蓋
explain select * from actor where name = 'a';
(3)Using index condition :查詢的列不完全被索引覆蓋,where 條件中是一個前導列的范圍
explain select * from film_actor where film_id > 1;
(4)Using temporary :MySQL 需要創建一張臨時表來處理查詢。出現這種情況一般是要進行優化的,首先是想到用索引來優化。
actor.name沒有索引,此時創建了張臨時表來distinct
explain select distinct name from actor;
film.name建立了idx_name索引,此時查詢時extra是using index,沒有用臨時表
explain select distinct name from film;
(5)Using filesort : 將用外部排序而不是索引排序,數據較小時從內存排序,否則需要在磁盤 完成排序。這種情況下一般也是要考慮使用索引來優化的。
actor.name沒有索引,會瀏覽 actor 整個表,保存排序關鍵字 name 和對應的 id,然后排序 name 并檢索行記錄。
explain select * from actor order by name;
film.name建立了idx_name索引,此時查詢時extra是using index
explain select * from film order by name;
(6)Select tables optimized away :使用某些聚合函數(比如 max、min)來訪問存在索引 的某個字段是
explain select min(id) from film;
# 示例表
CREATE TABLE`employees`(
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',
`age` int(11) NOT NULL DEFAULT '0' COMMENT '年齡',
`position` varchar(20) NOT NULL DEFAULT '' COMMENT '職位',
`hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入職時間',
PRIMARY KEY (`id`),
KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
)ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COMMENT='員工記錄表';
INSERT INTO employees(name,age,position,hire_time)VALUES('ZhangSan',23,'Manager',NOW());
INSERT INTO employees(name,age,position,hire_time)VALUES('HanMeimei', 23,'dev',NOW());
INSERT INTO employees(name,age,position,hire_time) VALUES('Lucy',23,'dev',NOW());
全值匹配
EXPLAIN SELECT * FROM employees WHERE name= 'ZhangSan';
EXPLAIN SELECT * FROM employees WHERE name= 'ZhangSan' AND age = 22;
EXPLAIN SELECT * FROM employees WHERE name= 'ZhangSan' AND age = 22 AND position ='manager';
最左前綴法則
如果索引了多列,要遵守最左前綴法則。指的是查詢從索引的最左前列開始并且不跳過索引中的列。
EXPLAIN SELECT * FROM employees WHERE age = 22 AND position ='manager';
EXPLAIN SELECT * FROM employees WHERE position = 'manager';
EXPLAIN SELECT * FROM employees WHERE name = 'ZhangSan';
不在索引列上做任何操作
不在索引列上做任何操作(計算、函數、(自動or手動)類型轉換),會導致索引失效而轉向全表掃描。
EXPLAIN SELECT * FROM employees WHERE name = 'ZhangSan'; EXPLAIN SELECT * FROM employees WHERE left(name,3) = 'ZhangSan';
給hire_time增加一個普通索引:
ALTER TABLE `employees` ADD INDEX `idx_hire_time` (`hire_time`) USING BTREE;
EXPLAIN select * from employees where date(hire_time) ='2020-09-30';
轉化為日期范圍查詢,會走索引:
EXPLAIN select * from employees where hire_time >='2020-09-30 00:00:00' and hire_time <='2020-09-30 23:59:59';
還原最初索引狀態
ALTER TABLE `employees` DROP INDEX `idx_hire_time`;
存儲引擎不能使用索引中范圍條件右邊的列
EXPLAIN SELECT * FROM employees WHERE name= 'ZhangSan' AND age = 22 AND position ='manager'; EXPLAIN SELECT * FROM employees WHERE name= 'ZhangSan' AND age > 22 AND position ='manager';
EXPLAIN SELECT name,age FROM employees WHERE name= 'ZhangSan' AND age = 23 AND position ='manager';
盡量使用覆蓋索引
盡量使用覆蓋索引(只訪問索引的查詢(索引列包含查詢列)),減少select *語句。
EXPLAIN SELECT name,age FROM employees WHERE name= 'ZhangSan' AND age = 23 AND position ='manager';
EXPLAIN SELECT * FROM employees WHERE name= 'ZhangSan' AND age = 23 AND position ='manager';
mysql在使用不等于(!=或者<>)的時候無法使用索引會導致全表掃描
EXPLAIN SELECT * FROM employees WHERE name != 'ZhangSan';
is null、is not null 也無法使用索引
EXPLAIN SELECT * FROM employees WHERE name is null
like以通配符開頭('%abc...')mysql索引失效會變成全表掃描操作
EXPLAIN SELECT * FROM employees WHERE name like '%Zhang'
EXPLAIN SELECT * FROM employees WHERE name like 'Zhang%'
問題:解決like'%字符串%'索引不被使用的方法?
使用覆蓋索引,查詢字段必須是建立覆蓋索引字段
EXPLAIN SELECT name,age,position FROM employees WHERE name like '%Zhang%';
如果不能使用覆蓋索引則可能需要借助搜索引擎
字符串不加單引號索引失效
EXPLAIN SELECT * FROM employees WHERE name = '1000'; EXPLAIN SELECT * FROM employees WHERE name = 1000;
少用or或in
少用or或in,用它查詢時,mysql不一定使用索引,mysql內部優化器會根據檢索比例、 表大小等多個因素整體評估是否使用索引,詳見范圍查詢優化。
EXPLAIN SELECT * FROM employees WHERE name = 'ZhangSan' or name = 'HanMeimei';
范圍查詢優化
給年齡添加單值索引
ALTER TABLE`employees` ADD INDEX `idx_age` (`age`)USING BTREE;
explain select * from employees where age >=1 and age <=2000;
沒走索引原因:mysql內部優化器會根據檢索比例、表大小等多個因素整體評估是否使用索引。比如這個例子,可能是由于單次數據量查詢過大導致優化器最終選擇不走索引 優化方法:可以將大的范圍拆分成多個小范圍。
explain select * from employees where age >=1 and age <=1000; explain select * from employees where age >=1001 and age <=2000;
還原最初索引狀態:
ALTER TABLE `employees`
DROP INDEX `idx_age`;
索引使用總結
假設 index(a,b,c)
like KK% 相當于=常量,%KK 和 %KK% 相當于范圍
以上就是MySQL中怎么保證數據庫的效率,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。