在获取cookie时，Java是不会对数据做任何处理，但是php则会默认进行一次urldecode操作，这导致了，两边系统里面获取同一cookie时，结果不一致的 bug。

类似的问题 PHP 在解析外部变量时的一个 BUG

很多时候，最大的优势在某些情况下就会变成最大的劣势。PHP 语法非常灵活，也不用编译。但是在项目比较复杂的时候，可能会导致一些意想不到的 bug。
那是时候体验一下代码静态扫描工具啦。

最近通过一个日志表做排行的时候发现特别卡，最后问题得到了解决，梳理一些索引和MySQL执行过程的经验，但是最后还是有5个谜题没解开，希望大家帮忙解答下

主要包含如下知识点

• 用数据说话证明慢日志的扫描行数到底是如何统计出来的
• 从 group by 执行原理找出优化方案
• 排序的实现细节
• gdb 源码调试

好的语义表达是团队协作中高效迭代的润滑剂，好的语义表达是线上未知代码问题排查的指南针。

不要让其他人读不懂你的代码，其他人可能就是一周后的你。时刻以“如果你写的这段代码出现故障，一个陌生人接手你的代码需要多久能处理完这个bug”来监督自己。

日常中应该多多刻意提升自己语义表达，百利而无一害。那么我们应该从哪些细节去做好语义表达呢？

使用 optimizer_trace 可以更加详细的看到 mysql 的整个执行流程，作为分析优化思路，验证优化思路非常有帮助。

需求：现在需要统最近一个月阅读量最大的10篇文章
Mysql 版本 ：5.7

mysql> show create table article_rank\G;
*************************** 1. row ***************************
       Table: article_rank
Create Table: CREATE TABLE `article_rank` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `aid` int(10) unsigned NOT NULL,
  `pv` int(11) unsigned NOT NULL DEFAULT '1',
  `day` int(8) NOT NULL COMMENT '日期 例如 20171016',
  PRIMARY KEY (`id`),
  KEY `idx_day` (`day`),
  KEY `idx_day_aid_pv` (`day`,`aid`,`pv`),
  KEY `idx_aid_day_pv` (`aid`,`day`,`pv`)
) ENGINE=InnoDB AUTO_INCREMENT=240776593 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

有一个业务是查询最新审核的5条数据

SELECT `id`, `title`
FROM `th_content`
WHERE `audit_time` < '1541984478'
    AND `status` = 'ONLINE'
ORDER BY `audit_time` DESC, `id` DESC
LIMIT 5;

查看当时的监控情况 cpu 使用率是超过了100%，show processlist看到很多类似的查询都是create sort index。
查看该表的索引有一个audit_time在左边的联合索引。

分析上面的sql执行的逻辑：

• 从联合索引里找到所有小于该审核时间的主键id（因为该sql查询的是最新审核的，假如之前已经审核了100万条数据，则会在联合索引里取出对应的100条数据的主键id）
• 回表，查出100万行记录，然后逐个扫描，筛选出status='ONLINE'的行记录
• 最后对查询的结果进行排序（假如有50万行都是ONLINE，则继续对这50万行进行排序）

最后因为数据量很大，虽然只取5行，但是按照我们刚刚举的极端例子，实际查询了100行数据，而且最后还在进行了50行的内存排序。

所以是非常低效的。

在接收外部变量时，多个相同的外部变量，在nodejs中会被放在一个数组里面，而php中则是后者覆盖前者，如果需要传递数组变量，则在变量名后面添加上[]。这个不兼容，ok，是语言的特性能接受。

但是在php中在解析id[]_text的数据的时候都转换成id[]了，这点就有点坑了。

开发同学按照传达的精神使用了上次说的大表翻页优化的方式在做翻页查询了。执行时间97秒。

select a2.id,a2.keyword,a2.url from (select id from table_name order by id asc limit 73575000, 5000) a1, table_name a2 where a1.id=a2.id

select count(*) from table_name;

