@RickyC 并发测试的同时，观察一下 php 机器和 mysql 机器的 cpu 、内存、磁盘 IO 、网络 IO，可能的原因比较多，先排查一下

刚入行做网站的时候就去查过登录和登陆，结果是登录=注册，登陆才是正确的，但大多网站都在用登录

select * from 订单表 where id = ? for update 上行锁
commit 或 rollback 解锁

不是针对谁，在座的各位谁不是绝顶聪明

fpm 是多进程单线程的吧，你的业务代码应该是有高耗时 IO，导致 16 个 fpm 进程全被阻塞，新请求进不来，不改架构的优化方法：
磁盘 IO：开启 opcache 缓存，尤其是各种框架一堆 php 文件的，别每个请求都挨个读一遍；如果业务有处理大量小文件的，看能不能合并一个大文件
网络 IO：mysql/redis 机器放本机或局域网，索引优化好，text 字段没用到别查；第三方功能 api 换延迟低的
但治标不治本，进程模型处理 IO 任务很不科学，应该换多线程或协程，比如 swoole/workerman

吃透索引，亿级以内的数据查询很容易搞定，除非你只有 like %...%这一个条件
推荐一下极客时间的 mysql 实战 45 讲，非利益相关，纯粹觉得写的好

首先找到稳定复现 bug 的手段，然后二分查找法[doge] 找个中间层打 log，结果符合预期就在后半段中间继续打 log，否则去前半段打

我的想法是如果项目初期，需求变动频繁，qps 要求不高，可以 join 求灵活；反之需求稳定，qps 要求高，或新旧表业务关联性不高，就复制字段，需要同步修改的时候让旧表模块广播个消息

写 CRUD 真的没区别，鄙视了半天都是个人喜好问题

tcp 的服务，丢包率比延迟更重要

openssl_decrypt('odnPsVDQN6vBY5JZGwRFkTfmvfJ9tXjRwpu7IFL+YrgHJH7ctSXfjSQO36KZAuVpLqEB9X9fLIZauCjyUXrsUIYBX5KJmH/kksSU+us+bv+6RzrWmJmUJBiUnBBuBFbWPOHl4if54x0N3qwAZCp3vYDiQzAFSSQKSQ+Pz/gZRd/YdLxhMsPAQyv4VWDbNrk+9L1EtDOzgUfgDWxoK4ajjA==', 'AES-128-CBC', '999c09e1ba2e4dccb44aaf8d', 2, 'c4881489376b4d12')
有结果，不知道对不对

项目中写小文件的任务改成单文件追加，设计一个简单协议，对这个大文件分段，比如前 8 字节表示段数据大小，再扫描到\0 是该小文件的路径，其余是小文件数据，积累一定时间或数据量时新建一个大文件，然后调用一个外部程序按协议拆解前一个大文件，不知道这个方案是否可行

url 里面的域名要替换成 httpdns 的结果 ip，然后手动设置 Host 为域名
http 层并没有目标 ip 地址，ip 是封装在 tcp 包里的，所有的代理软件都是查看 http header 的 Host 识别用户访问域名

oss 挂载到 ecs 需要备份的路径上，开启 oss 的多版本备份功能，这个方法恢复单文件方便，怎么全盘恢复到指定时间还不太了解

你在任意目录运行 php -v 的结果是什么

php 是最适合个人或小团队做中小 web 项目的语言，没有之一，但也止步于此了

@hackingwu 突然发现自己上面的描述不对，应该是走了全索引树扫描。我猜优化器发现你的 t1 索引包含了全部需求字段，所以在 t1 索引树上做全部扫描，而没有去主键索引树（原表）做扫描，因为 t1 树的字节大小一定小于原表，更节省磁盘 I/O 。所以你的 explain 结果用到了覆盖索引。说的不对请指正。

覆盖索引应该是指索引树上包含了本次查询的全部字段，无需回表，你的 sql 是符合的
但查询条件 c2 不在 t1 的开头，所以走全表扫描

1080ti 坐等 3070