mysql配置文件優化（mysql高性能優化規範建議）

本文目錄一覽：

1、linux 下怎麼優化mysql佔用內存？
2、mysql 有哪些常見的優化策略
3、linux 下怎麼優化mysql佔用內存
4、MySQL配置文件（my.cnf）路徑查看及相關配置

linux 下怎麼優化mysql佔用內存？

Linux 進程通過 C 標準庫中的內存分配函數 malloc 向系統申請內存，但是到真正與內核交互之間，其實還隔了一層，即內存分配管理器(memory allocator)。常見的內存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默認使用的是 glibc 的 ptmalloc 作為內存分配器。

內存分配器採用的是內存池的管理方式，處在用戶程序層和內核層之間，它響應用戶的分配請求，向操作系統申請內存，然後將其返回給用戶程序。

為了保持高效的分配，分配器通常會預先向操作系統申請一塊內存，當用戶程序申請和釋放內存的時候，分配器會將這些內存管理起來，並通過一些算法策略來判斷是否將其返回給操作系統。這樣做的最大好處就是可以避免用戶程序頻繁的調用系統來進行內存分配，使用戶程序在內存使用上更加高效快捷。

關於 ptmalloc 的內存分配原理，個人也不是非常了解，這裡就不班門弄斧了，有興趣的同學可以去看下華庭的《glibc 內存管理 ptmalloc 源代碼分析》【文末鏈接】。

關於如何選擇這三種內存分配器，網上資料大多都是推薦摒棄 glibc 原生的 ptmalloc，而改用 jemalloc 或者 tcmalloc 作為默認分配器。因為 ptmalloc 的主要問題其實是內存浪費、內存碎片、以及加鎖導致的性能問題，而 jemalloc 與 tcmalloc 對於內存碎片、多線程處理優化的更好。

目前 jemalloc 應用於 Firefox、FaceBook 等，並且是 MariaDB、Redis、Tengine 默認推薦的內存分配器，而 tcmalloc 則應用於 WebKit、Chrome 等。

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。

linux 下怎麼優化mysql佔用內存

內存分配器採用的是內存池的管理方式，處在用戶程序層和內核層之間，它響應用戶的分配請求，向操作系統申請內存，然後將其返回給用戶程序。

目前 jemalloc 應用於 Firefox、FaceBook 等，並且是 MariaDB、Redis、Tengine 默認推薦的內存分配器，而 tcmalloc 則應用於 WebKit、Chrome 等。

MySQL配置文件（my.cnf）路徑查看及相關配置

查找my.cnf文件路徑；

從上可以看出, 服務器首先會讀取/etc/my.cnf文件，如果發現該文件不存在，再依次嘗試從後面的幾個路徑進行讀取。

參數詳解：

[client] #客戶端設置，即客戶端默認的連接參數

port = 3307 #默認連接端口

socket = /data/mysqldata/3307/mysql.sock #用於本地連接的socket套接字

default-character-set = utf8mb4　#編碼

[mysqld] #服務端基本設置

port = 3307 MySQL監聽端口

socket = /data/mysqldata/3307/mysql.sock #為MySQL客戶端程序和服務器之間的本地通訊指定一個套接字文件

pid-file = /data/mysqldata/3307/mysql.pid#pid文件所在目錄

basedir = /usr/local/mysql-5.7.11#使用該目錄作為根目錄（安裝目錄）

datadir = /data/mysqldata/3307/data　#數據文件存放的目錄

tmpdir = /data/mysqldata/3307/tmp #MySQL存放臨時文件的目錄

character_set_server = utf8mb4 #服務端默認編碼（數據庫級別）

collation_server = utf8mb4_bin #服務端默認的比對規則，排序規則

user = mysql #MySQL啟動用戶

log_bin_trust_function_creators = 1 #This variable applies when binary logging is enabled. It controls whether stored function creators can be trusted not to create stored functions that will cause #unsafe events to be written to the binary log. If set to 0 (the default), users are not permitted to create or alter stored functions unless they have the SUPER #privilege in addition to the CREATE ROUTINE or ALTER ROUTINE privilege. 開啟了binlog後，必須設置這個值為1.主要是考慮binlog安全

performance_schema = 0 #性能優化的引擎，默認關閉

secure_auth = 1　#secure_auth 為了防止低版本的MySQL客戶端(

原創文章，作者：XNT7Q，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/127842.html