最近遇到生产环境的运维反馈，每天的生成的日志信息占用较大的磁盘空间，希望研发能减少部分无效日志信息，把日志文件拉回来看了一下，主要是在MySQL的一些执行打印了text等大字段的数据，当这些表频繁进行插入、修改动作时，导致一直打印这些大字段数据，从而导致占用较大的磁盘空间，但是我们又不能直接关闭mybatis的执行打印日志，在生产环境出现异常时，我们还是需要根据这写执行日志来定位问题，所以最后想是否能将打印的控制逻辑细化到字段上，也就是说对于类型为text等类型的大字段不输出，简单使用一个占位符替代，从而达到既不影响异常问题的定位，也减少了一些无用日志信息。
最近闲来无事看到一篇关于DynamicTp动态可监控线程池框架，也去DynamicTp官网看了一下，发现原来跟Hutool出自同一个社区，想着上手试试，看了下官网的『使用步骤』发现需要引入配置中心，在工作中apollo已经使用比较多，所以这次想尝试一下使用nacos。
事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。
感觉自身对于MYSQL的知识点是零散的，没有形成网络，只用到了基本的增删改查功能，偶尔遇到一点性能的问题，还需要通过搜索引擎来查到解决方案，并且查找到的解决方案参差不齐，导致往往问题虽然解决，但是还是不知其所以然，从而重复出现问题时，也不能较快的解决问题。据说MYSQL45讲对MYSQL介绍比较细致，所以希望通过学习MYSQL45讲让自己的MYSQL形成知识网络。
一句话简单来说，索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。一本 500 页的书，如果你想快速找到其中的某一个知识点，在不借助目录的情况下，那我估计你可得找一会儿。同样，对于数据库的表而言，索引其实就是它的“目录”。
公司中提交MYSQL脚本有相应的规范，需要编写为groovy文件，同时里面包含了一些其他信息项，有对应版本、编写人、模块编码、日期等等，每次写脚本时都通过拷贝旧文件，再修修改改之后提交，所以错误率比较高，想着通过配置信息项以及通过代码来直接生成对应脚本。完成之后发现，虽然达到了生成脚本的预期，但是交互是在console控制台上交互，使用上有点繁琐，偶然看到关于IDEA插件开发的博客，想着是否可以通过IDEA插件来写一个UI，生成逻辑直接使用原有代码移植过来。同时记录在开发IntelliJ IDEA插件过程中遇到的一些问题和踩到的一些坑。