公司线上项目一个库的cpu使用率总是偏高，经同事点拨，发现一处索引使用不当。
首先观察下面的表结构。
CREATE TABLE `live_calc_1b` ( `vid` varchar(100) NOT NULL, ... PRIMARY KEY (`vid`) )
再看下面的这个sql。
select * from live_calc_1b where vid = 14635808219671833713;
看似很普通的使用场景却暗藏隐患，发现了没？
今天在公司调试业务接口，发现一个会引发408的场景。记录一下。
起因是charles的一个bug，用edit功能编辑请求，会导致请求原文中丢失post body。
这样造成的后果就是content-length非0，但body为空，nginx对于该请求会一直处于阻塞状态，等待客户端发body，最终超时。
今早到公司，发现很多人反馈测试环境接口500了。查了下fpm的错误日志，发现数据库连接不上了。
按照配置手动执行mysql -h localhost毫无问题。但是通过fpm就是会抛出connot connect database的异常。
把项目代码中的数据库配置地址由localhost改成127.0.0.1就奇迹般的没问题了。
最终，发现数据库的mysql.sock文件位置被移动了。
另外，经过google，发现fpm连接mysql时，配置为localhost与127.0.0.1的连接方式是不同的。
