500000 条记录后 MySQL 变得非常慢
After 500000 records MySQL become extremely slow
我正在使用 phpMyAdmin 4.2.7.1。 MySQL 5.6.16。 MS Windows Server 2012 R2 标准版，4GB 内存，Intel Xeon E5-2620 @ 2.00GHz。几天前，我在 MySQL 查询中遇到了问题，该问题以前运行得很快。在过去，平均查询会 return 结果快于 5 分钟，现在即使在几个小时后也不能 return 结果。这是我创建的视图：
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
UUID的弊端
（我在这里冒险，不确定是否涉及 UUID。）
MessageId CHAR(36) COLLATE utf8... PRIMARY KEY
闻起来像 "UUID" 的十六进制字符串；我假设它是。
问题 #1
CHAR(36) CHARACTER SET utf8 在任何地方都占用 108 个字节。它似乎是多个表中的一个键，并且可能出现在辅助键中（InnoDB 在每个辅助键中隐含地包含 PRIMARY KEY。）对于 500K 记录，加起来有很多兆字节，可能是千兆字节。
修复 #1：
CHAR(36) CHARACTER SET ascii 将只有 36 个字节。
修复 #2：
将其转换为二进制并存储在BINARY(16)中，这样只需要16个字节。我的 UUID blog 提供了转换代码。
问题#2
UUID 非常随机。一旦 UUID 索引大于可以缓存在 innodb_buffer_pool_size（或 key_buffer_size，如果 MyISAM）中，越来越多的查找必须命中磁盘。例如，当索引是缓存的 20 倍时，95%（或更多）的查找需要磁盘命中。
我正在使用 phpMyAdmin 4.2.7.1。 MySQL 5.6.16。 MS Windows Server 2012 R2 标准版，4GB 内存，Intel Xeon E5-2620 @ 2.00GHz。几天前，我在 MySQL 查询中遇到了问题，该问题以前运行得很快。在过去，平均查询会 return 结果快于 5 分钟，现在即使在几个小时后也不能 return 结果。这是我创建的视图：
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
UUID的弊端
（我在这里冒险，不确定是否涉及 UUID。）
MessageId CHAR(36) COLLATE utf8... PRIMARY KEY
闻起来像 "UUID" 的十六进制字符串；我假设它是。
问题 #1
CHAR(36) CHARACTER SET utf8 在任何地方都占用 108 个字节。它似乎是多个表中的一个键，并且可能出现在辅助键中（InnoDB 在每个辅助键中隐含地包含 PRIMARY KEY。）对于 500K 记录，加起来有很多兆字节，可能是千兆字节。
修复 #1：
CHAR(36) CHARACTER SET ascii 将只有 36 个字节。
修复 #2：
将其转换为二进制并存储在BINARY(16)中，这样只需要16个字节。我的 UUID blog 提供了转换代码。
问题#2
UUID 非常随机。一旦 UUID 索引大于可以缓存在 innodb_buffer_pool_size（或 key_buffer_size，如果 MyISAM）中，越来越多的查找必须命中磁盘。例如，当索引是缓存的 20 倍时，95%（或更多）的查找需要磁盘命中。