我的天

昨天说到一个很简单的SQL语句引用的数据库就只有一个字段两行记录，居然需要24秒才能得出结果。这让我觉得非常不可思议。首先可以肯定的是数据量非常少，为什么会出现这种问题呢？那只能是连接方面是不是出了什么故障，也不能说，那是失效的，因为的确还能查询得到想要查询的东西。在我测试的那个宏里面。我引用了两个文件，一个是外部文件，一个是内部文件。外部文件是含有比较多的数据，而内部文件，也就是我一开始说的那个只有两条数据。我感觉如果我的SQL再厉害一些，我对VBA再熟悉一些的话，那个内部文件可能我就不需要引用了，我直接就在VBA里创建一个数据库，然后把两条数据给写进去，用完以后就删掉，但显然现在我还没有很大的把握，一定能完美地做这件事情。把我某个文件里面的数据转化为数据库的数据我又烂熟，所以我采取了现在使用的这种方式。

ADO+SQL的这种方式，因为我们是跨表引用，所以意味着数据肯定来源于多个文件。他们有可能是同一个工作簿的不同工作表，也有可能是在不同的工作簿里。对我来说，只要是在一个工作簿里，那么起码一开始设定指向的时候就得有一个数据源。最经典的方式引用的那个数据源在使用数据的时候，在from后面不需要进行进一步的引用，其它的就得麻烦一些。我的第一个反应是，是不是引用数据的那个语句出现了变动呢？比如说现在我用的是Excel12。在数据源引用方面，我又折腾了一番，发现好像还是那样，没什么进展。会拖慢查询的那个数据源，我甚至把它放到了主数据源里，结果发现还是很慢，于是这就排除了是数据源引用语句变动导致缓慢。

所以这到底是什么原因造成的呢？因为我有很多个跨表引用的查询。有些查询是内部数据外部数据都有，有些只有外部数据，经过测试后我发现好像只有引用了内部数据的查询才会变慢。

为了证明我这个想法，星期三的晚上我编造了一些数据做测试。主要原理就是研究是不是数据源的关系导致这种变慢。一开始我的设计就是一个排列组合的方式，因为我默认的数据引用是要跨表的，所以我把数据源根据内内、内外、外外和外内这4种方式测试，实际上内内和外外是一回事，也就不需要进行两个引用了，所以我又把那两个东西拿了出来，同样进行测试。结果让人有点吃惊，凡是有内部数据参与的查询都会变慢。我测试的数据就只有一个字段几条记录，内内和内外需要12秒，外外需要0.1秒，外内需要24秒。这就能解释为什么我的那些变慢的查询起码都要24秒才能出结果。因为我永远把内部数据放在后面。究其原因是因为我设计那些查询的时候，我后来才想到要在那个查询文件里面搭一个加脚手架，把一些基础的东西加上去，在这种情况下我加得最多的是日期表。

关于这个测试的来龙去脉以及最终的结果，我在ExcelHome里面做了一个详细的帖子，在这里就不再具体阐述了。

折腾了这么一番以后，我发现这个锅还真不是我整出来的。造锅的是微软，不知道更新出了什么状况导致了。

Excel用多了，不知不觉我也居然能挑出微软的毛病。

没试过掉链子，没试过挂链子，也没试过给单车的链条上油。上周四在回家的路上我就已经买了单车的链条油。问单位机电科的人拿一些机油就能解决问题，但对我这个不想开口的人来说，我宁愿花几块钱。这个油也不仅仅是用在单车上，估计其它需要润滑的装置也能用得上，比如宿舍大门那个经常一到潮湿天气就会卡死大门锁。我并不知道链条油跟其它的润滑油有什么区别。

之前单位宿舍的台扇要手动一下才能转起来，又或者是到某个情况下，手动也转不起来了。那个时候我就会加点缝纫机油。油虽然上去了，但是感觉效果不能持续太久。据说缝纫机油就是这样，如果买一些专业性强一点的油可能不会。缝纫机油过上一段时间我又得加一些进去，否则那个风扇又会卡死了。正是因为风扇那个样子，所以后来我就又买了现在的那个台扇，体积更小，风量更大，噪音更小。现在宿舍的台扇，是我把一个类似循环扇的东西当台扇用。除了清洗不太容易以外，其它都还好。以前的那个台扇，最好的地方就在于拆卸比较方便，因为那个框是铁架的，所以清洗很简单，扇叶也能轻松拆下来，全部东西清洗几分钟就完了。但现在的那个风扇，要把前盖拆下来，得费一点劲，后盖直接是拆不下来的，扇叶也拆不下来，所以就只能用抹布擦，不能直接拿到水龙头下冲洗。不是所有循环扇都不能完全拆洗，但因为我比较抠门，所以我的那个款式估计就这样了。

