@frankies 我觉得编程能锻炼通用的解决问题的能力，但是我没有证据。

@BraveChi 你那个儿子现在多大了？如果还想试的话建议尝试教一些画图方面的库的使用，或者直接就教 logo 之类的语言。我小学的时候接触 logo 感觉挺有趣的，初中的时候在文曲星电子词典上也基本全是在用 GVBASIC 画图和做动画。目前来说自己比较满意的一个程序也是用汇编语言写的一个看起来比较垃圾的 3D 动画。我记得之前在可汗学院上也看到一个教孩子用程序做动画的课程，还有分享自己的作品的地方。不知道现在还有没有了。

感觉大五人格的开放性和认知闭合需求跟思想开放的关系很大。都能测，网上就有很多量表。

@h0099
昨天我在本站使用指南节点看到站长说骂人也属于言论自由。我记性不太好，忘了是哪帖了，搜也没搜出来。不过我怎么记得站长好像因为某人骂人处罚那个人了？可能是我记错了吧。你是怎么记住那么多页面的？感觉某些好像不是搜索就行的，有什么方法吗？还是仅仅是你记性好而已？

你说的那个 bit array 的位数是 tag 的数量吧？我见识少，智商也不高，只能想到这个。为了防止你有什么更高明的方法问一下。存储方面我只能想到数据库压缩存储，计算方面怎么处理我就想不出来了。我之前好像了解过类似的东西，但是听说类似的方法相当耗资源就没详细了解。不过我也没具体了解到底要消耗多少资源，也许应该实际试一下。

> 您为啥要两两配对执行？为了缓存某个 content 的所有 tag ？但现查也只要 10ms 那您为什么要去套个缓存？说不定您的缓存比 10ms 还慢
> 而且为了获知所有 content-tag 关系（而不是需要哪个 content/tag 就去现查）您也只需要去掉 WHERE 子句直接`SELECT * FROM content_tag_rel`，所以哪来的两两配对？

可能是我脑子出问题了。不知道为什么会说错。也可能是我写的时候脑子里想的是另外一种计算所有内容两两之间的相似度的方法吧。其实用我上面的 SQL 执行一次就能获得某个 content 的按某种相似度排序的所有的 content ，所以用不着 content 两两之间计算相似度，对所有 content 执行一遍那个带 IN 的语句就行了。感觉这个错误实在是太神奇了。想不到什么避免的方法。

我之前想说的是每个月都在所有的 content 上都运行一次那个带 IN 的语句。说得还是不明确，我一步一步说吧。

SELECT *
FROM tag_content_rel
WHERE content_id = 1;

把获得的结果填入那条带 IN 的语句的 IN 的部分并执行和保存结果。

SELECT *
FROM tag_content_rel
WHERE content_id = 2;

把获得的结果填入那条带 IN 的语句的 IN 的部分并执行和保存结果。

其实两条语句应该是可以合成一条。我之前可能是怕缓存获得不太具有预测性的执行时间把，毕竟有时候搜索的 tag 可能不是某个 content 相关联的。

> 其实阁下就是陷入了 https://xyproblem.info 之中：

很有启发性，刷新我的认知了。已保存到我的笔记里。不过我好像偶尔还是能意识到这个问题的，因为我问问题的时候偶尔会带上自己的目的。另外我也是对自己的目的有点不想公开。不过这些基本都是借口，以后我会多注意的。

> 与此同时隔壁某主题帖 /t/909154 中一大堆阴阳怪气的杠精和低级红高级黑反串都没人管，却要封我一个纯路人？

常在河边走，哪能不湿鞋。可能是我感觉错了吧，我感觉站长处罚人好像有一定随意性和随机性的，还有有时候 @他他才会管。希望别被站长看到。不过尽量还是别 @他，之前好像见过某人因为经常 @他结果被处罚了。另外 V2EX 的处罚不只是封号，还有降权。谁知道还有什么隐藏处罚。

好像新标签页打开的间隔长一些自动翻译的概率就会大一些。难道是限制翻译请求频率了？

#2 @h0099

>还要看 filtered 是多少

filtered 一直都是 100 。

> ANALYZE TABLE

狂暴轰入大量垃圾数据 > 执行带 in 查询 10 毫秒左右 > 重启 MariaDB > 执行带 in 查询 1 秒多 > 执行 ANALYZE TABLE tag_content_rel; > 执行带 in 查询 10 毫秒左右 > 之后不管重启多少次执行那条带 in 的都是 10 毫秒左右。

