> 在我的电脑上那条带 IN 的语句的执行时间很不稳定，有时候 10 毫秒左右，有时候一两秒，有时候一二十秒。这么不稳定的执行时间我接受不了了。之前说不纠结这个一部分就是因为很多次都是 10 毫秒左右，现在这么不稳定不能不纠结了。我新问了一个问题： https://www.v2ex.com/t/909074 。忙的话就不用看了。

您后台是不是跑着一堆频繁内存 /硬盘 io 的程序？您应该先把他们都关掉以控制变量，或是直接去开个空白服务器专门测试这些
您 innodbbufferpoolsize 多少？是不是还用着默认的 128M ？

> https://blog.csdn.net/kevinxxw/article/details/109567275
> in 通常是走索引的，当 in 后面的数据在数据表中超过 30%（上面的例子的匹配数据大约 6000/16000 = 37.5%）的匹配时，会走全表扫描，即不走索引，因此 in 走不走索引和后面的数据有关系。

这不就是 cost-based optimizer 认为直接 full table scan 的 IO 时间开销比去使用索引然后反复在 primary/secondary index 和具体的 datanode 之间绕圈子更快？这跟 where in 有关系吗？
您自己建个只有 10 行的表，哪怕您给`WHERE field=1`的 field 加了索引 EXPLAIN 也会显示根本不使用您加的索引因为 scan10 行远比去索引里绕要快
so 人早已道明真相： https://stackoverflow.com/questions/586381/mysql-not-using-indexes-with-where-in-clause

另外阁下看着这些简中互联网的 csdn 垃圾还不如去啃 en 文档或 en 书籍：
https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html
https://use-the-index-luke.com/sql/where-clause/searching-for-ranges/greater-less-between-tuning-sql-access-filter-predicates


> 估计属于可得性偏差了。大意是认为容易想到的东西出现的概率更大。我平时经常用知乎，stackoverflow 好像是没用过，虽然经常能搜到上面的问题。因为经常用知乎，所以以为知乎的那套规矩是比较常见的。其实我之前也想过那可能只是为了赚钱和增长之类的原因才那么定的，不过应该是可得性偏差的力量太强大了。

逼乎那群功利主义者带 v KOL 您指望什么？整天吹嘘着知识付费然后反手把几年前发的回答给删了放进盐选订阅里
等您花了几块钱巨款打开一看全都是车轱辘话和十几年前 web2.0 时代的互联网上唾手可得的信息的复制粘贴嗯缝合，或是像 csdn 人那样去机翻 en 互联网上的公开免费信息回来兜售二手屎
stackexchange 人至少不搞什么乱七八糟的 monetize ，您把您的 sql pastebin 发到 dba.stackexchange 上同样会有人指出您的`WHERE tag_id`无法直接使用索引而只能`using index for skip scan`，所以应该按照最左字段原则改变 composite key 中的字段顺序

> 你的意思是你很忙吗？是的话那抱歉消耗你时间了。

我只是说我们都在与 mysql 搏斗

REPAIR TABLE 是用于以前使用 myisam 引擎的表的，您的 sStatus 的 table engine 是 innodb 还是 myisam ？（还有人用 myisam ？）

与此同时：我还在与表结构 migration 搏斗
https://i.imgur.com/dWpNcH2.png

> answer 发出来就会被 tag off-topic 一瞬削除

回顾经典之 https://stackoverflow.com/questions/18113418/ignore-duplicate-key-insert-with-entity-framework/75113236#comment132551981_75113236

`解决个人问题`建议立即前往 stackexchange 站群的各个站点如 stackoverflow ，他们可不会计较什么`这是您自己的复杂问题关我啥事`，因为这种 answer 发出来就会被 tag off-topic 一瞬削除

> 比如那个 in 据说在某些情况下会出问题

啥问题？

> 我想优化的其实是那个带 in 的查询语句

#19 显示`WHERE content_id = 50000`比那一坨`WHERE tag_id IN`要慢，因为 content_id 只能`skip scan with index`
而且 tag_id 应该是走 PK 上的索引了的因为您的 PK 是(tag_id, content_id)符合最左字段
所以阁下要优化这几百 ms 的 sql ？

> 今天我又试了一下结果 HeidiSQL 又偶尔出现不到一毫秒的情况了，这次没看错。不过我猜应该是 HeidiSQL 的显示不准确

