原来以为MySql从删库到跑路只是句笑话，没想到是真的。这学期才学数据库原理，以前人们总是说数据要经常备份，不然哪一天就会后悔，果然昨天我就碰到了这么倒霉的情况...

昨天晚上没事做，发现typecho后台文章cid的变化有些奇怪，按道理来说主键自增不会出现突变，可是cid有时却从50多跳跃到了90。于是我便在百度上找到了这个坑爹帖子。本来想着是优化一下数据库表的结构，直到运行了这个sql语句后TRUNCATE TABLE typecho_contents，突然发现，咦？为什么查询不到结果了？？？原来数据库的一个表被我删掉了。当时就急了，这个作者什么都没提醒啊，我之前也没用过这个语句，根本就不知道这有什么用途，还以为只是优化一下表呢。百度一查，这个TRUNCATE语句就意味着DROP+CREATE...不仅删掉表，还重建了表。如果只是删掉了表，那么还可以通过闪回操作恢复，但这样之后就没办法恢复了。当时瞬间整个人就懵逼了，我从来没有手动备份过，不知道有没有自动备份。检查了一下，不仅没有自动备份，连事务日志都没有。正常的数据库级恢复方法当然就没有用了，只好跑去腾讯云那里发了个工单，看他们有没有自动备份硬盘。我真佩服腾讯的工程师，凌晨居然都还有值班的，回复我说：需要自己手动快照才能备份。

好吧，这下就彻底GG了，之前的博客文章都是直接在typecho里写的，电脑上也没有备份，这么久的心血难道就毁于一旦了吗？还好想起了搜索引擎快照这个东西，百度一下果然没有，谷歌上一搜就找到了，赶紧连夜从谷歌快照上恢复了这么多博客文章。所以说数据库一定要备份啊！不仅需要数据库级的备份，也需要异机、异地备份，以防万一，不然就只能从删库到跑路了...

PS：真正的修改方法是：alter table typecho_contents AUTO_INCREMENT=100;