乱码代码一堆，看不懂，乱码内容时间、地点、数字没有，无法具体分析。

说白了，这堆代码就是个百度知道页面的前端资源加载清单。
其实很简单，核心就是加载各种JS和CSS文件，然后根据页面路径决定加载哪些组件。

展开讲，关键点有这么几个：先用require.resourceMap定义所有资源及其依赖关系，比如common-new:widget/search-box-new/search-box-new.js依赖了多个其他模块；然后通过require.async按需异步加载这些模块，比如用户栏userbar-renew和搜索框search-box-new；还有个定时器runCounter，当某个页面超时没响应（比如1 5 秒），就会自动跳转。
去年我们跑的那个项目也用了类似逻辑，不过量级小多了，大概3 000量级。

我一开始也以为这代码挺乱的，后来发现不对，其实这是百度知网的模块化加载方案，用pkg和url区分内置模块和外部资源。
等等，还有个事，注意window.BaiduHttps这部分，是强制HTTPS重定向的脚本，说实话挺坑的，很多老项目都没处理好这个兼容。

提醒一下，容易踩的坑是依赖关系没理顺，比如某个模块加载顺序错了，会导致5 02 Bad Gateway，这个点很多人没注意。

mysql中如何查看优化器优化后的执行计划

上周有个客人问我数据库优化的事情，我正好刚研究了点MySQL的索引和HINT。
他问的这个问题，其实和数据库里的两个概念有关，一个是数据的可选择性基数，另一个是HINT的使用。

先来说说数据的可选择性基数，也就是我们常说的cardinality值。
简单来说，它反映了每个字段中不同值的分布情况。
比如一个表有1 00行数据，一个字段里有1 00个不同的值，那这个字段的cardinality就是1 00。
这个值越高，意味着查询优化器可以更精确地估计查询中每一步操作涉及的记录数。
所以，在基数高的字段上建立索引是有意义的，因为这样可以提高查询效率。
但如果字段基数低，建立索引可能反而没有全表扫描快。

再来说说HINT，这东西就像是给数据库优化器的人工提示，告诉它在这个查询中，你可以这样考虑执行计划。
通常优化器自己生成的执行计划已经很不错了，但在某些特殊情况下，比如表频繁更新导致cardinality不准确时，优化器可能就不会给出最优的执行计划。
这时候，我们就可以使用HINT来手动引导优化器。

我举个例子，假设有一个表t1 ，上面有三个字段rank1 、rank2 、rank3 ，每个字段都有一个二级索引。
如果我想查询rank1 =1 或rank2 =2 或rank3 =2 的记录，没有使用HINT的情况下，查询效率可能不高。
但是，如果加上HINT，让优化器知道可以使用索引合并（index_merge），查询效率就能大幅提升。

这个客人听我解释完，好像懂了不少。
他后来跟我说，他之前遇到的一个查询优化问题，可能就是这个HINT没用到的原因。
我告诉他，以后遇到类似的问题，可以试试加上适当的HINT。

反正你看着办，数据库优化是个挺复杂的话题，有时候还得根据实际情况来调整。
我还在想这个问题，也许以后还能找到更多优化数据库的方法。