建议 phpmyadmin/datagrip

> 你愿意提供收费优化 SQL 的服务吗？感觉有点主动上钩的感觉，如果你真是有意的的话。抱歉我带着恶意揣测你了
v2 人发帖回答您时收您费了？顶多您回帖需要站内积分

> 表结构之类的东西： https://pastebin.com/Kin9UkXg 。太长了，直接发我嫌浪费积分

然而您有着 14k 积分

> 知乎禁止过于个人化的问题，想要解决个人问题基本上只能用付费咨询。

什么知乎盐选
所以这里是知乎还是 V2EX ？还是说 V2EX 早已被知乎收购？建议立即致电 livid

https://vuejs.org/guide/components/provide-inject.html
https://vuejs.org/api/composition-api-dependency-injection.html
但不如#4 的简单粗暴

#3 @zhy0216 可以吧
https://pythonsimplified.com/everything-you-need-to-know-about-python-lambda-functions/
> Another way you can invoke the Lambda function is through Immediately Invoked Function Expression (IIFE). However, this is not a recommended use of calling lambda expression. You don’t see this method being used anywhere. I have mentioned this for informational purposes only.
> >>> print((lambda x: x**2)(5))
> 25

https://elfi-y.medium.com/python-lambda-%CE%BB-6c62a5427913
> We can invoke them directly in Immediately Invoked Function Expressions (IIFE) like:
> (function (a, b) {return a + b })(1, 2); // 3
> ((a,b) => (a+b))(1, 2); // 3

而 uniq 表比原表小的多，这就是因为不再需要那个 `隐式的自增 id 字段作为主键`
https://i.imgur.com/rynDF0i.png
https://i.imgur.com/YEuKO58.png

回到`SELECT * FROM tag_content_rel WHERE content_id = 50000`本身，他的 EXPLAIN 是
https://i.imgur.com/xVVVitb.png

Using index for skip scan 意味着查询计划是将 key （这里是 PK ）用于帮助加快 full table scan 的速度，因为根据 key 中的信息可以知道有些行可以直接跳过（所以叫 skip scan ），但这并不能改变查询计划仍然是在做 full table scan 的罪恶本质： https://dev.mysql.com/doc/refman/8.0/en/range-optimization.html
而只能 full table scan 的根本原因是这个 sql 的 where 子句只有对字段 content_id 的约束，而 content_id 不在任何索引的最左字段（第一个）之中，因为您的 PK 是(tag_id, content_id)而不是(content_id, tag_id)

所以在
ALTER TABLE `tag_content_rel_uniq` ADD INDEX(`content_id`)
之后
https://i.imgur.com/fETf9OI.png
立省 50%
EXPLAIN 显示这下的确是直接使用了新建的 content_id 索引，所以不再需要任何形式的 full table scan 了：
https://i.imgur.com/vyauhY0.png

但代价是这个新索引吃了 148mb 空间（加了之后我还没 OPTIMIZE TABLE ），但整个表大小 460 也小于您最初设计的表 604
https://i.imgur.com/sLzqfgp.png
如果您需要节省空间（既是指硬盘上的空间也是指 innodb buffer pool 中能塞下多少个这样大的表的 index ）
那么需要根据您实际业务的查询，您是主要查询 WHERE content_id 还是 WHERE tag_id （都只约束一个字段，如果两个字段都约束那肯定会用上 composite key ，因为您的 CK 只有这两个字段），就把哪个字段移动到现有 CK （在这里是 PK ）的最左（第一个）

```sql
ALTER TABLE `tag_test`.`tag_content_rel` DROP INDEX `tag_content_rel_index`, ADD PRIMARY KEY (`tag_id`, `content_id`) USING BTREE
```
#1062 - Duplicate entry '87582-57377' for key 'tag_content_rel.PRIMARY'

真就 `需求就是允许一个 content 有着多个完全重复的 tag` 呗（当然我知道有重复的`tag_id,content_id`对是因为您的存储结构是直接生成随机数值来 INSERT 的而又没有去重）

```sql
CREATE TABLE IF NOT EXISTS tag_content_rel_uniq
(
tag_id INT NOT NULL,
content_id INT NOT NULL,
PRIMARY KEY (tag_id, content_id)
);
INSERT IGNORE INTO tag_content_rel_uniq(tag_id, content_id) SELECT * FROM tag_content_rel;
OPTIMIZE TABLE tag_content_rel_uniq;
SELECT COUNT(*) FROM tag_content_rel_uniq;
SELECT * FROM tag_content_rel_uniq WHERE content_id = 50000;
```
耗时还是差不多

