linuxmysql優化

㈠ 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 = 2G*************************** 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_proced_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 = 2G*************************** 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_proced_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 =100G*************************** 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_proced_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 =100G*************************** 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_proced_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時採用源碼編譯安裝，但是如何讓MySQL的編譯時間縮短呢

可以試試在使用make && make install 時添加-j參數，不限制內核進行編譯安裝。或者-j 後加內核數 。例如 make -j 4 && make install -j 4
優點：速度快會相對提高很多
缺點：消耗大量CPU，內存資源。
我做過一個測試，如果不限定內核 （16核 80GB內存 ）的伺服器編譯安裝mysql 5.0.7 安裝時長大致在10分鍾左右，但是測試時伺服器CPU跑滿100% ，內存消耗至少32GB。直接使用 make && make install 安裝耗時45分鍾，內存4GB ，CPU 10%左右。

㈢ linux伺服器下mysql啟動慢，怎麼解決

0 先了解主機和資料庫的環境
#主機
內存多大，為了看有多少剩餘能為mysql留出多少來：free

資源使用情況，看負載情況，重點看空閑 CPU百分比(帶 xx% id)：top
#mysql
看mysql數據文件多大： -c -s /var/lib/mysql

1 初步調整（最主要的）
# 配置mysql的innodb內存佔用，根據上邊結果中剩餘內存（取80%）增加 innodb_buffer_pool_size的值
# 配置mysql的其它內存使用和緩存使用情況，不要加的太大，主要是 sort_buffer_size, join_buffer_size, key_cache_size。
配置依據是：總內存 - OS系統預留 - max_connections * (sort_buffer_size + join_buffer_size + read_buffer_size + read_rnd_buffer_size + thread_statck ) - key_cache_size > 0

2 優化調整（屬於優化性能方面）
主要是以下幾方面：
連接等待隊列數 back_log
客戶端請求線程緩存數 thread_cache_size
表緩沖的數量 table_open_cache
臨時表的內存大小，用於group by的優化 tmp_table_size

innodb日誌緩沖大小 innodb_log_buffer_size
innodb能打開表的數量大小（庫里的表特別多時增加此項值） innodb_open_files

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

修改mysql配置文件，優化緩存大小和連接數連接方式，優化sql語句 ,記得mysql好像是有工具可以查看最佔用資源的sql語句，找到他，優化他。

安裝好mysql後，配製文件應該在/usr/local/mysql/share/mysql目錄中，配製文件有幾個，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網站和不同配製的伺服器環境，當然需要有不同的配製文件了。

一般的情況下，my-medium.cnf這個配製文件就能滿足我們的大多需要；一般我們會把配置文件拷貝到/etc/my.cnf 只需要修改這個配置文件就可以了，使用mysqladmin variables extended-status _u root _p 可以看到目前的參數，有3個配置參數是最重要的，即key_buffer_size,query_cache_size,table_cache。

key_buffer_size只對MyISAM表起作用，

key_buffer_size指定索引緩沖區的大小，它決定索引處理的速度，尤其是索引讀的速度。一般我們設為16M,實際上稍微大一點的站點這個數字是遠遠不夠的，通過檢查狀態值Key_read_requests和Key_reads,可以知道key_buffer_size設置是否合理。比例 key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE 『key_read%』獲得）。 或者如果你裝了phpmyadmin 可以通過伺服器運行狀態看到,筆者推薦用phpmyadmin管理mysql，以下的狀態值都是本人通過phpmyadmin獲得的實例分析:

這個伺服器已經運行了20天

key_buffer_size _ 128M

key_read_requests _ 650759289

key_reads - 79112

比例接近1:8000 健康狀況非常好

㈤ linux怎麼修改mysql資料庫臨時表空間大小

以MySQL 8.0 來說，通過查看 8.0 的官方文檔得知，8.0 的臨時表空間分為會話臨時表空間和全局臨時表空間，會話臨時表空間存儲用戶創建的臨時表和當 InnoDB 配置為磁碟內部臨時表的存儲引擎時由優化器創建的內部臨時表，當會話斷開連接時，其臨時表空間將被截斷並釋放回池中；也就是說，在 8.0 中有一個專門的會話臨時表空間，當會話被殺掉後，可以回收磁碟空間；而原來的 ibtmp1 是現在的全局臨時表空間，存放的是對用戶創建的臨時表進行更改的回滾段，在 5.7 中 ibtmp1 存放的是用戶創建的臨時表和磁碟內部臨時表；

也就是在 8.0 和 5.7 中 ibtmp1 的用途發生了變化，5.7 版本臨時表的數據存放在 ibtmp1 中，在 8.0 版本中臨時表的數據存放在會話臨時表空間，如果臨時表發生更改，更改的 undo 數據存放在 ibtmp1 中；

總結：在 mysql5.7 時，殺掉會話，臨時表會釋放，但是僅僅是在 ibtmp 文件里標記一下，空間是不會釋放回操作系統的。如果要釋放空間，需要重啟資料庫；在 mysql8.0 中可以通過殺掉會話來釋放臨時表空間。

㈥ Linux上MySQL優化提升性能，哪些可以優化關閉NUMA特性

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

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