这是fengyqf的博客
使用MySQL做数据，有时会隐约感觉到一些语句执行速度极其慢，而理论上应该是很快的。通常使用phpMyAdmin作为客户端，在表结构页里可以方便的看到索引状态，对基数cardinalyty一知半解，隐约理解为惟一值个数。
但前两天写一条查询语句执行速度非常非常慢，看到一个索引的基数竟然是空的，而且明明应该有很多值。猜测MySQL出bug了，于是删除并重建了索引，基数正常了，语句也飞快跑完。于是稍多留意了一下索引基数。同一天，看到一个基数为1的索引，也是很多惟一值的字段，这也不正常。因为是MyISAM表，直接打包了对应的.frm, .MYD, MYI 三个文件，保留一个现场，[……]
这只是个无聊的小把戏。
最近又看到关于qwerty键盘布局的讨论，有提到好的键盘布局标准之一：把连续的按键分散在左右两手上，这样第一只手击键的同时，第二只手可以提前做好准备，提高效率。
于是从网上找了一批古典英文小说的txt电子版，写了个傻傻的脚本，统计其中连续两个字母的频次（忽略大小写），其中频度最高的前30项如下表。这30项共计占总频次的43.3%.
如前述，“是否可以把连续击键分散在两只手上”，即表格最后一列。从结果上看，分散与否各15项，所以qwerty在这个标准上优势似乎并不明显。
当然，这并不能证明qwerty键盘是不合理的；毕竟评估因素非常多。[……]
FireFox 扩展Adblock Plus
使用原则：只阻止过于反感的广告，其他广告一律放行；亦即，自带的过滤列表一律不激活。
创建和编辑您的过滤列表
//pos.baidu.com/ //static.mediav.com/js/
[……]
MySQL的缺陷/Bug/异常/陷阱/注意事项
这里只是个记录，踩过的坑
REGEXP 对中文的错误识别，如下语句，结果竟然是1，在 MySQL 5.5.53, MariaDB 5.5.60, MySQL 5.7.24 下测试结果一致.
SELECT '区中医院' regexp '[一二三四五六七八九十〇]{6,}' as mt
这个问题是在utf8-general-ci 数据表上做regexp匹配连续的数字汉字时发现，暂时没测试否与字符集的选择相关，猜测是regexp本身行为对宽字符集支持的问题。
已确认 MySQL 8.0.4 以后解决了该[……]
shadowsocks, 现代科学上网的里程碑式产品，早已经停止更新，github上的原项目已经删除。其后继者为shadowsocks-libev，有多个平台上的版本，目前主流的平台都有其客户端。
可使用的yum源：
软件：采用当前（2019/03/28）的最新x64位版，软件都从官方下载。
测试素材： 1) WordPress源码解压缩后的文件夹，是 wordpress-3.5.2-zh_CN.zip 比较老，没有特别原因，只是电脑上正好有这个zip包而已。 2) 一批数码相机照片，计400多张，370M.
使用WinRAR与7-Zip分别压缩，含标准压缩、最大压缩，压缩成[……]
直接上代码及调用示例，调用示例：
假设有一张表user_status_in_playground，存储了用户在每个游戏场的统计数据，如总积分 、玩过次数、最近玩的时间、最近次得分。逻辑上 user_id + playground_id 是个惟一键，我们希望按照这个惟一键追踪其它字段的数据变更记录（建数据快照）。需要快照时执行一次存储过程，快照数据存到表archive_user_status_in_playground里。其中归档表只需要指定表名即可，将由存储过程自动创建。
SET @data_source='source_db.`user_status_in_playground`';[......]
2018/12/26 23:30 linode 关闭删除前一些状态备份，算是愐怀吧
uptime
[root@n feng]# uptime 15:35:19 up 240 days, 20 min, 1 user, load average: 0.00, 0.00, 0.00
free -m
[root@n feng]# free -m
total used free shared buffers cached
Mem: 979 598 3[......]