```sql
CREATE TABLE tag_content_rel(
tag_id INT NOT NULL,
content_id INT NOT NULL);

CREATE INDEX tag_content_rel_index ON tag_content_rel(tag_id, content_id);
```

您为什么不用自带 unique 约束的 primary key ？还是说您的需求就是允许一个 content 有着多个完全重复的 tag ？
您设置为普通 index 就意味着他是 secondary index ，而这个表无 PK 也无 UK 就意味着 innodb 只能自动生成一个隐式的自增 id 字段作为主键，这被关系代数学家称作 https://en.wikipedia.org/wiki/Surrogate_key： https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html
> If a table has no PRIMARY KEY or suitable UNIQUE index, InnoDB generates a hidden clustered index named GEN_CLUST_INDEX on a synthetic column that contains row ID values. The rows are ordered by the row ID that InnoDB assigns. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in order of insertion.

> 可能是 MySQL 或者 SSD 的缓存的问题
考虑到您都不知道`innodb_buffer_pool_size` https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html：
建议深入学习贯彻 RDBMS 供应商无关的关系代数理论知识： https://use-the-index-luke.com 然后再结合 innodb 本身的实现进行思考

https://i.imgur.com/kNIQHtg.png
OPTIMIZE 个 TABLE 先
https://i.imgur.com/Q6E5tBI.png

https://i.imgur.com/r2g8FPc.png
所以阁下想优化`SELECT * FROM tag_content_rel WHERE content_id = 50000`？还是什么？

```
tbm> CALL add_tag(1000)
[2023-01-13 19:51:43] 100 rows affected in 842 ms
tbm> CALL add_content(1000)
[2023-01-13 19:51:44] 100 rows affected in 875 ms
tbm> CALL add_tag_content_rel(100000, 100000, 100000)
[2023-01-13 19:54:15] 100 rows affected in 2 m 30 s 141 ms
tbm> USE tag_test
[2023-01-13 19:54:17] completed in 356 ms
tag_test> SELECT *
FROM tag_content_rel
WHERE content_id = 50000
[2023-01-13 19:54:25] 85 rows retrieved starting from 1 in 6 s 972 ms (execution: 6 s 700 ms, fetching: 272 ms)
tag_test> USE tag_test
[2023-01-13 19:54:26] completed in 572 ms
tag_test> SELECT content_id, COUNT(*)
FROM tag_content_rel
WHERE tag_id IN (730,2621,2805,3200,3340,3590,3969,4039,4799,5249,8859,11894,12628,12646,16959,17024,17142,18032,18861,19316,20839,21179,22346,22507,22522,22639,23562,23822,25172,25786,25821,26606,29899,29917,30586,30901,31216,31413,32562,32567,34740,36586,36954,38109,39202,40519,40756,40816,41464,42942,43069,43286,43344,44787,44950,45549,45652,46313,47111,50549,51942,52738,52959,52961,54034,55526,59162,59767,59945,60361,60816,61307,61730,62269,62503,62589,63960,64580,64634,64794,65209,66332,68222,69396,69905,70629,70939,71277,71804,72580,72896,73651,74301,74525,74706,75153,76169,76500,78042,78148,79109,81463,82140,84217,85212,85327,85584,86392,86908,88188,88475,89175,89190,91156,93202,94124,95294,95345,96013,98135,99679)
GROUP BY content_id
ORDER BY COUNT(*) DESC
[2023-01-13 19:54:28] 500 rows retrieved starting from 1 in 555 ms (execution: 402 ms, fetching: 153 ms)
```

> 让你回复了这么多很不好意思。你回这么多图的是什么？这些明显属于个人咨询了，你回的这些东西好像很难帮到除了我以外的人吧？

那阁下来 v2 问您的特定于您的表结构场景的问题又什么什么目的？

> 之前问朋友朋友说如果达到千万级别就不用我优化了

经典提前优化与钞能力

恭喜阁下已经入门了 FP （函数式编程）思维

可能原因： https://github.com/phpmyadmin/phpmyadmin/issues/17527

我之前也被 pma 白屏折磨过