自行车链条油买的时候广告说那个东西有润滑和防锈的作用。我把油涂上去的时候，链条其实表面已经是生锈的状态。我是星期一下午下班吃过晚饭后对单车进行链条装紧以及上油的。星期三下午，我要进行小破车的第二次测试。第二次测试也是以失败告终，这是更离谱，只骑了不到600米，在深粮物流门口链条就被颠掉了，但是这一次，当我想把链条挂回去，显然就要比第一次费劲很多。跟第一次最明显的区别在于当我把链条挂回去以后，我还能继续踩，我还能把车骑回去单位。星期一对链条进行张紧之后，我曾经把链条的状态图发给网友。如果看上去还没张紧到位，他肯定会让我重来，但显然看上去的确差不多OK了，但实际上还是会被颠掉。第二次测试开始之前，我拿了呆头扳手，测试了一下后轮两个固定螺母是否松，同时也检查了一下后轮的张紧螺母。为了防止那个张紧螺母及铁片掉出来，我还找了根固定线材的小铁线，在那里做了一个封堵设置。在深粮物流门口颠掉链的时候，我也拿出了呆头反手测试了一下后轮两个螺母，发现它们依然很紧固。所以这次链条被颠掉，不是因为颠着颠着后轮移位了。平路和山坡的时候都没有问题，但是深粮物流门口的那些颠簸实在太离谱了，深粮物流门口的颠簸只是新港南路第一关，后面还有很多关。从路程上算，我只走完了不到1/3。这一次我把链条想挂回去的时候，真的搞得自己一手都是油。我完全没想过原来那些链条的油是可以这么的润滑的，一直稳稳地附着在链条上。我摸的时候，那个东西已经把很多铁锈溶解了出来，所以手摸的那些东西的颜色就像巧克力一样。车架是白色的，但是因为被我的手碰过，它们就像是在泥地里淌过一样。

接下来我该怎么办呢？长一点的呆头扳手我已经买了。不锈钢的M10法兰螺母我也买了，但实际上我不确定我的这个小破车后轮的两个轴是M9.5还是M10。因为这两个尺寸都是有可能的，但是在单纯卖法兰螺母而不是自行车固定螺母的地方只有M9和M10两种尺寸。

下周一我不能进行第二轮的链条张紧了，因为那是一个月末日，我得进行我常规的月末焦虑。

花了好多天叙述我要进行的那个小破车测试。我的计划是从单位骑到漳澎文化广场再骑回来。在百度地图上测量，这条路径大概10公里。具体的长度跟我走什么路有关，但不可避免的是，我必须完成来回两轮颠过那条2公里长的新港南路。如果小破车能完成这个测试，实现这个10公里，那么我觉得，它应该能支撑我从单位到家的40公里。在这过程中，如果是有什么不对，也就只有是我不行了。我不行能怎么办呢？熬到一个地铁口，把车停在附近，然后第2天再去把车继续骑回家。在我的计划中，我就没有考虑过车半路就突然不行，刹车是好的，能骑得动，还有什么是不行的呢？在我的计划中，根本就没有掉链子这种事，但实际上掉链子这种事让我的10公里测试戛然而止。

以前也骑过新港南路好多回，好像以前我从来没有感觉过双手被颠得如此麻木。越是颠簸你越得把车把握紧，把住方向，但是你握的越紧，感觉那个震动就越离谱，虽然每次狂疯震颤也就大概不到半分钟而已，的确新港南路的路况很差，但不至于一整条都那样，比如从我们单位一出来到角美粮库门口那个红绿灯这一段是比较顺畅的。但是过了角美粮库的门口，尤其是接近深粮物流门口的那一段，就非常糟糕，尤其是深粮门口那一段。我不知道为什么会这么离谱。深粮物流门口跟宏远汽车的门口是两对面，无论是东往西方向，还是西往东方向，路况都非常差，为什么那一段路就那么的糟糕呢？那段路给我的感觉是沥青路被那些挖掘机耙过。过了深粮门口，上桥的那一段稍微好一点，桥上下来，又开始糟糕。新港码头那里糟糕一段，接近国丰以及国丰门口也很糟糕。简单来说，这条新港南路有80%以上的路况都很糟糕。能明显看到的大坑，我已经躲开了，但是躲不开的是路面铺开全部都暴露在外的小石子。明明这是一条沥青的大马路，为什么那种感觉是我在小石子路上骑行呢？可能沥青路最上面的那层沥青已经被磨没了。

