运维日志

打开表结构，14 个索引，其中 6 个是单列索引，还有几个前缀完全重复。这张 2000 万的表写入从 2000 TPS 掉到 600，磁盘占用比数据本身还大——索引比数据多。 索引不是越多越好。每多一个索引，每次 INSERT/UPDATE/DELETE 都要多维护一棵 B+ 树，写入成本实实在

服务器重启之后不起来了。屏幕上要么是 `grub rescue>`，要么是刷一堆 `dracut` 报错后掉进 emergency shell。这种时候最忌讳的就是乱试命令——搞清楚**卡在启动的哪一步**，问题就解决一半了。 启动的四个阶段 定位的第一步是判断停在哪： 1. **固件

权限问题的标准解法是 `chmod 777`，然后问题解决，然后没人再管。这事的麻烦在于：三个月后另一个人也遇到"没权限"，也 `777`，最后整个数据目录对所有人可写，谁删的你都查不出来。 Linux 权限其实就三层，搞清楚之后大部分问题有更干净的解法。 基础：rwx 到底是谁的 `

为什么 ETL 不够用了 传统数据同步靠**定时批量抽取**： ```sql -- 每天凌晨抽昨天的数据 INSERT INTO dw.orders SELECT * FROM oltp.orders WHERE update_time >= '2026-09-06 00:00:00';

手上几台 5.7 的库要升 8.0，第一反应是 `yum update mysql-server` 然后重启？别。我见过这么干的，重启完应用连不上，查半天发现是认证插件变了，账号全废了。升级这种事，慢就是快。 先跑官方预检，别凭感觉 MySQL Shell 自带的 `util.check

应用日志里蹦出一行： ``` Deadlock found when trying to get lock; try restarting transaction ``` 很多人第一反应是加个重试就完事。重试确实能让业务不报错，但死锁频繁说明**并发控制的设计有问题**，光重试是把火药桶盖住了