共計 3087 個字符，預計需要花費 8 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關 MySQL 優化案例的初步思路是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
今天想起這件同事處理的一個性能優化案例，當時雖然解決了，但是還是留下了幾個未解的問題，和大家一起討論一下。
首先，這個問題是根據反饋 sql 響應很慢，已經開始影響前端應用的登錄了。稍后 DBA 介入，發現是由于 CPU 使用率過高導致，為了能夠延緩問題和進一步分析，因為數據庫中的數據量不大，直接就遷移到了另外一臺配置不錯的服務器上，但是遷移之后，CPU 配置好了很多，問題依舊，同時也在進行問題的診斷和分析。
得到的慢日志如下，發現大多數的響應時間都耗費在了兩個 SQL 上，其實出自同一個存儲過程。
1、慢日志
# Profile
# Rank Query ID Response time Calls R/Call V/M Item
# ==== ================== =============== ===== ======= ===== ============
# 1 0x26EEFEA86049462C 7667.3733 44.3% 189 40.5681 6.88 CALL p_register_check_1021e
# 2 0x6D5C3CEFC40B5E28 7518.4182 43.5% 189 39.7800 6.10 UPDATE push_list_s
兩個查詢的統計信息如下：
# Query 1: 0.30 QPS, 12.15x concurrency, ID
0x26EEFEA86049462C at byte 976472
# This item is included in the report
because it matches –limit.
# Scores: V/M = 6.88
# Time range: 2015-11-02 21:41:53 to
21:52:24
# Attribute
pct total min
max avg 95% stddev
median
# ============ === ======= ======= =======
======= ======= ======= =======
#
Count
3 189
# Exec time 44
7667s 1s
90s 41s
57s 17s 45s
# Query 2: 0.30 QPS, 11.92x concurrency, ID
0x6D5C3CEFC40B5E28 at byte 1397182
# This item is included in the report
because it matches –limit.
# Scores: V/M = 6.10
# Time range: 2015-11-02 21:41:53 to
21:52:24
# Attribute
pct total min
max avg 95% stddev
median
# ============ === ======= ======= =======
======= ======= ======= =======
#
Count
3 189
# Exec time
43 7518s 1s
77s 40s
57s 16s 45s
# Lock time
30 65s 13us
19s 343ms 21us
2s 18us
相關的 SQL 語句如下
# Converted for EXPLAIN
# EXPLAIN /*!50100 PARTITIONS*/
select APNS_PUSH_ID = `ID` from push_list_s where
APNS_PUSH_ID =
NAME_CONST(i_apnsPushId ,_utf8 eb43f3f09940de7228a780f69d05eab0a9df98083c701e23d11c7494a980b351
COLLATE utf8_general_ci )\G
涉及的表只有一個，表結構如下：
Create Table: CREATE TABLE `push_list_s` (
`ID` int(10) NOT NULL
AUTO_INCREMENT,
`SN_LIST_ID` int(10) NOT NULL
DEFAULT 0 ,
。。。
`APNS_PUSH_ID` varchar(64) CHARACTER
SET latin1 NOT NULL DEFAULT ,
。。。
PRIMARY KEY (`ID`),
UNIQUE KEY `INDEX_SN_LIST_ID`
(`SN_LIST_ID`),
UNIQUE KEY `APNS_PUSH_ID`
(`APNS_PUSH_ID`),
KEY `INDEX_CABLE_PUSH_ID` (`CABLE_PUSH_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=2181938
DEFAULT CHARSET=utf8
整個調用過程的要點如下，里面有一個 update 操作，字段 APNS_PUSH_ID 為 varchar
IF
(LENGTH(i_apnsPushId)=64) THEN
UPDATE push_list_s SET APNS_PUSH_ID = `ID` WHERE APNS_PUSH_ID = i_apnsPushId;
END IF;
運行的語句類似下面的形式:
UPDATE push_list_s SET APNS_PUSH_ID = `ID` WHERE APNS_PUSH_ID = eb43f3f09940de7228a780f69d05eab0a9df98083c701e23d11c7494a980b351
初步的分析懷疑是由于索引為字符過長導致，所以根據表的結構信息，其實就是轉換到了數字類型的字段上。
修改后的部分如下：
IF
(LENGTH(i_apnsPushId)=64) THEN
select ID into v_id from push_list_s WHERE APNS_PUSH_ID = i_apnsPushId;
IF (v_id 0) THEN
UPDATE push_list_s SET APNS_PUSH_ID = v_id WHERE ID = v_id;
END IF;
END IF;
這是優化前后的對比效果圖：
目前對于這個問題的疑問如下：
1. 對于字符型字段作為索引，目前來看沒有很直接的原因使得字符型索引和數字型索引存在巨大的差別。從后來我單獨得到的執行計劃和華寧復現情況來看，沒有發現存在很巨大的差別。
2. 對于慢日志中得到的語句，看到內部已經做了轉換。
UPDATE push_list_s SET APNS_PUSH_ID = `ID` WHERE APNS_PUSH_ID = NAME_CONST(i_apnsPushId ,_utf8 eb43f3f09940de7228a780f69d05eab0a9df98083c701e23d11c7494a980b351 COLLATE utf8_general_ci)\G
而對于這種轉換，可能關注點都在 NAME_CONST 這個部分，在查看了一些資料之后，發現在其他版本和環境中，主要是和字符集轉換有關，但是我查看了當前環境的這些配置信息，沒有發現有相匹配的信息
3. 關于這個問題，在 5.1 版本中發現了相應的 bug 描述，但是目前的環境是在 5.6，所以應該也不是相關。
關于這個問題的進一步分析，我希望得到一些確切的信息，能夠復現，能夠找到一些相關的 bug 或者相關的解決方案（除了使用數字型字符臨時替換的方案)
上述就是丸趣 TV 小編為大家分享的 MySQL 優化案例的初步思路是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
