这是学习笔记的第 1833篇文章

首先做个背景说明，我的工作重点内容是MySQL方向，说MySQL的问题不是说MySQL不行，而是希望通过一种开放的方式来讨论，同时也不是说MySQL欠缺的地方，就一定需要参考其他数据库方向的。

当然在这篇之后，我会再写一些MySQL独有的一些亮点特性。

首先，我觉得有几个地方是MySQL待改进的，待改进不意味着要添加，也需要做减法，我觉这些应该是明确不会大力支持的：

1. event的支持问题
2. 存储过程,触发器
3. 分区表

本意是希望能够在应用设计中做出合理的取舍，不要什么都在数据库层面来做。应用透明了，数据库层不透明，一动就出问题。 而且这些从MySQL的适用场景来说，本身就是一些硬性的限制和瓶颈。

其次我觉得下面的一些点是MySQL待改进的地方。

• 网络服务不支持多端口

我们使用习惯了可能就不会有疑问了，但是如果跳出来看这个现象就会发现其实本身这一块是比较薄的需求，能够支持多端口也就意味着我们的服务也可以做到不同粒度的访问控制了。

• MySQL的角色配置不明确

在Oracle,Redis里面，数据库会有一个明确的属性Role,在MySQL里面可能和它的扩展性设计有关，是没有这样一个明确的定义的，目前我们通过应用层把MySQL的角色定义为Master,Slave,Relay,SingleDB,其中Relay和Single是Master和Slave之间的两种状态，如果能够支持Master或者Slave，其实这一块的处理方式也会简单许多，使用show processlist,show slave hosts,show slave status的方式还是比较繁琐，因为信息监测通常都是单向的，如果能够通过属性或者配置的方式得到一个统一的信息是很不错的体验。

• 主从数据延迟的改进空间

MySQL在Slave端的从库延迟如果要完全参考seconds_behind_master是会出问题的，这一块pt是有另外一种设计思路，在这个参数的使用上，其实目前也是一种临界状态，可以和同步模式下的一些差异来有所区别。

• binlog的状态信息不够丰富

如果使用show binary logs看待一些binlog的状态，其实会发现里面明显少了一类信息，那就是时间戳，有了时间戳的信息，其实是很容易鉴别出一些数据量的增长情况的，目前来看，要筛选不同时间段的binlog信息，只能通过系统层面来看了。

• 优化器比较薄弱

优化器的部分是MySQL近些年改进的一个重点，相比于原来确实改进了不少了。不过相比来说，还是比较脆弱的，新一些的版本有了一些新增的hints。

• server_id太死板

MySQL的server_id配置其实限制蛮大，需要指定格式，并在长度范围以内，如果能够支持类似域名的方式或者更具有系统属性的值对于server_id的管理会更加清晰，所以除非一些大厂会明确的定义server_id的算法，其实对很多公司的使用都是默认使用端口或者端口和IP的简单数据计算，通过结果要反推出原本的一些信息是很难的。

• 等待模型还处在初级阶段

MySQL监控层一直想做的一个指标是类似DB time的一个东西，这个指标的含义是能够标识数据库服务的整体负载量，因为目前通过业务巡检的建设，发现通过QPS,TPS，连接数，刷页频率等指标单一去统计是很难以去界定负载的一个整体情况的，而Oracle的设计思想是等待模型，在MySQL层面还在初步的建设阶段，我看好后期的sys schema，是一个很亮点的部分。

• 执行计划信息比较粗

MySQL的执行计划信息是比较简略的，相比于一些商业数据库的执行计划信息，会少很多的参考数据辅助，在分析问题的时候还是会有一些瓶颈。后期的一个改进是和JSON对接，在本身的信息采集和分析上还是有不小的空间。

• 统计信息粒度和直方图

直方图是对于执行计划输出信息的准确度的一个体现方式，这块在8.0有了这个特性，在统计信息的粒度上也可以持续发力。

• 数据增量刷新

如果要对MySQL表的数据做增量刷新，数据库层是本身不提供这样一套平滑的方案的，当然有其他第三方的方案或者是使用触发器等方式实现，在这个地方，MySQL的实现思路其实和Oracle不同，但是设计思路是类似的，都是空间换时间。

• mysql的redo用途改进

MySQL的redo对很多同学感觉是比较低调，它从来不会“出差”，只负责底层的数据写入，保证异常恢复，redo的使用在有些大公司有了明确的用途，对于数据复制还是大有帮助，物理的和逻辑的还是差别大了。

• 没有快照，问题诊断可参考信息太少

在性能优化的时候，总是会发现MySQL能够提供的原始信息比较少，如果监控信息不全面，我们是没法完全定位到一个指定时间段的负载明细，行业也有第三方的一些实现，不过效果还是很受限。