Question

我有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

Answer 1

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

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

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

您应该在(id, location)表的t_event上创建一个综合索引：

ALTER TABLE t_event ADD INDEX (id, location);

Answer 2

我的观点是，大量的专栏负责这种放缓，但即使是＆gt;当我写“SELECT e.id，I.events_id，d.id”时，它仍需要16秒。

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

我认为你是对的。

如果你可以将JOIN加速无限，你可以将“选择”阶段减少到零，并保持“发送数据”部分不受影响 - 这是其他74秒。

换句话说，查询优化的无限努力将为您提供90秒内16秒的优势 - 总体上约为18％。

如果这是批量查询，则时间不是那么重要;如果不是，我相信，那么我认为某人不太可能想要一个大约27,000件物品的展示，甚至是大纲。

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

所以我研究了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，然而，用户会得到非常快速的响应。

如何通过两个内连接提高查询性能？

2 个答案: