500000條記錄后MySQL變得極其緩慢

Question

我正在使用phpMyAdmin 4.2.7.1。 MySQL 5.6.16。 MS Windows Server 2012 R2 Standard，4GB RAM，Intel Xeon E5-2620 @ 2.00GHz。 幾天前，我在MySQL查詢中遇到了問題，該問題之前運行很快。 過去，平均查詢返回結果的速度要快5分鍾，而現在即使經過幾個小時也無法返回結果。 這是我創建的視圖：

CREATE ALGORITHM=UNDEFINED DEFINER=root@localhost SQL SECURITY DEFINER 
VIEW okp_view AS 
     select q.MessageId AS MessageId,
q.SenderTimeStamp AS SenderTimeStamp,
r.GsbId AS GsbId,
r.ReceiverTimeStamp AS ReceiverTimeStamp,
r.FinalTimeStamp AS FinalTimeStamp,
k.ErrorCode AS ErrorCodeRes,
t.ErrorType AS ErrorTypeRes,
g.ID AS ID,
g.OIB AS OIB,
g.MssgText AS MssgText,
s.ErrorCode AS ErrorCodeResMssg,
m.ErrorType AS ErrorTypeMssg 
     from ((((((soap_req_env q 
join soap_res_env r) 
join soap_res_err k) 
join res_err_type t) 
join soap_message g) 
join soap_mssg_err s) 
join mssg_err_type m) 
     where ((q.MessageId = g.MessageId) 
and (g.ID = s.ID) 
and (s.ErrorCode = m.ErrorCode) 
and (q.MessageId = r.MessageId) 
and (r.GsbId = k.GsbId) 
and (k.ErrorCode = t.ErrorCode)) 
order by q.SenderTimeStamp desc;

視圖包含超過500000條記錄。 這些是MySQL表上的索引：

TABLE_NAME,INDEX_NAME
mssg_err_type,ErrorCode
registar_e_poruka_za_okp,PRIMARY
registar_e_poruka_za_okp,fk_Registar_e_poruka_za_OKP_Sifarnik_posiljatelja_e_poruka1_idx
registar_e_poruka_za_okp,fk_Registar_e_poruka_za_OKP_Sifarnik_zivotnih_situacija1_idx
registar_e_poruka_za_okp,fk_Registar_e_poruka_za_OKP_Sifarnik_tema1_idx
registar_e_poruka_za_okp,fk_Registar_e_poruka_za_OKP_Sifarnik_razine_pouzdanosti_vje_idx
registar_e_poruka_za_okp,fk_Registar_e_poruka_za_OKP_Sifarnik_tipa_privitka1_idx
registar_e_poruka_za_okp,fk_Registar_e_poruka_za_OKP_Sifarnik_frekvencije_slanja_por_idx
registar_e_poruka_za_okp,fk_Registar_e_poruka_za_OKP_Sifarnik_statusa_e_poruke1_idx
res_err_type,ErrorCode
soap_message,PRIMARY
soap_message,MessageId
soap_mssg_err,ID
soap_mssg_err,ErrorCode
soap_req_env,PRIMARY
soap_res_env,PRIMARY
soap_res_env,MessageId
soap_res_err,GsbId
soap_res_err,ErrorCode

現在，MySQL為我提供了該查詢的數據：

SELECT * FROM okp_view WHERE SenderTimeStamp>="2015-05-25" 
Showing rows 0 - 24 (2132 total, Query took 13.9374 seconds.) 

如果我嘗試使用以下方法檢索更大的子集：

SELECT * FROM okp_view WHERE SenderTimeStamp>="2015-05-24"    

但是要花很長時間

如何改善數據庫架構以優化數據庫並加快數據檢索。

編輯：如果我使用查詢而不查看它需要很長時間：

select * from soap_req_env q, soap_res_env r, soap_res_err k, res_err_type t, soap_message g, soap_mssg_err s, mssg_err_type m
where q.messageid=g.messageid
and g.id=s.id
and s.errorcode=m.errorcode
and q.messageid=r.messageid
and r.gsbid=k.gsbid
and k.errorcode=t.errorcode
and q.sendertimestamp>="2015-05-15"
ORDER BY `q`.`SenderTimeStamp` DESC

SHOW VARIABLES LIKE '%buffer%'; 是

Variable_name   Value
bulk_insert_buffer_size     8388608
innodb_buffer_pool_dump_at_shutdown     OFF
innodb_buffer_pool_dump_now     OFF
innodb_buffer_pool_filename     ib_buffer_pool
innodb_buffer_pool_instances    8
innodb_buffer_pool_load_abort   OFF
innodb_buffer_pool_load_at_startup  OFF
innodb_buffer_pool_load_now     OFF
innodb_buffer_pool_size     16777216
innodb_change_buffer_max_size   25
innodb_change_buffering     all
innodb_log_buffer_size  8388608
innodb_sort_buffer_size     1048576
join_buffer_size    262144
key_buffer_size     16777216
myisam_sort_buffer_size     8388608
net_buffer_length   8192
preload_buffer_size     32768
read_buffer_size    262144
read_rnd_buffer_size    524288
sort_buffer_size    524288
sql_buffer_result   OFF

