本文目錄一覽：
怎麼進行mysql數據庫優化？
有八個方面可以對mysql進行優化：
1、選取最適用的字段屬性
MySQL可以很好的支持大數據量的存取，但是一般說來，數據庫中的表越小，在它上面執行的查詢也就會越快。因此，在創建表的時候，為了獲得更好的性能，我們可以將表中字段的寬度設得儘可能小。
2. 使用連接（JOIN）來代替子查詢(Sub-Queries)
MySQL從4.1開始支持SQL的子查詢。這個技術可以使用SELECT語句來創建一個單列的查詢結果，然後把這個結果作為過濾條件用在另一個查詢中。
3、使用聯合(UNION)來代替手動創建的臨時表
MySQL從4.0的版本開始支持union查詢，它可以把需要使用臨時表的兩條或更多的select查詢合併的一個查詢中。在客戶端的查詢會話結束的時候，臨時表會被自動刪除，從而保證數據庫整齊、高效。
4、事務
儘管我們可以使用子查詢（Sub-Queries）、連接（JOIN）和聯合（UNION）來創建各種各樣的查詢，但不是所有的數據庫操作都可以只用一條或少數幾條SQL語句就可以完成的。更多的時候是需要用到一系列的語句來完成某種工作。但是在這種情況下，當這個語句塊中的某一條語句運行出錯的時候，整個語句塊的操作就會變得不確定起來。設想一下，要把某個數據同時插入兩個相關聯的表中，可能會出現這樣的情況：第一個表中成功更新後，數據庫突然出現意外狀況，造成第二個表中的操作沒有完成，這樣，就會造成數據的不完整，甚至會破壞數據庫中的數據。要避免這種情況，就應該使用事務，它的作用是：要麼語句塊中每條語句都操作成功，要麼都失敗
5、鎖定表
儘管事務是維護數據庫完整性的一個非常好的方法，但卻因為它的獨佔性，有時會影響數據庫的性能，尤其是在很大的應用系統中。由於在事務執行的過程中，數據庫將會被鎖定，因此其它的用戶請求只能暫時等待直到該事務結束。其實，有些情況下我們可以通過鎖定表的方法來獲得更好的性能。
6、使用外鍵
鎖定表的方法可以維護數據的完整性，但是它卻不能保證數據的關聯性。這個時候我們就可以使用外鍵。
7、使用索引
索引是提高數據庫性能的常用方法，它可以令數據庫服務器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當中包含有MAX(),MIN()和ORDERBY這些命令的時候，性能提高更為明顯。
8、優化的查詢語句
絕大多數情況下，使用索引可以提高查詢的速度，但如果SQL語句使用不恰當的話，索引將無法發揮它應有的作用。
怎麼優化MySQL數據庫
1、選取最適用的字段屬性,儘可能減少定義字段長度,盡量把字段設置NOT NULL,例如’省份,性別’,最好設置為ENUM
2、使用連接（JOIN）來代替子查詢:
a.刪除沒有任何訂單客戶:DELETE FROM customerinfo WHERE customerid NOT in(SELECT customerid FROM orderinfo)
b.提取所有沒有訂單客戶:SELECT FROM customerinfo WHERE customerid NOT in(SELECT customerid FROM orderinfo)
c.提高b的速度優化:SELECT FROM customerinfo LEFT JOIN orderid customerinfo.customerid=orderinfo.customerid
WHERE orderinfo.customerid IS NULL
3、使用聯合(UNION)來代替手動創建的臨時表
a.創建臨時表:SELECT name FROM `nametest` UNION SELECT username FROM `nametest2`
4、事務處理:
a.保證數據完整性,例如添加和修改同時,兩者成立則都執行,一者失敗都失敗
mysql_query(“BEGIN”);
mysql_query(“INSERT INTO customerinfo (name) VALUES (‘$name1’)”;
mysql_query(“SELECT * FROM `orderinfo` where customerid=”.$id”);
mysql_query(“COMMIT”);
5、鎖定表,優化事務處理:
a.我們用一個 SELECT 語句取出初始數據，通過一些計算，用 UPDATE 語句將新值更新到表中。
包含有 WRITE 關鍵字的 LOCK TABLE 語句可以保證在 UNLOCK TABLES 命令被執行之前，
不會有其它的訪問來對 inventory 進行插入、更新或者刪除的操作
mysql_query(“LOCK TABLE customerinfo READ, orderinfo WRITE”);
mysql_query(“SELECT customerid FROM `customerinfo` where id=”.$id);
mysql_query(“UPDATE `orderinfo` SET ordertitle=’$title’ where customerid=”.$id);
mysql_query(“UNLOCK TABLES”);
6、使用外鍵,優化鎖定表
a.把customerinfo里的customerid映射到orderinfo里的customerid,
任何一條沒有合法的customerid的記錄不會寫到orderinfo里
CREATE TABLE customerinfo
(
customerid INT NOT NULL,
PRIMARY KEY(customerid)
)TYPE = INNODB;
CREATE TABLE orderinfo
(
orderid INT NOT NULL,
customerid INT NOT NULL,
PRIMARY KEY(customerid,orderid),
FOREIGN KEY (customerid) REFERENCES customerinfo
(customerid) ON DELETE CASCADE
)TYPE = INNODB;
注意:’ON DELETE CASCADE’,該參數保證當customerinfo表中的一條記錄刪除的話同時也會刪除order
表中的該用戶的所有記錄,注意使用外鍵要定義事務安全類型為INNODB;
7、建立索引:
a.格式:
(普通索引)-
創建:CREATE INDEX 索引名 ON tablename (索引字段)
修改:ALTER TABLE tablename ADD INDEX [索引名] (索引字段)
創表指定索引:CREATE TABLE tablename([…],INDEX[索引名](索引字段))
(唯一索引)-
創建:CREATE UNIQUE 索引名 ON tablename (索引字段)
修改:ALTER TABLE tablename ADD UNIQUE [索引名] (索引字段)
創表指定索引:CREATE TABLE tablename([…],UNIQUE[索引名](索引字段))
(主鍵)-
它是唯一索引,一般在創建表是建立,格式為:
CREATA TABLE tablename ([…],PRIMARY KEY[索引字段])
8、優化查詢語句
a.最好在相同字段進行比較操作,在建立好的索引字段上盡量減少函數操作
例子1:
SELECT * FROM order WHERE YEAR(orderDate)2008;(慢)
SELECT * FROM order WHERE orderDate”2008-01-01″;(快)
例子2:
SELECT * FROM order WHERE addtime/724;(慢)
SELECT * FROM order WHERE addtime24*7;(快)
例子3:
SELECT * FROM order WHERE title like “%good%”;
SELECT * FROM order WHERE title=”good” and name”good”;
優化MYSQL數據庫的方法
在開始演示之前，我們先介紹下兩個概念。
概念一，數據的可選擇性基數，也就是常說的cardinality值。
查詢優化器在生成各種執行計劃之前，得先從統計信息中取得相關數據，這樣才能估算每步操作所涉及到的記錄數，而這個相關數據就是cardinality。簡單來說，就是每個值在每個字段中的唯一值分布狀態。
比如表t1有100行記錄，其中一列為f1。f1中唯一值的個數可以是100個，也可以是1個，當然也可以是1到100之間的任何一個數字。這裡唯一值越的多少，就是這個列的可選擇基數。
那看到這裡我們就明白了，為什麼要在基數高的字段上建立索引，而基數低的的字段建立索引反而沒有全表掃描來的快。當然這個只是一方面，至於更深入的探討就不在我這篇探討的範圍了。
概念二，關於HINT的使用。
這裡我來說下HINT是什麼，在什麼時候用。
HINT簡單來說就是在某些特定的場景下人工協助MySQL優化器的工作，使她生成最優的執行計劃。一般來說，優化器的執行計劃都是最優化的，不過在某些特定場景下，執行計劃可能不是最優化。
比如：表t1經過大量的頻繁更新操作，（UPDATE,DELETE,INSERT），cardinality已經很不準確了，這時候剛好執行了一條SQL，那麼有可能這條SQL的執行計劃就不是最優的。為什麼說有可能呢？
來看下具體演示
譬如，以下兩條SQL，
A：
select * from t1 where f1 = 20;
B：
select * from t1 where f1 = 30;
如果f1的值剛好頻繁更新的值為30，並且沒有達到MySQL自動更新cardinality值的臨界值或者說用戶設置了手動更新又或者用戶減少了sample page等等，那麼對這兩條語句來說，可能不準確的就是B了。
這裡順帶說下，MySQL提供了自動更新和手動更新表cardinality值的方法，因篇幅有限，需要的可以查閱手冊。
那回到正題上，MySQL 8.0 帶來了幾個HINT，我今天就舉個index_merge的例子。
示例表結構：
mysql desc t1;+————+————–+——+—–+———+—————-+| Field | Type | Null | Key | Default | Extra |+————+————–+——+—–+———+—————-+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+————+————–+——+—–+———+—————-+7 rows in set (0.00 sec)
表記錄數：
mysql select count(*) from t1;+———-+| count(*) |+———-+| 32768 |+———-+1 row in set (0.01 sec)
這裡我們兩條經典的SQL：
SQL C：
select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;
SQL D：
select * from t1 where rank1 =100 and rank2 =100 and rank3 =100;
表t1實際上在rank1,rank2,rank3三列上分別有一個二級索引。
那我們來看SQL C的查詢計劃。
顯然，沒有用到任何索引，掃描的行數為32034，cost為3243.65。
mysql explain format=json select * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “3243.65” }, “table”: { “table_name”: “t1”, “access_type”: “ALL”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “rows_examined_per_scan”: 32034, “rows_produced_per_join”: 115, “filtered”: “0.36”, “cost_info”: { “read_cost”: “3232.07”, “eval_cost”: “11.58”, “prefix_cost”: “3243.65”, “data_read_per_join”: “49K” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))” } }}1 row in set, 1 warning (0.00 sec)
我們加上hint給相同的查詢，再次看看查詢計劃。
這個時候用到了index_merge,union了三個列。掃描的行數為1103，cost為441.09，明顯比之前的快了好幾倍。
mysql explain format=json select /*+ index_merge(t1) */ * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “441.09” }, “table”: { “table_name”: “t1”, “access_type”: “index_merge”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “union(idx_rank1,idx_rank2,idx_rank3)”, “key_length”: “5,5,5”, “rows_examined_per_scan”: 1103, “rows_produced_per_join”: 1103, “filtered”: “100.00”, “cost_info”: { “read_cost”: “330.79”, “eval_cost”: “110.30”, “prefix_cost”: “441.09”, “data_read_per_join”: “473K” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))” } }}1 row in set, 1 warning (0.00 sec)
我們再看下SQL D的計劃：
不加HINT，
mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “534.34” }, “table”: { “table_name”: “t1”, “access_type”: “ref”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “idx_rank1”, “used_key_parts”: [ “rank1” ], “key_length”: “5”, “ref”: [ “const” ], “rows_examined_per_scan”: 555, “rows_produced_per_join”: 0, “filtered”: “0.07”, “cost_info”: { “read_cost”: “478.84”, “eval_cost”: “0.04”, “prefix_cost”: “534.34”, “data_read_per_join”: “176” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))” } }}1 row in set, 1 warning (0.00 sec)
加了HINT，
mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “5.23” }, “table”: { “table_name”: “t1”, “access_type”: “index_merge”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “intersect(idx_rank1,idx_rank2,idx_rank3)”, “key_length”: “5,5,5”, “rows_examined_per_scan”: 1, “rows_produced_per_join”: 1, “filtered”: “100.00”, “cost_info”: { “read_cost”: “5.13”, “eval_cost”: “0.10”, “prefix_cost”: “5.23”, “data_read_per_join”: “440” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))” } }}1 row in set, 1 warning (0.00 sec)
對比下以上兩個，加了HINT的比不加HINT的cost小了100倍。
總結下，就是說表的cardinality值影響這張的查詢計劃，如果這個值沒有正常更新的話，就需要手工加HINT了。相信MySQL未來的版本會帶來更多的HINT。
MySQL數據庫的幾個優化建議
我列舉幾個我熟悉的，
1，存儲引擎，根據應用選擇合適的引擎
2，索引 —-這個就有很多文章了，具體需要你自己去了解
3，sql語句優化，查詢條件的選擇之類
4，mysql自身系統配置，需要針對應用去定製
5，表的選擇，臨時表，或者分區表，也需要針對應用的情況去選擇使用
8，mysql數據庫，怎麼優化
優化Mysql數據庫的8個方法
1、創建索引
對於查詢佔主要的應用來說，索引顯得尤為重要。很多時候性能問題很簡單的就是因為我們忘了添加索引而造成的，或者說沒有添加更為有效的索引導致。如果不加索引的話，那麼查找任何哪怕只是一條特定的數據都會進行一次全表掃描，如果一張表的數據量很大而符合條件的結果又很少，那麼不加索引會引起致命的性能下降。但是也不是什麼情況都非得建索引不可，比如性別可能就只有兩個值，建索引不僅沒什麼優勢，還會影響到更新速度，這被稱為過度索引。
2、複合索引
比如有一條語句是這樣的：select
* from users where area=’beijing’ and
age=22;
如果我們是在area和age上分別創建單個索引的話，由於mysql查詢每次只能使用一個索引，所以雖然這樣已經相對不做索引時全表掃描提高了很多效率，但是如果在area、age兩列上創建複合索引的話將帶來更高的效率。如果我們創建了(area,
age,
salary)的複合索引，那麼其實相當於創建了(area,age,salary)、(area,age)、(area)三個索引，這被稱為最佳左前綴特性。因此我們在創建複合索引時應該將最常用作限制條件的列放在最左邊，依次遞減。
3、索引不會包含有NULL值的列
只要列中包含有NULL值都將不會被包含在索引中，複合索引中只要有一列含有NULL值，那麼這一列對於此複合索引就是無效的。所以我們在數據庫設計時不要讓字段的默認值為NULL。
4、使用短索引
對串列進行索引，如果可能應該指定一個前綴長度。例如，如果有一個CHAR(255)的
列，如果在前10 個或20
個字符內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁盤空間和I/O操作。
5、排序的索引問題
mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order
by中的列是不會使用索引的。因此數據庫默認排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個列的排序，如果需要最好給這些列創建複合索引。
6、like語句操作
一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like
“%aaa%” 不會使用索引而like “aaa%”可以使用索引。
7、不要在列上進行運算
select *
from users where
YEAR(adddate)2007;
將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成
select * from
users where adddate‘2007-01-01′;
8、不使用NOT
IN和操作
NOT IN和操作都不會使用索引將進行全表掃描。NOT IN可以NOT
EXISTS代替，id3則可使用id3 or id3來代替。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/300778.html
微信掃一掃 
支付寶掃一掃 