有个现象很常见：
业务系统变慢，老板第一句“加机器”；开发第一句“接口没问题”；运维第一句“CPU 没满”。
最后查一圈，锅在数据库。
今天不聊职位定义，直接聊企业里最容易踩的 3 个库侧坑。
1. 慢查询没走索引
不是写了 WHERE 就等于快。
这些情况常失效：
对字段套函数：WHERE DATE(create_time)=...
隐式转换：字符串字段传数字
复合索引顺序错
LIKE '%xx' 左模糊
返回列太多触发回表
表现就是：数据量小的时候没事，涨到几百万行突然拖死接口。
解法不是背 SQL，是看执行计划（EXPLAIN），看它有没有走索引、扫了多少行、有没有 Using filesort。
2. 锁等待和长事务
有时接口不算慢查询，但就是卡住。
常见原因：
事务里夹了外部接口调用
批量更新不分段
手动开启事务忘了提交
报表 SQL 跑在业务库主库
结果：行锁堆积 → 后续写入排队 → 表面看是“系统卡了”，实际是库在等锁。
正规做法是业务库和报表分析分开，长查询走从库或只读实例。
3. 备份有，但没验过恢复
很多企业备份任务是开的，真出误删却恢复不出来：
备份文件过期被清了
增量链断了
字符集不对
恢复完权限丢一半
数据库工程师的日常里有一项很关键：备份策略 + 定期恢复演练
不是“我备了”，是“我能按时恢复到某个时间点”。
这活谁来做
小公司常是后端兼着弄，量大了一定得专人。
岗位名字可能叫 DBA、数据库运维、数据库开发、数据平台工程师，干的活绕不开上面几块 。
AI 助手能帮什么
现在确实有工具能生成 SQL、给优化建议，但两件事它替不了：
判断这条 SQL 在线上会不会锁业务表
出故障时报错堆栈背后的真实成因
所以企业里更稳的搭配是：AI 辅助写 → 工程师审执行计划 → 生产环境灰度
EEC工信教考中心，数据库工程师，辉达
丁老师13522094648
马老师13391509126
系统卡顿别先加机器，先查慢查询、锁、备份三件事。想转这方向，建议从 MySQL/PG 的索引、事务、备份恢复三块啃起，比最新框架更保值和适用。