我的表的結構是：

CREATE TABLE `soap_req_env` (
 `MessageId` char(36) COLLATE utf8_croatian_ci NOT NULL,
 `SenderTimeStamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (`MessageId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_croatian_ci

    CREATE TABLE `soap_res_env` (
 `MessageId` char(36) COLLATE utf8_croatian_ci NOT NULL,
 `GsbId` char(36) COLLATE utf8_croatian_ci NOT NULL DEFAULT '',
 `ReceiverTimeStamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 `FinalTimeStamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (`GsbId`),
 KEY `MessageId` (`MessageId`),
 CONSTRAINT `soap_res_env_ibfk_1` FOREIGN KEY (`MessageId`) REFERENCES `soap_req_env` (`MessageId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_croatian_ci

CREATE TABLE `soap_res_err` (
 `GsbId` char(36) COLLATE utf8_croatian_ci NOT NULL,
 `ErrorCode` char(4) COLLATE utf8_croatian_ci NOT NULL,
 UNIQUE KEY `GsbId` (`GsbId`,`ErrorCode`),
 KEY `ErrorCode` (`ErrorCode`),
 CONSTRAINT `soap_res_err_ibfk_2` FOREIGN KEY (`ErrorCode`) REFERENCES `res_err_type` (`ErrorCode`),
 CONSTRAINT `soap_res_err_ibfk_3` FOREIGN KEY (`GsbId`) REFERENCES `soap_res_env` (`GsbId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_croatian_ci

 CREATE TABLE `res_err_type` (
 `ErrorCode` char(4) COLLATE utf8_croatian_ci NOT NULL,
 `ErrorType` text COLLATE utf8_croatian_ci NOT NULL,
 UNIQUE KEY `ErrorCode` (`ErrorCode`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_croatian_ci

CREATE TABLE `soap_message` (
 `ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
 `MessageId` char(36) COLLATE utf8_croatian_ci NOT NULL,
 `OIB` char(11) COLLATE utf8_croatian_ci NOT NULL,
 `MssgText` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
 PRIMARY KEY (`ID`),
 UNIQUE KEY `MessageId` (`MessageId`,`OIB`),
 CONSTRAINT `soap_message_ibfk_1` FOREIGN KEY (`MessageId`) REFERENCES `soap_req_env` (`MessageId`)
) ENGINE=InnoDB AUTO_INCREMENT=571197 DEFAULT CHARSET=utf8 COLLATE=utf8_croatian_ci

CREATE TABLE `soap_mssg_err` (
 `ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
 `ErrorCode` char(4) COLLATE utf8_croatian_ci NOT NULL,
 KEY `ID` (`ID`),
 KEY `ErrorCode` (`ErrorCode`),
 CONSTRAINT `soap_mssg_err_ibfk_2` FOREIGN KEY (`ErrorCode`) REFERENCES `mssg_err_type` (`ErrorCode`),
 CONSTRAINT `soap_mssg_err_ibfk_3` FOREIGN KEY (`ID`) REFERENCES `soap_message` (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=571197 DEFAULT CHARSET=utf8 COLLATE=utf8_croatian_ci

CREATE TABLE `mssg_err_type` (
 `ErrorCode` char(4) COLLATE utf8_croatian_ci NOT NULL,
 `ErrorType` text COLLATE utf8_croatian_ci NOT NULL,
 UNIQUE KEY `ErrorCode` (`ErrorCode`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_croatian_ci

Answer 1

UUID的弊端

（我在這里四處走動，不確定是否涉及UUID。）

MessageId CHAR（36）COLLATE utf8 ...主鍵

它聞起來像一個十六進制字符串，是“ UUID”； 我以為是。

問題1

CHAR(36) CHARACTER SET utf8出現的所有位置都會占用108個字節。 它似乎是多個表中的一個鍵，並且可能顯示在輔助表中（InnoDB在每個輔助鍵中都隱含地包含了PRIMARY KEY 。）對於500K記錄，這加起來很多兆字節，甚至可能是千兆字節。

修復＃1：

CHAR(36) CHARACTER SET ascii只有36個字節。

修復＃2：

將其轉換為二進制文件並將其存儲在BINARY(16) ，它將僅占用16個字節。 我的UUID博客提供了轉換代碼。

問題二

UUID非常隨機 。 一旦UUID索引大於innodb_buffer_pool_size（如果為MyISAM，則為key_buffer_size）中可以緩存的索引，那么越來越多的查找必須命中磁盤。 例如，當索引的大小是緩存的20倍時，95％（或更多）的查找需要磁盤命中。