太谢谢你了。这下我基本上是安心了。剩下的那点不安心是我的问题，我不习惯因为暂时的有效而确信方法是绝对正确的。另外因为你我也算是对数据库优化稍微有点见识了。

> 一条 sql 耗时 10ms 还需要优化？

如果能优化到更低的水平我就可以加个功能了。比如说每隔一个月所有 content 都两两执行一次那个带 IN 的语句，前提是用户允许。对我想做的网站来说这应该是个很实用的功能，应该能提升用户的体验。当然两个未修改的 content 之间和两个不活跃的用户的 content 之间不执行我是想到了的。其实我的网站不是简单的标签加内容，只是用了标签加内容的形式，“内容”关联的“标签”是可能一直变的。

网站的具体细节我就不说了。由于网站还没开始做，我想尽量保密。你要是感兴趣的话我可以把原型和计划书单独发给你。其实我这个东西我给很多人都看过了，好像很多人都说从商业角度看不靠谱。所以不出意外我只能用业余时间自己做这个网站了。我对我设想的网站实在是太痴迷了，不做出来难受。

> 您写的奇妙深刻业务逻辑

哈哈，是在嘲讽我吗？或者是玩笑？我几乎不在乎被嘲讽，在知乎上问问题问多了习惯被回答者嘲讽了。不过 V2EX 的站长好像对礼貌问题的容忍度挺低的，如果不想被处罚还是小心点吧。我感觉你这个说法很像嘲讽了，应该不只是我过于敏感。

@h0099

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

> 啥问题？

https://blog.csdn.net/kevinxxw/article/details/109567275 。

> 所以阁下要优化这几百 ms 的 sql ？

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

> 然而您有着 14k 积分

我以后可能会在 V 站充钱，然后花积分置顶帖子，积分能省点就省点吧。

> v2 人发帖回答您时收您费了？顶多您回帖需要站内积分

是这样。我是在某本书上看到说先某个人一些好处，然后再向这个人提要求这个人更容易答应。你这么热心的人我之前好像基本没见过。然后再联想到之前我也有过付费咨询的经历，所以就想到找你做付费咨询了。感觉我的思维方式有点跳跃。不过感觉好像也算是稍微又那么一些合理吧，我好像只在付费咨询的时候得到过类似的连续的问答。

> 所以这里是知乎还是 V2EX ？还是说 V2EX 早已被知乎收购？建议立即致电 livid
> `解决个人问题`建议立即前往 stackexchange 站群的各个站点如 stackoverflow ，他们可不会计较什么`这是您自己的复杂问题关我啥事`，因为这种 answer 发出来就会被 tag off-topic 一瞬削除

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

> 与此同时：我还在与表结构 migration 搏斗

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

@h0099
你说的东西我基本上只能看懂一部分。另外我打算暂时不纠结这个东西了，因为了解越多我越感觉这个东西复杂。比如那个 in 据说在某些情况下会出问题。而我现在应该是处理不了这么复杂的东西，因为很多数据库优化方面的概念我都没有系统的了解。有时间还是看数据库优化方面的书吧。

我想优化的其实是那个带 in 的查询语句。今天我又试了一下结果 HeidiSQL 又偶尔出现不到一毫秒的情况了，这次没看错。不过我猜应该是 HeidiSQL 的显示不准确，因为用 show profile 看大概是十毫秒左右。之前的两秒多的情况反而无法复现了。

你愿意提供收费优化 SQL 的服务吗？感觉有点主动上钩的感觉，如果你真是有意的的话。抱歉我带着恶意揣测你了，因为我之前好像看过相关的东西，我记得好像是《影响力》里有相关的东西。能留个联系方式吗？邮箱就行。不想留的话我留。

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

因为我对只能帮助一个人没什么太大的排斥，另外如果只能帮助一个人但是能提升自己的表达或者其他能力我是愿意帮的，我估计你可能也有类似或者其他的原因吧。所以我估计你可能会回复我，所以就问了。还有我感觉好像是你引导我问这种问题的。我问那个是因为我估计网上绝大多数人输出内容应该都是为了更大的利益吧，输出只能帮助到一个人的内容明显不能最大化自己的利益。这个应该算是在知乎学到的吧，知乎禁止过于个人化的问题，想要解决个人问题基本上只能用付费咨询。

