看到 mysql.proc 相关错误时，很多人第一反应是“表坏了”。
这个判断不完全错，但 2016 年我在看这类问题时越来越觉得，真正值得警惕的不是某一张系统表本身，而是它背后通常暴露出一整段升级和权限处理流程都没收好。

数据库升级这种事，很多团队会认真写升级步骤，却不认真写回滚步骤。可真正到了线上，最能决定你心态的往往不是“怎么升”，而是“如果升坏了，能不能稳稳退回来”。

图形化数据库工具很容易让人操作得太顺。
尤其是像 DataGrip 这类客户端，连接、查询、查看结构都很方便，很多动作看上去像在本地演练一样自然。但 2016 年我开始更频繁地用这类工具处理线上数据后，最先养成的习惯反而不是记快捷键，而是先看自动提交有没有关掉。

2016 年接手 Java 项目时，我遇到过一种很典型的混乱：同样是处理用户逻辑的类，有的叫 UserDao，有的叫 UserMapper，有的叫 UserServiceImpl，还有的直接叫 UserManager。项目还能跑，但只要需求稍微一变，大家就会先花时间猜“这个类到底管什么”。

图片上传这类接口最容易在需求讨论里被说成一句话：选文件，传上去，返回地址。
可 2016 年我在做这类功能时越来越明显地感觉到，一个上传接口如果一开始只关注“体验顺不顺”，却没有先限制大小、类型和错误边界，后面出问题会非常频繁。

带坐标的数据一多，最常见的需求之一就是“按距离最近排序”。
很多人一开始会先把经纬度查出来，再在应用层自己算距离、自己排序。小数据量时确实能跑，但 2016 年我在看这类场景时越来越觉得，所有距离计算都堆在应用层，其实是在主动放弃数据库已经能帮你做的一部分工作。

服务启动失败这件事，最怕的不是问题复杂，而是人一慌就到处乱看。2016 年自己管机器的时候，我也吃过这种亏：一发现接口没起来，就先怀疑代码、怀疑框架、怀疑依赖版本，结果折腾了半天，最后只是端口被别的旧进程占着。

给老 PHP 项目加缓存，表面上看很像一件“性能补丁”工作：慢了就加缓存，数据库忙了就挡一层。
可 2016 年我自己在碰这类改造时，最大的感受不是技术难，而是很多老项目根本没人能完整说清楚数据到底是怎么读出来、又是从哪里被改掉的。

2016 年做接口优化时，缓存几乎是最容易被提起的方案。接口慢了，加缓存；数据库忙了，加缓存；列表页扛不住了，还是加缓存。可真正做过几轮之后，我反而越来越谨慎，因为缓存很少是“开了就完事”的提速按钮。

很多人一说文章迁移，会先想到正文是不是完整、标题和日期有没有带过去。
这些当然重要，但 2016 年我在整理和迁移一批 Markdown 内容时，最让我头疼的反而不是纯文本，而是那些看起来像细节、丢了却很影响阅读体验的东西。