之所以说奇葩，是因为问题解决了，我却还没想明白问题的原因在哪。
前两天帮朋友给一个机器换了环境，从原先的CentOS换到Debian，当时没什么问题，也都很顺利。
今天朋友找来，说文章列表有点问题，一个是不显示新文章，另一个是通过ajax加载的列表页扩展数据有重复。
我看了一下确实有这情况，可这也是我第一次遇到这种情况，查了web日志，没有错误。
后来想起来可能跟数据库有关。
原先环境里是宝塔面板，数据库是mysql 5.6.50，新的debian系统数据库是mariadb 10.3.xx，这个应该没什么问题。可原先的数据表引擎是innodb，而我习惯性会将这个引擎禁用（推荐做法），于是表创建为myisam，这个理应也没什么问题，可我偶然看到所有表的自增字段设置全没了。
好吧，我手工改了几个，问题没解决。用最原始的备份文件重置数据库，依然没解决，于是我看了一下原先的mydump导出文件，里面确实没有自增字段的定义了，这是个很怪的事，就是疑点一。
我习惯性进行网站迁移的时候会先在备用机或者目标机器上面做好环境和数据，测试没问题再进行实际迁移，避免出岔子。
可tmd我发现备用机上的自增字段也没了……而这个字段定义与否并不影响现有数据运行，所以当时没发现。
还好还好，我进行这种重大迁移的时候会至少进行两种备份，于是用另一种备份重置了库，在备用机上面问题解决了。但是我把整个库导回生产机器的时候，问题依旧。于是把所有网站文件又用rsync同步了一次，问题已经很接近彻底解决了，但是扩展列表依然有重复数据。
反复排查之下，发现litespeed cache这个插件缓存数据捣的鬼，把他禁掉，问题彻底解决。
于是我推测的可能性是原先做环境的人不讲究，我也不清楚他改动了什么配置，使得mydump导出的文件居然能丢失字段定义，而且是部分定义，而且是所有表都丢。
题外话 1，以现在的硬件情况来说，innodb没什么优势，还容易丢数据，个人强烈不推荐，特别是wp这种写入并发很低甚至是低到根本不会并发写入的程序，用innodb是个不恰当的做法。
绝大多数情况下，一定要追求性能的话，数据库一般都不会太大，直接把数据放内存里，这效率提升的幅度是很惊人的，根本不用考虑数据表引擎能有什么优势劣势。
题外话 2，要做重大迁移或者要完全毁灭现有环境的时候，备份手段一定要靠谱，最好能人工看一眼，最好能先搞个备用环境实际测试一下，最好使用多种/多点备份方法。我这次惊险的快速处理掉问题就是依托于良好的习惯，不然这次真要头大了。