142.
@老虎会游泳，我不清楚MySQL选择索引的策略
会不会是看数据量最少的几个索引中，哪个被缓存得更多，就挑哪个？
甚至会不会是，哪个索引要额外读取得更少，就挑哪个？
另外，值域的多寡（如[0,1]、[0,2]，导致更少/多的重复项），有什么优化作用吗？
如果大家都是INT，就都占 4字节 的空间，索引总体大小不都一样吗
（SQLite 里倒是有个跳跃扫描，可以用得上重复项多的索引，但和`SELECT COUNT()`无关？）*
这个Markdown解析器不是很完善啊，斜体内不能再出现*，即使是被代码框包起来
143.
@无名啊，markdown的规范是用斜杠转义
*1\*2*
1*2
144.
@老虎会游泳，噢，我用Typora写的，估计它自己优化了吧
它还用$公式$代表公式，我还要自己转换成《公式：xxx》
145.
@无名啊，如果索引有100个键，那就需要遍历这100个键，并对其值的数量进行求和。
如果索引只有两个键，就是遍历两个键，对其值的数量进行求和。
你认为哪个更快？
146.
@无名啊，如果你不转义*1*1*1*，谁知道你是想要
111
还是想要
1*1*1
147.
@老虎会游泳，但我有个代码框包着*呀，不应该被当作斜体结束符
148.
@无名啊，虎绿林用户发布未加[code]的PHP代码的几率很高，所以我们很难支持$公式$而不带来副作用。
150.
@无名啊，
但我有个代码框包着*呀，不应该被当作斜体结束符
那确实是解析器缺陷，对此我表示遗憾并且没有办法修复。
151.
@老虎会游泳，我勉强理解不支持$公式$，我也了解php/shell这类大量使用$的代码可能容易误匹配（除非尝试看能不能解析成正常公式）
但考虑考虑误认作斜体结束的*呗~就好比
$arr = [']'];
153.
@无名啊，如果升级Parsedown到新版本不能解决该问题，则该问题无法由我修复。
154.
@无名啊，从这个demo来看，升级无法解决该问题。
155.
@老虎会游泳，罢了罢了，碰上几率也不多，就算遇到，也不咋看得见，无伤大雅~
156.
@老虎会游泳，
如果索引只有两个键，就是遍历两个键，对其值的数量进行求和。
你是说，一百行的表，对其中一个值域大小为2的字段建索引，该索引只有两条记录？每条记录指向50个主键ID？（假设均匀分布）
157.
@无名啊，对呀，难道不是吗，B+树的一个节点不是能存很多指针吗？除非一个节点存不下，才会需要存储在相邻节点吧。
159.
@无名啊，我修复了斜体问题，现在mdpre（`xxx`）的渲染由虎绿林UBB引擎接管了。
斜体``斜体*
由于出现严重副作用，修改已被撤回。
161.
@老虎会游泳，
对呀，难道不是吗，B+树的一个节点不是能存很多指针吗？除非一个节点存不下，才会需要存储在相邻节点吧。
不知道，没找到索引表B+树结构长啥样
我记得SQLite的非聚簇索引是用B树存的，每一行记录都会有一行索引，后面直接跟着主键ID
不知道MySQL咋样。估计要直接测试后看统计/索引文件大小/索引文件内容，才知道结论了
想想确实也是，相同索引键的主键ID可以都丢到一块儿去，好像没啥副作用？