我有2个表与关系表连接。
有关表格的更多详情：
id (index)
store_name
city_id (index)
...
id (index)
cat_name
store_id
cat_id
每家商店都属于一个或多个类别。
在store_cat_relation表中，我有（store_id，cat_id）和（cat_id，store_id）索引。
我需要在巴黎（city_id = 1）找到超级市场（cat_id = 1）的总量。我有一个有效的查询，但是当数据库在巴黎有很多商店或数据库有很多超市时需要很长时间。 这是我的问题：
SELECT COUNT(*) FROM stores s, store_cat_relation r WHERE s.city_id = '1' AND r.cat_id = '1' AND s.id = r.store_id
此查询大约需要0.05秒。数据库包含约8000家超市（1类商店）和巴黎约8000家商店（store_id = 1）。目前巴黎共有550家超市。
我想将查询时间缩短到0,01以下，因为数据库只会变大。
EXPLAIN的结果是：
id: 1
select_type: SIMPLE
table: store_cat_relation
type: ref
possible_keys: cat_id_store_id, store_id_cat_id
key: cat_id_store_id
key_len: 4
ref: const
rows: 8043
Extra: Using index
***************************************
id: 1
select_type: SIMPLE
table: stores
type: eq_ref
possible_keys: PRIMARY, city_id
key: PRIMARY
key_len: 4
ref: store_cat_relation.store_id
rows: 1
Extra: Using index condition; Using where
任何人都知道为什么这个查询花了这么长时间？
编辑：我还创建了一个每个表300行的SQL小提琴。行数较少，速度非常快，但我需要快速处理+100.000行。答案 0 :(得分：3)
我做了一些测试，最好的表现是使用查询缓存。您可以启用它们并使用它 ON DEMAND 。所以你可以说哪些查询插入到缓存中。如果你想使用它，你必须在/etc/my.cnf中进行更改以使它们持久化。如果更改表，您还可以运行一些查询来预热缓存
这是一个示例
表格大小
MariaDB [yourSchema]> select count(*) from stores;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (1 min 23.50 sec)
MariaDB [yourSchema]> select count(*) from store_cat_relation;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (2.45 sec)
MariaDB [yourSchema]>
验证缓存已开启
MariaDB [yourSchema]> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| have_query_cache | YES |
+------------------+-------+
1 row in set (0.01 sec)
设置缓存大小和需求
MariaDB [yourSchema]> SET GLOBAL query_cache_size = 1000000;
Query OK, 0 rows affected, 1 warning (0.00 sec)
MariaDB [yourSchema]> SET GLOBAL query_cache_type=DEMAND;
Query OK, 0 rows affected (0.00 sec)
启用性能分析
MariaDB [yourSchema]> set profiling=on;
首先执行您的查询 - 需要0.68秒
MariaDB [yourSchema]> SELECT SQL_CACHE COUNT(*) FROM stores s, store_cat_relation r WHERE s.city_id = '1' AND r.cat_id = '1' AND s.id = r.store_id;
+----------+
| COUNT(*) |
+----------+
| 192 |
+----------+
1 row in set (0.68 sec)
现在从缓存中获取
MariaDB [yourSchema]> SELECT SQL_CACHE COUNT(*) FROM stores s, store_cat_relation r WHERE s.city_id = '1' AND r.cat_id = '1' AND s.id = r.store_id;
+----------+
| COUNT(*) |
+----------+
| 192 |
+----------+
1 row in set (0.00 sec)
请参阅美国持续时间的个人资料
MariaDB [yourSchema]> show profile;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000039 |
| Waiting for query cache lock | 0.000008 |
| init | 0.000005 |
| checking query cache for query | 0.000056 |
| checking privileges on cached | 0.000026 |
| checking permissions | 0.000014 |
| checking permissions | 0.000025 |
| sending cached result to clien | 0.000027 |
| updating status | 0.000048 |
| cleaning up | 0.000025 |
+--------------------------------+----------+
10 rows in set (0.05 sec)
MariaDB [yourSchema]>
答案 1 :(得分：2)
您正在关注的是索引方案：
使用优化器，DBMS会尝试查找数据的最佳路径。根据数据本身的不同，这可能会导致不同的访问路径，具体取决于提供的条件（WHERE / JOINS / GROUP BY，有时是ORDER BY）。此处的数据分布可能是快速查询或查询速度非常慢的关键。
所以你现在有2个表，store和store_cat_relation。在商店，你有2个索引：
你有一个关于city_id的地方，以及一个关于id的连接。然后，DBMS引擎中的内部执行如下：
1）阅读索引city_id 2）然后读取表（ok，主键索引）以查找id 3）加入ID
使用多列索引可以对此进行更优化：
CREATE INDEX idx_nn_1 ON store(city_id,id);
这应该导致：
1）读取索引idx_nn_1 2）使用此索引idx_nn_1
加入在当前示例中，您的示例中的所有city_id=1都有相当多的侧面数据。这种在真实数据中的数据分布可以给你带来问题，因为where city_id=类似于说＆＃34;只需从表存储＆＃34;中选择所有内容。在这种情况下，该列的直方图信息可能导致不同的计划，但是如果您的数据分布不是那么高，那么它应该可以很好地工作。
在你的第二张表store_cat_relation上，您可以尝试这样的索引：
CREATE INDEX idx_nn_2 ON store_cat_relation(store_id,cat_id);
查看DBMS是否决定通向更好的数据访问路径。
对于您看到的每个连接，研究连接并查看多列索引是否可以减少读取次数。
不要索引所有列：索引中的列太多会导致插入和更新速度变慢。
另外一些场景可能要求您以不同的顺序创建索引，从而导致表上的许多索引（一个列（1,2,3），下一个列（1,3,2）等）。这也不是一个真正的快乐场景，其中列的单列或限制以及仅读取列2,3的表可能是首选。
索引需要测试最常见的场景，这可能会非常有趣，因为您将看到运行数秒的慢速查询如何在100秒或更快的速度内突然运行。