从 Anemometer BUG 到 FRM 文件的恢复

最近深深体会到，目前的发展速度，数据库方面各种东西，原理层出不穷，一个礼拜不去看那些公众号去“滋养”，一下脑子，就发现新的概念不知道了。

题目是Anemometer， 估计大部分不是MYSQLER的不大清楚这是个什么东西，其实这是几年前通过WEB界面查询MYSQL 慢查询的一个方法，安装上，通过一些脚本，就可以让每个MYSQL的服务器的慢查询显示出来。

本来应该是驾轻就熟的事情，装上去，然后每台机器传送慢查询的语句过来，在进行查看，没有那么的复杂，可就是简单的问题，发现安装上，根本不显示东西，在注意一下github 上安装的方法和配置文件的部署方式上已经变化了，按照变化的方式搞了半天，还是无法显示。

后来请来单位的PHP 牛人，给看了一下PHP程序，找到其中的BUG，发现是$system_timezone 无法获得正确的时间区域，造成的，指定了一下时间区域，github上的 Anemometer开始工作了。

当然后续头疼的事情也有，PT工具输入后的数据和数据库中的结构有不一致的情况。所以有些时候某些开源软件的使用只是一段时间，而后期如果公司有强需求，需要考虑自己去开发一套这样的东西。

按下锅盖，起了瓢，最近MYSQL 的测试服务器，因为整改，原来的设置, 所有的文件都没有per file ，而是都在一个ibd 文件，整改后就出了问题，数据读不出来了，测试的数据倒是不重要，但是表结构对于测试时重要的，开发人员希望能恢复MYSQL 的表结构，根据原来的经验，直接的选择就是 mysql-utilties 工具集合里面的 frm文件修复，本来想的很简单，现实很骨感，服务器上的PYTHON 版本 3.6， 由于对于python + LINUX 的更换版本的操作，本人表示，很白痴。搞到最后，连YUM 都不OK 了，（因为YUM 使用PYTHON），所以最后的结果是从新找了太干净的机器，按照老的方法把 mysql-utitiles 装上，然后恢复FRM 文件，本来还在担心这个工具集已经走到生命的终点，（其实还是蛮好用）。后来一想，MYSQL 8.0 就没有 FRM 文件了，这个功能就不需要在担心了。

另外最近工作中发现一个项目，对数据库的选型越来越有需求，比如一个需求里面如果客户，强烈希望有模糊查询，并且对RDS数据库的需求，那如果继续选择 ORACLE  SQL SERVER , MYSQL 将对程序员是一件痛苦的事情，明摆着如此查询早晚出性能问题的事情，如果不对各种数据有了解，那闭眼去选择大概率是要吃亏的，后期程序上要搞模糊查询的成本会比较高，而如果知道 POSTGRESQL 的能力，则毫无疑问的直接选择，降低开发和运维的成本。又例如，数据选择了MYSQL ，但数据的经常有瞬间的 IN OUT  高峰，那就的分析高峰时刻是否有缓解的方法，例如把MYSQL 进行分库，或者使用REDIS + MQ 的方式前期将数据HOLD在前端，后续让数据库慢慢消费，这些都是有场景的，所以脱离业务去单纯的谈架构， that's a day dream.

所以我一直认为，不理解业务，就去使用一个种database是很草率的，并且数据库发展到今天，传统关系型， NO SQL , NEW SQL  ，内存数据库，时序数据库， 选择的余地是越来越大，需要了解的东西也越来越多。