theflowerofac^MQLYES的专栏

效果上，都是统计满足条件的总行数，不考虑是否为null。COUNT(字段)是要考虑是否为空。性能上COUNT(*)>COUNT(1)>COUNT(id)>COUNT(字段)能用COUNT(*)就用COUNT(*)个人感觉，COUNT(1)和COUNT(id)没有存在必要，可以放弃掉，这样简单一点，哈哈哈哈哈哈！

上周运维同学重启了UAT环境的MySQL数据库服务，刚开始我是不知道数据库重启了，先是业务服务开始异常，初步定位到的原因是一个表的主键ID出现了回退，又查到MySQL低版本（8.0以下）重启可能会导致自增主键值回退或重置，最后和运维同学确认了下重启时间，确认了原因。正如前文中所说，这种方式复杂且风险很大，MySQL8.0并不完全兼容低版本，升级后这个问题解决了，但可能会导致其他方面的问题，所以生产环境一般是不会同意这样做的。在MySQL8.0中，执行同样的操作，自增值仍为6，没有丢失，这里就不演示啦！

查阅后发现问题是由于max_allowed_packet参数引起的，该参数是指mysql服务器端和客户端在一次传送数据包的过程当中最大允许的数据包大小。一次插入的数据超过了max_allowed_packet，则会数据库保存失败，报出异常。我这里是批量插入多条数据，数据条数目测有个几千条，数据大小超过了阈值。网上解决方案是修改max_allowed_packet的值，调大这个值，临时修改或者永久修改都可以。比如之前一次插入5000条数据，我这里改成一次插入500条，分10次插入就ok了。

可以通过OPTIMIZE TABLE 回收掉没有在使用的磁盘空间碎片，但需要提前预估好供其“倒腾“使用的空间。