勘误


最近伯乐在线旗下的几个公众号(CPP开发者,数据库开发等)转载了我的几篇文章,带来了很大的阅读量,也引发了激烈的讨论。评论中,有几位经验丰富的老司机,指出了我文章中的错误;当然,也有一些人在没有营养地纯喷啦,这个我也已经习惯了……

C++11新特性之容器相关特性的评论中,@少跟网线设置路由写到:

“每当在程序中出现一段以{}包围的字面量时,就会自动构造一个initializer_list对象。” 这段话是错误的,这个要看情况,假如将{}包含的字段当做实参传递给一个接受 std::initializer_list 作为参数的函数,那这句话是正确的,在使用std ::initializer_list {}调用构造函数也要看列表中的数据是否跟某个构造函数的参数一一对应,此时也只是相当于使用“()”方式调用构造函数,生成对象,至于传统的数组也还可以使用{}来初始化,此时更不可能生成std::initializer_list 对象。

生成std::initializer_list对象的过程中构建了一个临时数组,并将{}列表中的元素拷贝到数组中,应该{}中的元素必须可拷贝,生成的过程也相对有些消耗,因此std::initializer_list 对象的生成要考虑考虑拷贝的性能,另外使用它的时候也要注意底层关联的临时数组的生命期!一般情况下,为了保存数据,接受生成的std::initializer_list 的一方还要二次拷贝数据!

这里确实是我想当然的写了一句推论,没有经过深思熟虑,谢谢指正~

一个潜伏了5年的bug中,我这样总结MySQL SELECT语句的返回顺序:

MySQL对于无ORDER BY子句的SELECT的语句的返回结果有潜规则:

  • 对于MyISAM引擎来说,其返回顺序是其物理存储顺序;
  • 对于InnoDB引擎来说,其返回顺序是按照主键排序的。

这是当时在查bug时google到的一篇文章中说到的,也正好能够解释我当时看到的现象。但是事实证明,我这里的理解是有偏差的。

但是,老司机@逝水fox指出:

什么都说得好,就是总结的太胡扯了。[尴尬]结果顺序和具体引擎对数据结构的使用有关。举个例子,innodb使用辅助索引进行筛选的结果,有无启用mrr优化,返回记录顺序是可能不同的,不一定就是主键序。其实,遇到过最奇怪的顺序问题,不是MySQL,而是Oracle,即使用了order by,数据记录的顺序仍然可能是不一定的

另外,也有老司机指出,可以通过ORDER BY FIELD来控制MySQL直接按照WHERE IN子句内的顺序返回。


谢谢各位老司机,暴露自己理解上的问题,纠正自己的错误认识,这也是写技术博客的很重要的收获~

转载请注明出处: http://blog.guoyb.com/2016/08/27/correct-errors/

欢迎使用微信扫描下方二维码,关注我的微信公众号TechTalking,技术·生活·思考:
后端技术小黑屋

Comments