相关疑难解决方法(0)

几乎在任何地方,我FORCE INDEX都非常沮丧地使用它,我完全理解并知道原因 - MySQL有更大的机会知道哪些索引比(普通)开发人员更好.

但是,最近我发现了一个案例,它FORCE INDEX在几百次的范围内改进了我的执行时间:

• JOIN 在4张桌子上
• 第一张表有大约500 000条记录
• INNER JOINed表中的2个有超过1百万的记录
• 第一个表有一个名为的字段published_date,varchar以YMD格式存储(无法更改为datetime)
• 需要published_date最多5 000条记录的范围
• 第一个表上的一些其他GROUP BY和ORDER BY子句在不同的字段上,而不是published_date此查询所需的

虽然我以多种方式重写了查询,但我的执行时间不到130秒(最高超过700秒).使用FORCE INDEX后published_date,执行时间降至5秒以下.

我花了几天时间才想起臭名昭着的FORCE INDEX选择.

问题:

• 您找到的其他用例是什么FORCE INDEX？
• 考虑使用时,您是否有一些最佳实践FORCE INDEX？

编辑 - Obsevations: 我也在这里创建了这篇博文.你提供的所有答案也会出现在那里 - 有学分和你想要的所有东西.

编辑2

I applied the suggestions I received in your comments (ANALYZE TABLE and OPTIMIZE …

mysql> desc temp1;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| value | varchar(255) | YES  |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+

mysql> desc temp2;
+-------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------+------+-----+---------+-------+
| value | text | YES  |     | NULL    |       |
+-------+------+------+-----+---------+-------+

255-每行中有一个“ a”字符（在两个表中）

mysql> select * from temp1 limit 1;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| value                                                                                                                                                                                                                                                           |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

mysql> select …

样本表：

+----+-------+-------+-------+-------+-------+---------------+
| id | col1  | col2  | col3  | col4  | col5  | modifiedTime  |
+----+-------+-------+-------+-------+-------+---------------+
|  1 | temp1 | temp2 | temp3 | temp4 | temp5 | 1554459626708 |
+----+-------+-------+-------+-------+-------+---------------+ 

上表有5000万条记录

1. （col1、col2、col3、col4、col5 这些是 VARCHAR 列）
2. （id为PK）
3. (修改时间)

每列都有索引

例如：我的网站中有两个选项卡。

FirstTab - 我使用以下条件打印上表的计数 [col1 如“value1%”，col2 如“value2%”]

SeocndTab - 我使用以下条件打印上表的计数 [col3 like“value3%”]

由于我有 5000 万条记录，因此按照这些标准进行计数需要很长时间才能得到结果。

注意：我有时会更改记录数据（表中的行）。插入新行。删除不需要的记录。

我需要一个可行的解决方案，而不是查询整个表。例如：就像缓存旧计数一样。这样的事有可能吗？

我需要Contains在列中执行操作。对于包含操作，我们需要在单词前后使用通配符。

例如：个性化

查询 -> like '%sonal%'

因为这种类型的查询不能使用索引。有什么办法可以提高搜索速度。

注意：我使用MySql(InnoDB)和PSQL