@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 版本也不是不能用。

@charlie21 这书我看过，看不太懂就放弃了。

RSS 功能做了吗？首页没找到。没做的话催更。

@someonedeng 肢体动作、语言之类的。但是这两个好像带宽都不大。某些章鱼（我不知道是否所有章鱼都能变色）的变色能力好像有潜力实现一种类似显示屏的高带宽输出能力。不过不知道章鱼能不能精确控制每一个“像素”。