#16 @h0099
我试了一下，关系表一千万条查询一百个左右 tag 需要两秒多。一百万是不到 100 毫秒。不过我发现好像一千万的记录如果 tag 小于七个能在不到一毫秒的时间内完成。而从八个到一百个左右时间基本都是两秒左右。还有个奇怪的地方，我某次生成了测试数据之后搜索一百个左右的 tag 好像只用了不到一毫秒。不知道是怎么回事。我弄了好几次也没成功复现，我都有点怀疑是我 explain 忘了删才不到一毫秒的。或者可能是 MySQL 或者 SSD 的缓存的问题？

不知道到千万的级别后是分表更好还是用我这贴说的限制资源的方式更好。之前我考虑过按使用目的进行分表，让用户依据使用的目的选择项目放到哪个表中。

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

表结构之类的东西： https://pastebin.com/Kin9UkXg 。太长了，直接发我嫌浪费积分。之前问朋友朋友说如果达到千万级别就不用我优化了。不过现在互联网这么不景气，感觉悲观一些也不错。你感觉麻烦的的话就不要回复了。

#13 @h0099 我说的那些消耗资源的 SQL 语句基本类似标签搜索，但是每次搜索会搜索哪些对象具有给定的很多个的标签，多的时候可能会有几十个标签吧。另外按标签匹配的个数进行排序。我用的基本上就是这个问题题主采纳的回答里的语句： https://stackoverflow.com/questions/8762333/multiple-tags-search-query 。不知道你觉得这种查询是否能优化。我还没学数据库优化。我之前生成一些随机的数据进行测试好像是搜一百个标签的时候在我的 SSD 电脑上搜索时间达到秒级了。好像还建索引了。另外我的那些随机数据应该是有一些问题的，跟实际的数据很可能有区别，不知道实际数据是会更快还是更慢。

@lululau 一条 SQL 语句可能就会占用大量的硬盘 IO 等资源，然后在执行这条语句的时候可能正常的处理网页显示的代码读取数据库就会变慢了。类似消息处理的东西我是打算做的，我之前还计划把这些耗时的操作全都延迟到下半夜没人访问的时候执行。然后怕流失用户所以想分三档，不太消耗资源的这类 SQL 语句立即同步执行，中等的异步限制资源执行，太消耗资源的就只能下半夜不限制资源执行了。

@Features slave 是在另外一台服务器上是吧？

@redorblacck886
我估计是没法优化。

@iseki
能限制 IO 吗？另外限制内存不会跟限制时间一样都是到限制之后都停止执行吧？我的意思是类似让它优先级低一点，但是能执行完。

@aijam
我的意思是类似让它优先级低一点，但是能执行完。

@Pipecraft 20 元打赏有兴趣要吗？感觉太少了，但是多了我肉疼。没在你的网站上找到打赏的地方。

@Pipecraft #42 我用的是 Inoreader 。好像也是新更新的在上面。我好像有点过于迂腐了，仔细想想 rss 里面按回复数排序和按进入顺序排序好好像基本上是等价的。可能是之前肉眼看的 rss 订阅源次数比较多吧，所以对你的这种比较奇怪。我订阅的是 50 个的，八小时左右好像才更新三条。对我来说太少了。不知道是不是没到高峰期。我想要 100 个的，如果不麻烦的话希望能添加一下。另外建议提一下不同数量的订阅源效果是不一样的。我第一眼看到的时候好像没反应过来，我刚看到的时候好像以为就是类似一页显示多少条一样，效果是一样的，记不清了。不过像我脑子这么笨的可能不多，没准加上可能会让某些人产生侮辱他智商的感觉。

@Pipecraft 受累了。感觉有几个好像不对劲的地方，不知道是不是我理解错了。比如 30 天最热榜单的 RSS 订阅源我觉得应该是新进入这个 30 天最热榜单的帖子出现在最上面吧？而不是像现在这样按回复数降序排列。当然前者好像实现起来麻烦很多。还有 30 天最热网页版是 100 个，RSS 版好像最多 50 个？这样的话 RSS 版就看不到那些不那么火的了？你要是嫌麻烦就不用改了，现在的 RSS 版本也不是不能用。