@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 好啊，有钱为啥不赚

吓了我一跳，刚登录发现刚好 1 年 5 天没登录我的 163 了

@ca1123 之前用过一段时间 k3s，现在卸了，空转也浪费资源，3B 只有 1G 内存，而且读写的都是 tf 卡

你这么想要树莓派我把我的卖给你，200 一个带 tf 卡，或者我下面那 5 台一套带那个亚克力板 tf 卡和电插板 1000 打包给你

@akmisty 喊你去喝酒然后趁机偷你装了私钥的笔记本

@ca1123 那你可要测试测试了，树莓派还有电压电流要求，要是不达标要么终端一直低电压错误，要么 hdmi 接显示器闪黑屏，电插排都要选好，4B 好像是要 5V3A 的电源，3B 也得是 5V1A 以上的样子，加起来你得算好了，我的就是电流不够 hdmi 接入显示器老是闪黑屏

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

@calmzhu 遇到了个大佬，终于有人分析压测图了

htop 观测（ linode ubuntu 20.04 ）:
裸机：Tasks：24，5 thread
裸机+dockerd: Tasks: 30, 25 thread
裸机+k3s+containerd: Task: 46, 117 thread
裸机+k3s+dockerd: Task: 52, 193 thread

问题：
1. 单 node 是因为 traefik 和 nginx pod 争抢 cpu 导致的瓶颈，2c4g 太低，25 thread vs 117 thread
2. 多 node 实际上我搭建压测环境偷懒了，实验设计会因为 1 的瓶颈导致整体没有达到最理想状态，新加入的 node cpu 利用率只有 50%左右，而 4node 一开始的延迟比 3node 还要高，就是入口 node 过载更严重导致，3node 用的 6k，4node 用的 7k

不过问题 1 才是我需要的答案，问题 2 对我无足轻重，只是想看看现有方案添加多 node 会怎样，所以问题 2 没有太严谨的压测

目前得到的结果是：
1. 后期会加强 ingress 入口机器的配置，并不是只加 agent 机器数量
2. 或者前置一个负载均衡均匀分配请求到所有 node
3. 或者用 CF 的 DNS 多 A 记录来分担负载

@carrotrollroll

k8s 系有 k8s，k3s，microk8s 等。标题是 rhel 的 yum 源慢，帖子说 centos 更新好慢有问题么

说的是小成本项目，铺个 100 台 64c128g，不管是裸机还是 docker 还是 k8s 系，最后 qps 都会相近，任何基础组件的损耗占比都可以被抹平，你还有 20%损失说明机器还不够多，再铺一倍机器损耗会到 10%

@salmon5

2c4h 是我自己的站常用的配置，我觉得的小成本就是几台 2c4g，为了测试我自己的项目用的，可能每个人眼中的小成本不太一样，而且我测试常用 vultr 或者 digitalocean 这种，最高配置 8c16g

@idblife 我自己的是有一堆小项目每年换服务器商能快速迁移，其次接入 github actions 自动化部署也方便很多，而且有时候突然流量来了能快速伸缩

@laragh 就是硬盘大的服务器

@zlowly 其实你说的都对，也是现状，也正是你说的原因，好多项目的系统还是 centos6，大家都没有养成应该持续维护升级软件系统的价值观，为什么大到桥梁建筑，小到路口路灯都有人维护，软件服务为什么都想一次买断

普及 debian 以及普及持续升级服务的价值观还有以下好处：

1. 5 年就必须更新一次系统，而不是 rhel 的 10 年，多了一倍工作量，可以为行业带来更多的工作岗位
2. 持续更新系统能够保证软件包够新，历史包袱少，临近版本的升级带来的不兼容也更容易修复，举个例子你是愿意把 php7 的项目迁移到 php8 还是 php5 的项目迁移到 php8
3. 即使你操作系统维护周期 10 年，软件源的软件不一定维护 10 年，最后几年会遇到各种需要自己添加软件源的情况，还可能需要处理各种依赖包兼容问题，新系统则极少出现此类问题


不仅是 ubuntu/debian，linux 内核或者是 freebsd 目前都是讲生命周期维护到 5 年左右，5 年是互联网共识，红帽腾讯阿里这些企业之所以维护 10 年，是因为老系统维护问题多，他们卖的就是服务，自然愿意维护 10 年。而普及 debian 得到的好处 1，就是要从他们嘴里夺食

别学一楼，给他人提供翻墙违法，搞台大盘鸡装个 sharelist 或者其他的

@ca1123 树莓派功耗差不多，现在得买 4b，但是 4b 默认得装散热片，不然 cpu 很烫

树莓派你跑 k3s 组集群，20 台你得再买个牛逼的交换机吧，我组 5 台开始用的 h3c s2g 的 8 口交换机，后来嫌网线太多直接用的无线路由器路由器，看你路由器支持 20 多台设备不

而且 20 台 4g 版本一台 500，20 台 1 万，性能还不好

所以最好还是 x86，看看小型机工控机，不独显不显示器功耗要不了 200w

@jiangzhizhou 很贵，按楼上大佬的意思搞几台 16c64g，简单的 4c8g 每个月小几千，个人项目和小公司很难负担吧

@tinkerer 要分析 k3s 发帖回帖是找不到答案的，找答案要自己分析系统 profile，主要是我自己的几个网站用的 k3s 后 qps 极速下降，我还以为是 cf 的问题，这测了下才知道是 k3s 导致