执行查看表总数都执行了70292.60ms，总行数是118345950行。

对于这种表，做大表翻页优化，也已经无效了。那应该怎么弄呢？

我们先不去纠结历史原因，为什么没有分表。着眼解决当前的问题。
问下具体开发的同学，是在全表扫描这个表是否命中一些违禁词。这样就好办了。我们只需要“分段扫描就行了呀”

看到数据库报警，查看慢 sql 日志看到

select id, content from table_name where status = 1 order by id asc limit 1328000, 1000

执行了 90 秒，扫描了 1329172 行。

改写成

select a2.id, a2.content from (select id from table_name where status = 1 order by id asc limit 1328000, 1000) a1, table_name a2 where a1.id=a2.id;

总结

这种数据量很大的表，应该是先做一个子查询查出 id（只会在索引里面扫描），然后关联查询，这样扫描的行数是限定的。而不会扫描表前面所有的行。

1. 演示 jquery-ujs https://mengkang.net/demo/rails/
2. 原理解析 - 代理表单提交 https://mengkang.net/demo/rails/2.html
3. 原理解析 - 实现 ajax 提交 https://mengkang.net/demo/rails/3.html
4. 扩展开发 - 行内回调 https://mengkang.net/demo/rails/4.html

我的弹幕服务，代码换了个环境运行，虽然服务可用，但是发现出现了如下情况，基本1秒输出来一次：

java.io.IOException: Connection reset by peer
  at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
  at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
...

因为我有两个网卡，请求是从 eth0 进，从 eth1 出，我尝试使用tcpdump -i any 发现第三次握手输出的 askno 数据不对。（为什么会这样呢，还不知道，谁知道请告知下）

初衷

通过一些明确的规范来提高云栖社区 UED、前端、后端的工作效率。

现状

视觉交互半规范化，不够系统，需要不断的完善

我从聊天记录来看，爱申是做了一些色值等方面的标准和规范，而且交付给了前端同学，前端同学在工作的时候能快速的工作。点赞。

但是没有全部明文列出，不够系统。打个比方，一般的封面图片 hover 需要出现一个放大效果的。由于我们每次外包同学都不一样，导致新外包介入时，就忘了这个效果。
使得5个页面上的有封面的地方都需要去加一个遮罩，然后做完以后，后端同学（我）再把对应的模板也都修改一遍。

这样类似的返工还有很多，比如字号，行间距，padding，margin 等，不仅每次需要 UED 的同学仔细审查，也会需要前端同学不断返工。

早上去没吃饭，帮忙做技术统计，学习新技能了。（汉字不是我写的，我写的没这么丑）下午替补出场，罚球100%命中率，投篮命中率50%，怒砍4分，大获全胜。好久不打球，打了20分钟左右，感觉不怎么累，对方防守强度不够。

感谢公司组织文化部的同学发起了本次比赛。公司的宣传海报都换成了篮球赛的，想必费用也不少吧，每队的球服费用，场地费用，报名人员的保险费用。记得刚来阿里云的时候，因为组织阿里云和追光动画打球，组织文化部的同学在自己周末的时间专程从杭州飞过来租场地，买水果等，忙到好晚。比赛的时候也全程陪同，给大家加油打气。那段时间虽然加班很多，但是那次的确给人一种家的感觉，虽然加班也不那么苦了。

问题

例如有这样一段文字

$$net_{h1} = w_1 * i_1 + w_2 * i_2 + b_1 * 1$$

公式里面的*和_都可能被 markdown 语法解析。导致最后公式无法正常解析。

鸟哥微博

为什么要字节对齐

需要字节对齐的根本原因在于CPU访问数据的效率问题。因为CPU每次都是从以4字节（32位CPU）或是8字节（64位CPU）的整数倍的内存地址中读进数据的。（更深入的原因，谁告知下），如果不对齐的话，很有可能一个4字节int需要分两次读取。

数据类型自身的对齐值

按各数据类型自身大小进行对齐。变量的内存地址正好位于它长度的整数倍