不想折腾的话，尝试下载一个旧点版本的 GO ？

你先看下 pid 文件里是什么内容，cat /var/run/nginx.pid
很有可能是这种情况，比如，pid 不存在于那个文件，或者 pid 文件里面存的 pid 是这样的：12345%，
他多了一个%号，然后命令就出错了

1：限制请求频率（通过定时器）
2：单次请求利用最大化，每次打包请求的时候，尽可能多的打包几条数据，比如：服务端上限是 1000 字符，那你客户端，看下在 1000 字符以内，尽量装多几条数据，可以提高效率

如果服务端完全不能动的话，那你客户端可以做 2 个事情：

你这个应该可以用 a_colum IN() 吧？

用 php 框架就尽量不要写原生 sql 了，php 框架的数据库操作非常完善和好用，如果某些特殊的需要写原生 sql，直接写就是了，一点都不要担心，我保证，这样的特例，是极少数的，并不会对后期造成太大的困扰

@Bramblex2 既然自己有主导权，也在重构，那么你可以做到统一风格了，我认为，你无论采用哪一种风格的接口，和前端解释一次，说之后都是采用此种风格，我相信一个能正常沟通的前端，都不会去纠结这个东西。

如果你仅仅是想知道，那种风格看起来比较标准，我平时是比较喜欢：B:null，前端有提出要求的话，我也是很乐意改的

个人看法，其实我觉得大家说的两种都没有问题，关键有两点：1 、该项目主要由谁来制定标准，该标准是否在各个客户端兼容性良好。2 、风格要统一。
什么是风格要统一呢？就是比如：你这个项目，数据结构用的是第一种，那就从头到尾都用第一种风格；用第二种亦是如此。
满足了这两点，我觉得前后端沟通成本就能有效降低，达成共识后，双方也就不再会纠结，这个接口怎么返回这种，那个接口怎么返回那种。

那么说下，既然风格统一有这么多好处，还会出现多风格的接口呢？出现这个往往都是有历史原因，经手人比较多，后来的人，不够了解前人的风格和做法，最后就造成了这种局面。
如果你看不惯目前的局面，要坚持自己的标准，那么请统一它、重构它。请问你做好这样的决心了吗？没有的话，请不要吐槽它，因为你自己也并不想花时间去改造它

@hyd8323268 如果你需求一定要时间排序的话，我觉得你可以试试，给时间戳建立索引，然后使用微秒级时间戳，看下这样能不能避免时间戳太多重复的情况？这个就要看你业务了

请问你是执行 select 字段 from 表名 order by 时间戳 desc,id asc limit 0,10; 的时候慢，还是获取表的总行数的时候慢？可以提供你的具体分页需求吗？是只做下一页，还是需要做页码的？
就我所知，千万级，select 字段 from 表名 order by 时间戳 desc,id asc limit 0,10; 的效率还是能接受的

php7.2，mariadb10.12 ，不想升级 7.2 以上了，感觉没有必要去趟坑

@ZRS 连接上之后是一样，但是多台服务器的时候，xshell 界面切换非常方便

@liuxu 我尝试创建了不同长度的 int，从表面看起来，他们没有任何区别，长度 1 的，实际上也能存储 1111111111 这样的数字，那么对于 int 来说长度约束，是不是没有作用的呢？

@joyeu 索引是 （ username+type+number 和 username+type ）

@joyeu 抱歉，结果搞反了，是（ 0.034s 和 0.11s ）

@joyeu 就我自己的业务情况而言，我刚才做了查询时间测试，（ username+type+number 和 username+number ）的查询时间平均为（ 0.11s 和 0.034s ）