我的页面上有实时搜索。当向服务器发送请求时，接受过滤和排序参数（开发商、发行商、流派、时间等）。问题在于它的执行需要相当长的时间，并且由于用户输入的每个字符都会触发脚本，因此这不得不引起人们的注意。如果在搜索时省略其他参数并以开发人员为例，您将得到以下查询（执行时间约为 0.14 秒，但在表单中输入时，当然运行速度会更慢）：
SELECT games.id AS id FROM games LEFT JOIN games_titles ON games.id=games_titles.game_id WHERE games_titles.lang=1 AND EXISTS(SELECT 1 FROM games_devs WHERE games_devs.game_id=games.id AND games_devs.dev LIKE ‘de%’) ORDER BY games.rating DESC LIMIT 6
解释：
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 1 | PRIMARY | games | index | PRIMARY | rating_index | 8 | NULL | 1 | Using index |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 1 | PRIMARY |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 1 | PRIMARY | games_titles | ref | game_id_index,lang | game_id_index | 4 | test_db.games.id | 1 | Using index condition; Using where |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 2 | MATERIALIZED | games_devs | range | PRIMARY,dev | dev | 452 | NULL | 49994 | Using where; Using index |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
分析：
±—±-----------------------±-------+
| 1 | Starting | 103 µs |
±—±-----------------------±-------+
| 2 | Checking Permissions | 16 µs |
±—±-----------------------±-------+
| 3 | Opening Tables | 32 µs |
±—±-----------------------±-------+
| 4 | After Opening Tables | 11 µs |
±—±-----------------------±-------+
| 5 | System Lock | 11 µs |
±—±-----------------------±-------+
| 6 | Table Lock | 25 µs |
±—±-----------------------±-------+
| 7 | Init | 48 µs |
±—±-----------------------±-------+
| 8 | Optimizing | 50 µs |
±—±-----------------------±-------+
| 9 | Statistics | 145 µs |
±—±-----------------------±-------+
| 10 | Preparing | 92 µs |
±—±-----------------------±-------+
| 11 | Sorting Result | 23 µs |
±—±-----------------------±-------+
| 12 | Executing | 46 µs |
±—±-----------------------±-------+
| 13 | Query End | 14 µs |
±—±-----------------------±-------+
| 14 | Removing Tmp Table | 13 µs |
±—±-----------------------±-------+
| 15 | Query End | 9 µs |
±—±-----------------------±-------+
| 16 | Commit | 11 µs |
±—±-----------------------±-------+
| 17 | Closing Tables | 10 µs |
±—±-----------------------±-------+
| 18 | Unlocking Tables | 9 µs |
±—±-----------------------±-------+
| 19 | Closing Tables | 15 µs |
±—±-----------------------±-------+
| 20 | Starting Cleanup | 9 µs |
±—±-----------------------±-------+
| 21 | Freeing Items | 19 µs |
±—±-----------------------±-------+
| 22 | Updating Status | 73 µs |
±—±-----------------------±-------+
| 23 | Reset For Next Command | 19 µs |
±—±-----------------------±-------+
由于我在网站上有分页，因此我需要获取所有条目的数量，以便可以转到最后一页。但在这种情况下，性能受到的影响更大（在页面上搜索时需要 1.97 秒）：
SELECT games.id AS id FROM games LEFT JOIN games_titles ON games.id=games_titles.game_id WHERE games_titles.lang=1 AND EXISTS(SELECT 1 FROM games_devs WHERE games_devs.game_id=games.id AND games_devs.dev LIKE ‘de%’) ORDER BY games.rating
解释：
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 1 | PRIMARY | games | index | PRIMARY | rating_index | 8 | NULL | 99889 | Using index |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 1 | PRIMARY |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 1 | PRIMARY | games_titles | ref | game_id_index,lang | game_id_index | 4 | test_db.games.id | 1 | Using index condition; Using where |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
| 2 | MATERIALIZED | games_devs | range | PRIMARY,dev | dev | 452 | NULL | 49994 | Using where; Using index |
±—±-------------±-------------±-------±-------------------±--------------±--------±-----------------±------±-----------------------------------+
分析：
±—±-----------------------±-------+
| 1 | Starting | 150 µs |
±—±-----------------------±-------+
| 2 | Checking Permissions | 19 µs |
±—±-----------------------±-------+
| 3 | Opening Tables | 30 µs |
±—±-----------------------±-------+
| 4 | After Opening Tables | 12 µs |
±—±-----------------------±-------+
| 5 | System Lock | 11 µs |
±—±-----------------------±-------+
| 6 | Table Lock | 13 µs |
±—±-----------------------±-------+
| 7 | Init | 57 µs |
±—±-----------------------±-------+
| 8 | Optimizing | 49 µs |
±—±-----------------------±-------+
| 9 | Statistics | 142 µs |
±—±-----------------------±-------+
| 10 | Preparing | 93 µs |
±—±-----------------------±-------+
| 11 | Sorting Result | 22 µs |
±—±-----------------------±-------+
| 12 | Executing | 21 µs |
±—±-----------------------±-------+
| 13 | Sending Data | 182 ms |
±—±-----------------------±-------+
| 14 | End Of Update Loop | 28 µs |
±—±-----------------------±-------+
| 15 | Removing Tmp Table | 790 µs |
±—±-----------------------±-------+
| 16 | End Of Update Loop | 15 µs |
±—±-----------------------±-------+
| 17 | Query End | 9 µs |
±—±-----------------------±-------+
| 18 | Commit | 11 µs |
±—±-----------------------±-------+
| 19 | Closing Tables | 10 µs |
±—±-----------------------±-------+
| 20 | Unlocking Tables | 9 µs |
±—±-----------------------±-------+
| 21 | Closing Tables | 17 µs |
±—±-----------------------±-------+
| 22 | Starting Cleanup | 9 µs |
±—±-----------------------±-------+
| 23 | Freeing Items | 19 µs |
±—±-----------------------±-------+
| 24 | Updating Status | 75 µs |
±—±-----------------------±-------+
| 25 | Reset For Next Command | 18 µs |
±—±-----------------------±-------+
CREATE TABLE games (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
rating double NOT NULL DEFAULT 0,
date date DEFAULT NULL,
date_type int(1) NOT NULL DEFAULT 1,
img varchar(500) DEFAULT NULL,
img_type int(10) NOT NULL,
url varchar(100) NOT NULL,
PRIMARY KEY (id),
KEY rating_index (rating) USING BTREE,
KEY date_index (date) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=326678 DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci
CREATE TABLE games_titles (
game_id int(50) NOT NULL,
title varchar(150) DEFAULT NULL,
lang int(10) NOT NULL DEFAULT 1,
KEY game_id_index (game_id) USING BTREE,
KEY lang (lang,title)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci
CREATE TABLE games_devs (
id int(50) NOT NULL AUTO_INCREMENT,
game_id int(50) NOT NULL,
dev varchar(150) NOT NULL,
PRIMARY KEY (id),
KEY game_id_index (game_id) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=126699 DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci
该请求还会按语言进行检查，因为该网站是多语言的。但我决定省略这些细节，因为这里的主要负载仍然来自搜索本身。我还没有将索引放在“dev”字段上，其余的一切都已设置完毕。您可以看到上面表格的结构。
您能告诉我如何提高搜索性能或者您可以提供什么替代 LIKE 运算符吗？我听说很多人不建议使用它。现在在“dev”表中，条目的形式为“dev_1”、“dev_2”等。如果在形式中输入字母“p”，则脚本将被触发约10毫秒，其中字母“d”当然，绕过所有选项需要更长的时间。当然，我知道在实际制作中写作会有更多变化，但这里最好的解决方案是什么？分页时，每增加一页，搜索时间就会增加（逻辑上，因为MySQL算法需要生成一个新的数据集，但是从初始位置做一个缩进），恐怕会花很长时间，
评论
