我以前和朋友的代码哦弄在自己的 gitea 上，后面迁移到了 github，不太好用

1 中排版有问题，更正一下：

1. 查看当前 locale 以及系统支持的语言
# locale
# localectl list-locales
C.UTF-8
en_US.UTF-8
很明显此时你没有 zh_CN.UTF-8

debian 一般默认是安装好了 locale 包的

1. 查看当前 locale 以及系统支持的语言
# locale
# localectl list-localesC.UTF-8
en_US.UTF-8
很明显此时你没有 zh_CN.UTF-8

2. 取消 /etc/locale.gen 中的“zh_CN.UTF8 UTF8”的注释，并让系统加载
# vim /etc/locale.gen
# locale-gen

3. 此时可以看到已经有了 zh_CN.UTF-8
root@li1604-45:~# localectl list-locales
C.UTF-8
en_US.UTF-8
zh_CN.UTF-8

4. 使用 zh_CN.UTF-8
# localectl set-locale zh_CN.UTF-8

5. 重新 ssh 登录，此时环境变量全部 zh_CN.UTF-8
root@li1604-45:~# locale
LANG=zh_CN.UTF-8
LANGUAGE=
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT="zh_CN.UTF-8"
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=


6.一般情况你还需要手动设置 LC_ALL，所以在~/.bashrc 里面添加
LC_ALL=zh_CN.UTF-8

然后加载
# source ~/.bashrc

这个重任就交给你了

@zxxufo008 我还以为是有人开机器人了，原来是换头像了

体验体验就好，正常用还是 lts

@Cu635 你可真是个严谨的大兄弟，连标点符号用的都是对的。

你要是 debian/ubuntu 的话我可以帮你详细分析下，其他的系统我就只能大致说下怎么查

首先你的 server-01 的 ip 似乎有一个 192.168.122.0/24，先确认下 server-0{1,2,3}和你本地机器的 ip 是不是在一个网段，互相 ping 一下
然后 server-0{1,2,3}的 iptable 、netstat 和 ifconfig 都看看
最后互相 curl，在双方机器上用 tcpdump 抓包看看

新人断层了，老早开始整个行业招聘都只招 2 年以上的，搞得 18-19 年的新人混不下去都换行了，现在 2-3 年的极少了

@Cu635 是的，ubuntu x.04 是 LTS

桌面和服务器都不要跟着最新，桌面版新 bug 比 server 还多，最好等 x.04.1 出来了再用

@wm5d8b 每台挂上探针观赏

变卖家产等双十一买显卡了，有老板要的没

一台 4 核 1G 内存，5 台 20 核 5G 内存，想感受集群多核的快乐吗，现在机会来咯

关键是全部包邮

5 台树莓派 3B 一起要的话，所有配件一起送（ 10 层亚克力板，5 个独立塑料壳，1 个金属 3B 散热壳，1 个 usb 插排，1 个 h3c s2g 交换机，5 根网线，5 根 usb 线，5 张 16g tf 卡，5 套散热片），1299

单台买送 TF 卡、塑料亚克力壳、散热片，USB 线一根，网线一根，259 （要金属外壳的话+19 ）

单台 H3C s2g 交换机，79

单个 USB 插排，39

https://i.imgur.com/YffQepB.jpg

https://i.imgur.com/tNjBD2H.jpg

https://i.imgur.com/XUQWEOd.jpg

https://i.imgur.com/87LgRBH.jpg

@EchoUtopia 哦看到了，mysql 8 支持，学习了，还活在 mysql5.7 里
安币种也可以，不过效果不好，像人民币和韩币的 2 个工资表大小肯定不一样，人民币的还是有你这个性能问题

@liuxu 这个表业务常用还有查询某个用户的工资，而不只是>1000，这样就会出现 where 条件是 user_id=xxx

我知道有些公司甚至不让用 join，我老东家曾经就有这个要求，所以你这个查询一个用户的工资会分成 2 个简单 sql 语句
1. 查询工资表
2. 从工资表拿到汇率 id，然后去汇率表汇率
最后业务代码里面合并计算

所以你最后的优化方案还是得看公司具体规定，能不能分表，换数据库

where 条件用了>最好的情况就是 range 类型查询，要是结果基数太大优化器就直接让全表扫描了，也就是不会用你的索引，想用的话可以添加 FORCE INDEX(idx)

能优化的方案就 3 个，首先是改写 sql，where 里面不要有计算，不然没法用索引（当然这个是 sql 预处理问题，未来或某些再发行版本可能优化为可以使用）。然后建覆盖索引，内存给够，扫内存而不是扫磁盘，包括 tmp 表内存限制给够，不要用到磁盘，参见 tmp_table_size 相关参数

第二是分表，这个是对于你这个需求是建议做的，简单合理又有效，我也常用，不过要选好 hash key，你这个表其实缺 user_id，一般 hash key 选它就行。你拆成 100 个表，每个表也就 10 万行，然后代码用异步框架 100 条 sql 一起执行，最后业务里面合并就好了。当然如果这个表有其他业务在用的话，建议同步到从表然后做这件事情

第三是用其他数据库

@chenqh 你看下你的请求头有没有 Accept: application/json，还是 Accept: */*，有的 client 工具默认是后者，会导致一些系统的异常页返回 html

@gabon 站群，全部 302 到一个地址，服务器是广州的机房，你买 10 台 1Gbps 的服务器，再买个代理，用 curl 脚本刷爆它

触发了百度的风控，一般都有，微博也有

@ca1123 好啊，有钱为啥不赚