3

我有 3 张桌子：

CREATE TABLE `t_event` (
  `id` int(10) NOT NULL auto_increment,
  `title` varchar(100) NOT NULL,
  `kind` int(10) NOT NULL,
  `type` int(10) NOT NULL,
  `short_desc` varchar(500) default NULL,
  `long_desc` varchar(1500) default NULL,
  `location` int(10) NOT NULL,
  `price` decimal(11,0) NOT NULL,
  `currency` int(11) NOT NULL default '1',
  `remark_price` varchar(250) default NULL,
  `remark_prerequisite` varchar(250) default NULL,
  `date_start` date NOT NULL,
  `date_end` date default NULL,
  `date_remark` varchar(300) default NULL,
  `time_start` time default NULL,
  `time_end` time default NULL,
  `remark_time` varchar(50) default NULL,
  `leader` int(50) NOT NULL,
  `leader2` int(100) NOT NULL,
  `eve_contact_name` varchar(50) default NULL,
  `eve_contact_phone` varchar(50) default NULL,
  `eve_contact_email` varchar(50) default NULL,
  `eve_contact_url` varchar(150) default NULL,
  `eve_image_path` varchar(250) default NULL,
  `provider` int(10) default NULL,
  `timestamp` datetime NOT NULL,
  `last_change` datetime NOT NULL default '0000-00-00 00:00:00',
  `quality` int(10) default NULL,
  `min_number` int(10) NOT NULL,
  `max_number` int(10) NOT NULL,
  `active_for_reservation` tinyint(1) NOT NULL,
  `cancellation_day1` int(10) NOT NULL,
  `cancellation_day2` int(10) NOT NULL,
  `cancellation_fee1` varchar(255) NOT NULL,
  `cancellation_fee2` varchar(255) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `FK_t_event_t_event_kind` (`kind`),
  KEY `FK_t_event_t_event_type` (`type`),
  KEY `FK_t_event_t_location` (`location`),
  KEY `FK_t_event_t_currency` (`currency`),
  KEY `FK_t_event_t_leader` (`leader`),
  KEY `FK_t_event_t_provider` (`provider`),
  KEY `FK_t_event_t_quality` (`quality`),
  CONSTRAINT `FK_t_event_t_currency` FOREIGN KEY (`currency`) REFERENCES `t_currency` (`id`),
  CONSTRAINT `FK_t_event_t_event_kind` FOREIGN KEY (`kind`) REFERENCES `t_event_kind` (`id`),
  CONSTRAINT `FK_t_event_t_event_type` FOREIGN KEY (`type`) REFERENCES `t_event_type` (`id`),
  CONSTRAINT `FK_t_event_t_leader` FOREIGN KEY (`leader`) REFERENCES `t_leader` (`id`),
  CONSTRAINT `FK_t_event_t_location` FOREIGN KEY (`location`) REFERENCES `t_location` (`id`),
  CONSTRAINT `FK_t_event_t_provider` FOREIGN KEY (`provider`) REFERENCES `t_provider` (`id`),
  CONSTRAINT `FK_t_event_t_quality` FOREIGN KEY (`quality`) REFERENCES `t_quality` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=8432 DEFAULT CHARSET=latin1

CREATE TABLE `t_location` (
  `id` int(10) NOT NULL auto_increment,
  `loc_name` varchar(50) NOT NULL,
  `loc_detail` varchar(50) default NULL,
  `loc_adress1` varchar(50) NOT NULL,
  `loc_adress2` varchar(50) default NULL,
  `loc_country` int(50) NOT NULL default '1',
  `loc_zip` varchar(50) NOT NULL,
  `loc_loc` varchar(50) NOT NULL,
  `loc_shortdesc` varchar(250) default NULL,
  `loc_contact_name` varchar(250) default NULL,
  `loc_contact_gender` int(10) default NULL,
  `loc_contact_phone` varchar(250) default NULL,
  `loc_contact_email` varchar(250) default NULL,
  `loc_contact_url` varchar(250) default NULL,
  `loc_image_path` varchar(250) default NULL,
  `latitude` varchar(100) default NULL,
  `longitude` varchar(100) default NULL,
  `created` datetime NOT NULL,
  `last_change` datetime NOT NULL default '0000-00-00 00:00:00',
  `provider` int(10) NOT NULL default '1',
  PRIMARY KEY  (`id`),
  UNIQUE KEY `id` USING BTREE (`id`),
  KEY `FK_t_location_t_country` (`loc_country`),
  KEY `FK_t_location_t_gender` (`loc_contact_gender`),
  KEY `FK_t_location_t_provider` (`provider`),
  CONSTRAINT `FK_t_location_t_country` FOREIGN KEY (`loc_country`) REFERENCES `t_country`(`id`),
  CONSTRAINT `FK_t_location_t_provider` FOREIGN KEY (`provider`) REFERENCES `t_provider` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1287 DEFAULT CHARSET=latin1

CREATE TABLE `t_dates` (
  `id` int(10) NOT NULL auto_increment,
  `events_id` int(10) NOT NULL,
  `events_start_date` date NOT NULL,
  `events_end_date` date NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `IND_id` (`id`),
  KEY `IND_events_id` (`events_id`),
  CONSTRAINT `t_dates_ibfk_1` FOREIGN KEY (`events_id`) REFERENCES `t_event` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=32048 DEFAULT CHARSET=latin1

我的查询是：

SELECT e.*,I.* ,d.*
FROM t_event AS e
INNER JOIN t_location AS I ON   I.id = e.location
INNER JOIN t_dates  AS d ON  d.events_id  = e.id
;

此查询需要 90 秒才能执行并返回 = 27727

PROFILE 命令显示“发送数据”部分几乎占用了执行时间。EXPLAIN 命令如下：

+----+------------+------+------+----------------------------+--------------------+---------+-----------+-------+-------+
| id | select_type | table | type | possible_keys               | key                | key_len | ref       | rows | Extra |
+----+------------+------+------+----------------------------+--------------------+---------+-----------+-------+-------+
|  1 | SIMPLE     | I    | ALL | PRIMARY,id                 | NULL               | NULL    | NULL      |  1143 |       |
|  1 | SIMPLE     | e    | ref  | PRIMARY,FK_t_event_t_location | FK_t_event_t_location | 4       | wu_db.I.id |     4 |       |
|  1 | SIMPLE     | d    | ref  | IND_events_id               | IND_events_id       | 4       | wu_db.e.id |     3 |       |
+----+------------+------+------+----------------------------+--------------------+---------+-----------+-------+-------+

我的观点是，大量的列是造成这种减速的原因，但即使我写“SELECT e.id, I.events_id, d.id”，它仍然需要 16 秒。

我认为我必须用 LIMIT 和 OFFSET 子句重写查询，你怎么看？

每个表的记录数：

  • t_event = 7991
  • t_location = 1086
  • t_dates = 27727
4

2 回答 2

1

从广义上讲，MySQL 只能使用查询中每个表中的一个索引来过滤记录。

也就是说，虽然您的表在和t_event上都定义了索引，但只能使用其中一个索引来满足您的查询。您可以在输出中看到这一点，这表明和键都被确定为可能有用（后者实际选择使用）。idlocationEXPLAINPRIMARYFK_t_event_t_location

因此，您的与 连接t_dates（涉及对id列的测试）是通过表扫描而不是索引查找来完成的。EXPLAIN同样，您可以从显示type = ALL（表扫描）和key = NULL（未使用索引）的输出的第一行中看到这一点。

(id, location)您应该为您的t_event表创建一个复合索引：

ALTER TABLE t_event ADD INDEX (id, location);
于 2012-11-18T18:36:33.867 回答
0

我的观点是，大量列是造成这种减速的原因，但即使 > 当我写“SELECT e.id, I.events_id, d.id”时，它仍然需要 16 秒。

我认为我必须用 LIMIT 和 OFFSET 子句重写查询，你怎么看？

我想你是正确的。

如果您可以将速度提高无限JOIN倍，那么您将“选择”阶段减少到零，并且“发送数据”部分保持不变 - 这是另外 74 秒。

换句话说，查询优化的无限努力将使您在 90 秒中获得 16 秒的优势 - 总体上约为 18%。

如果这是批量查询，那么时间就不那么重要了；如果不是，我相信，那么我认为有人真的不太可能想要大约 27000 件物品的展示，甚至是概要。

除了“分页”方法，或者如果分页方法被证明不实用，甚至除了分页方法之外，您还可以查看您的应用程序是否可以使用某种“过滤”查询（日期范围、位置范围）。

所以我会研究什么WHERE条件可以用来使选择更精简。

如果它是一个 Web 应用程序，您可以SELECT只使用 ID（您已经尝试过的查询，这个查询只需要 16 秒；如果使用 WHERE，可能会更少），或者尽可能少的列。让我们想象一下，现在您正在显示一个非常长的页面，其中包含许多包含所有信息的“表单”，例如

...
+----------------------------------------+
| Date: ....  Place: ...... Notes: ....  |
| Leader: .... Cost: ....                |
  ... and so on and so forth ...
+----------------------------------------+
| Date: ....  Place: ...... Notes: ....  |
  ... and so on and so forth ...
+----------------------------------------+
...

相反，您可以只显示一组非常基本的、最少的信息，对应于您获取的列：

...
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
...

此时，用户将能够快速浏览列表，但几乎可以肯定不会打开所有这些表单，而只会打开两三个。当用户点击 时OPEN，jQuery 函数可以向服务器发出非常快速的 AJAX 调用，提供带有 ID 的数据；然后三个单独的查询将以毫秒为单位检索所有相关数据。

数据将被json_encode()d 发送回 jQuery，表单将“打开”以“手风琴”方式显示所有信息：

+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|
+----------------------------------------+
| Date: ....  Place: ......       <CLOSE>|
| large form with all the information
| ...
| ...
+----------------------------------------+
| Date: ....  Place: ......        <OPEN>|

这样您就不需要立即检索所有列，尤其是那些较大的列，例如short_desc和long_desc，它们之间可以达到两个完整的 Kb，但用户会体验到非常快速的响应。

于 2012-11-18T23:59:30.667 回答