过了新港南路，马上就接新沙路。新沙路我不需要在马路上骑行，因为两侧的人行道以及单车径刚刚修好，而且修得非常漂亮。先修的是人行道以及慢跑径，后修的是水泥的单车径。我是看着那条水泥单车径修起来的，那个单车进比马路面高出一截。接口的地方还竖了几个桩，意味着小车停不上去。即便已经计划好不让小车停上去，但是那条路虽然只是人行道，但依然打了钢筋网。

我觉得我的快乐日子马上要开始了，刚刚经历完地狱之路，马上要进入天堂之道。一开始的确很爽，但是到那个位置的时候，天已经开始渐黑，所以我感觉一些虫子之类的不断向我的眼睛和脸扑过来，所以那个时候我想，如果我真要这么干，必须得戴个口罩。麻涌是一个水乡，到处都有各种小河道，所以从新港南路转入新沙路之后，不久就有一个桥。悲剧就在这里发生了，刚过了那个桥不久，我就觉得脚踏没有了阻力。脚踏完全是一个踩空的状态，这意味着什么呢？掉链了！掉链该怎么办呢？该怎么把那个链子重新挂回去？显然这个我完全不知道，我只能凭感觉。我掉链的地方是后轮，但出乎意料的是我几乎没费什么劲就把链子给挂回去了，但挂回去的时候，我已经已经在想，挂回去会不会两下之后又掉呢？果然不出所料。没蹬两下，又咔嚓掉链了，连续试了好几回都这个样子。骑到那个位置的时候才过去了8分多钟，我才刚刚骑了2公里多一点。那个时候，我想把车直接丢在那里，人走回去算了。因为我实在不知道是链子还是其它的问题，只是掉链是个很普通的事情，应该有救，但如果是其它呢？

最后我选择的是推着车回去，因为一路上我都没有看到垃圾站什么的，我不好意思把破车丢在那里不管。

这个星期不知道什么就过完了，我感觉好像自己没做些什么东西，虽然实际上做的东西还是不少，其中一个很重要的东西就是搞我妈的电脑，要搞显示器也要搞主机。相对来说显示器耗费的时间短一点。当然这个短一点只是最后下单购买的时候几乎没什么犹豫，因为问过同事。之前我实在不知道该怎么怎么选，因为理论上我觉得闭上眼睛买那些就好了实际上从评价看来到处都是坑。那些坑多到你简直不敢踩下去，但是因为同事新配了电脑，也买了显示器，所以最后我跟买就行，最后要做的只是到点在京东那里抢一个券，大众入手的基础上再减个20块钱。相对来说主机耗费的时间比较多。首先是挑选什么样的主机，然后主机到了以后还在不断地折腾。

当我拿着主机回家的时候，我妈问那个是什么东西，我说那是主机。当时我并没有跟她解释到底是什么主机，因为去年的早些时候我就买了一个，她以为我把那个主机带回家了。直到我开始安装显示器的时候，我才告诉她那是她的主机。跟她说的时候实际上我是有点忐忑的，因为不知道她会给我什么反应，她会不会跟我说不是有一个吗，为什么又买一个。上一周换了个固态硬盘，装了个系统，加了内存以后，那台机的开机速度的确很快，但问题是CPU真的有点老了。在安装新的显示器跟电脑之前，我又试了一下上周的那个老机器。打开Edge的时候告诉我之前发生过错误，但Edge是可以打开的。前提是我打开的那个不是爱奇艺的快捷方式，是浏览器本身。在打开浏览器的同时，我继续在监测系统的性能，结果发现在浏览器完全打开之前CPU飙到了100%，而且持续时间不短。有些时候你可以秒打开浏览器，但有些时候双击浏览器之后要等好几秒，浏览器才打开，估计就是因为这个要等个好几秒，我妈觉得没按准，结果继续按，越按越多。本来开一次就占用全部CPU，于是就出现了错误的提示弹窗，不断按不断地弹窗，于是就死循环了。

我觉得机器蓝屏花瓶再或者是Edge卡死跟内存有关，结果我用内存检测的软件跑了10分钟，内存一个错误都没有，所以说内存是好的，我甚至不需要再次打开主板清理内存槽的灰尘以及内存条金手指上面的氧化，因为那完全是多余的，事实证明内存一点问题都没有。
Edge可以正常打开，内存毫无错误，所以这台电脑感觉一点问题都没有。问题只是如果那台电脑开了几个小时，播了几个小时的视频，而且浏览器还同时打开了好几个窗口会不会出现卡顿、会不会出现某段时间CPU耗尽卡在那里，然后就开始各种各样不对劲的东西比较难说。
CPU使用率100%电脑会是一个什么状态？这个我是深有体会的。正常情况下电脑再进行其它操作会很卡。比如说我在压片的时候同时进行其它操作，比如打开个网页，即便是打开个文档也好都会卡顿。其它东西会卡顿，压出来的那个片子也有可能出现毛病，比如莫名其妙出现某些马赛克之类的又或者是某个画面卡住个一两秒。虽然会出现毛病，但起码压片的时候CPU100%卡顿，不会让机器真的死掉，只是卡而已，不会出现蓝屏，不会出现花屏，也不会出现不断弹窗。这是一部正常普通的电脑的状况，但是对现在的软件来说，一个老爷机的CPU上会不会也这样呢？我不知道。

所以最终我还是为我妈装上了新机，但是旧机并没有直接收起来，而是直接堆在桌子的某个角落，或许某一天会用上，毕竟从现在的诊断结果看来，那台机没有问题。

昨天我终于用python写出了把点点转化为WordPress的脚本。这个东西我确信是可行的，因为python的转换过程中没有出错，这就证明没有遇到奇怪的事情。用别人脚本的时候，把转换好的文件上传到WordPress，我总会担心不成功，但我自己写的脚本，我知道该注意些什么，哪些参数是现在的WordPress必须要求有的，所以只要python的转换不出错，我的WordPress导入就不会有问题。因为点点的文章有9000多篇，要从后台管理界面导入到WordPress，会非常耗时间。如果一篇文章需要两秒，完全导入就需要5个多小时，所以我没有做这种事。我挑选出22篇，各个类型都有的，试验导入，结果非常成功，网页的效果也很好，完全按照我的意思生成了。我觉得如果要快速解决问题，估计我得在数据库端导入。之前把文章导入到WordPress，因为要尝试不同的版本，我得不断地导入删除，但删除的文章太多的时候，速度很慢。后来我暴力地在数据库那里直接写删除语句，结果秒杀就完成了。现在我发现了一个更干净的方法。直接把关联WordPress的数据库里的内容全部删掉，这也是一个秒杀的过程，而且绝对不会留下任何的手尾，比如文章删除了，但是分类和标签仍然在那里。可能某些东西已经不存在了，但是计数还停留在一个很大数值，之所以这样，肯定是因为我删除文章的时候不够艺术。与其让里面留那么多乱七八糟的东西，还不如直接把数据库清空。因为我这是单机上的WordPress，我纯粹只是用来测试。这样的删除是最快捷的。大概我从上周，才突然领悟出可以这样。别人之所以要在数据库里写语句删除文章或者标签，是因为不能删掉一些不应该删掉的东西，但我没有这个顾虑。既然在数据库层面可以快速的删除，那么理论上也应该可以从数据库层面快速的导入。之所以有这个想法，是因为我发现WordPress的插件有些是针对数据库的，有些是针对WordPress自带函数的，数据库层面的查询要自带函数快非常多。现在我已经学会了转换适配后台界面导入的文件格式转换。下一步大概我得学习一下如何在数据库层面进行导入。这么高端的做法，貌似之前我还没有听说过。在网站迁移的时候，的确是把数据库打包，然后重新放到别的地方的，但那个数据库是本来就已经存在的。从一个地方挪到另外一个地方，原封不动地，但是我却要把大量的数据以快速的方式导入到数据库，并且还得按照WordPress的脾性建立各种关联，显然这貌是非常不简单，但理论上应该可以做到。

我不知道我的python到底学成怎样了，但起码我可以用那个东西实现我自己的愿望。相比于书本的习题，我觉得实现自己的愿望更有成就感，虽然其中有很多问题完全只能靠自己，没有参考答案。虽然总的来说，脚本不是我一个人写的，我是站在巨人的肩膀上修改而成，但BlogBus和点点的结构还是有差异的。最幸运的是某些我不知道该用什么手段实现的东西前人已经给我指明了方向。昨天我只是把脚本写出来了，接下来我要把脚本优化，一些老是翻来覆去说的句子完全可以把那作为自定义函数。到底什么东西应该泛化，应该泛化到什么程度，这个我还没有想好。昨天之所以可以这么迅速地完成任务，大概是因为在我开始之前先做了个思维导图，明确了我到底要做些什么。基础数据有哪些，应该在哪里取数，需要判断的参数有哪些，各自的参数有什么特性，能不能合并同类项。之前我就写过类似的东西，但是跟思维导图比起来，之前我写的那个真的很水。有思维导图、有专业的思维导图软件，人的思路可以非常快地展开。整体定下来，下面的事情就只剩下一步一步地实现。我做梦也没想到，自己这次居然这么高效。某些我没有把握能快速解决好的问题，昨天不知道为什么很多都迎刃而解了。转换一个30多MB的XML文件，我用了16秒。转换出来的文件大小为22MB。我觉得应该可以更快，但怎么才能更快呢？文件里的数据结构是我没有考虑过的，我是不是应该从那里入手？一些相同的判断，大概我应该做一些合并。

追求更好是没有尽头的。