能够看懂MySQL源码是一种怎么样的体验？

首先mysql是c++开发的。 github地址：https://github.com/mysql/mysql-server很多大型软件基本都是c/c++开发的。你会了c/c++基本就具备了领略程序世界的大门的钥匙。 mysql是一个完善的数据库软件。最上层：处理连接，授权认证，安全等 第二层：核心服务功能：查询解析，分析，优化，缓存以及所有内置函数（日期，时间，数据，加密等），存储过程，触发器，视图等。 第三层：存储引擎，存储引擎负责mysql中数据的存储和提取。每个引擎各有优势。服务器通过API与存储引擎进行通信。接口屏蔽了不同引擎的差异，对上层的查询过程透明。 你如果去读它，你基本就可以深入到这些业务点中。然后获取的提升绝对不是一星半点。你会发现开发一个web应用，开发一个中间件如此简单。你获取的是大神级工程师的开发思想，技巧。 举个例子：MVCC ，innodb 隔离性实现的技术。 设计原理很简单，也很巧妙。对数据安全和高并发做了平衡处理。 这个是单纯学习计算机语言，算法数据结构给不了的体验。 当前，你得能看的下去，你有那个恒心。吹牛逼就不要在这里问了？首先，能看懂 MySQL 源码的人物，我感觉肯定在技术上是一位大牛，能够将 C/C++ 语言的 MySQL 源码看懂，肯定也是一位非常有耐心的技术人，能够耐着性子去专研。 如果能够将Mysql源码研究的很透彻的话，我相信出去到大厂找数据库内核开发的岗位时，绝对是一个非常巨大的优势。能看懂 Mysql 的源码，首先第一点需要对 C/C++ 语言的知识点非常的熟悉，因为 MySQL 底层几乎都是 C/C++ 语言写的，比如指针等。 对于 MySQL 源码能够看得的话，我相信在和别人谈论数据库相关的问题时，其实也会更加有专业性和深度，能够快速的理解对方所说的数据库问题。同时，如果对 MySQL 源码有着很深入了解的话，其实对于数据库的相关配置优化等也会掌握的更好，因为你对底层原理了解的很透彻，对于自己做的每一件事情都是有理有据。每个数据库参数是什么含义，为什么要这样设置，背后都有你自己的理解和原因。这对于公司来说，也是非常需要这样的人才。当初我校招的时候，其实准备想投数据库开发相关的岗位，当时其实自己也自学过 MySQL 底层的原理（不过我没有去研究过源码）。 MySQL 最主要的还是底层可插拔式的存储引擎，比如 InnoDB、MYISAM等，重点是 InnoDB存储引擎。学习看 MySQL 源码的话，我建议可以选择其中一个模块开始入手。我刚开始看 《MySQL 技术内幕：InnoDB存储引擎》 这本书的时候，上面讲解的非常多的 MySQL InnoDB 的原理。先从原理知识入手，再去看源码会更加好一些，因为你掌握了整体的代码逻辑方向。说实话直接上手看 MySQL 源码，将会是很难的一件事情。我相信那些能够看懂 MySQL 源码的人，肯定在看源码之前，有一定的技术知识储备。新同学在去研究某一门开源技术组件的源码时，不建议直接上手去看代码，你应该是先去整体了解一下该技术组件的整体原理和框架，源码层则是更加细节方面的实现，你应该带着某一个问题去看，有针对性和目的性的去看源码，这样你的提升才会更加的快速。 我会持续大数据、数据库方面的内容，如果你有任何问题，也欢迎关注私信我，我会认真解答每一个问题。期待您的关注阅读代码，一般都是一件繁复的工作。程序员，只要工作需要、或有足够的时间，都能够胜任阅读代码的工作，特别是数据库这类功能具体的系统。如果软件的功能不确定，阅读起来确实有莫名的困难。年轻时，得到“一套”Z80汇编码，闲来无聊，尝试阅读，数周过去，不得要领。直到在一个忽略了的简单文档的阐述上下文中，意识到代码可能是实现“导d”稳定飞行的侧滚控制系统时，阅读中的问题瞬间都消失了。 拜托啦，我不只能看懂你的SQL，我还可以看懂VB、C++、数据库我也看

业务表tb_image部分数据如下所示，其中id唯一，image_no不唯一。image_no表示每个文件的编号，每个文件在业务系统中会生成若干个文件，每个文件的唯一ID就是字段id：

业务表tb_image的一些情况如下：

根据上面对业务的分析，分库分表完全没有必要。单库分表的话，由于要根据image_no和id查询，所以，一种方案是冗余分表（即一份数据以image_no为分片键保存，另一份数据以id为分片键保存）；另一种方案是只以image_no为分片键，而基于id的查询需求，业务层进行结果归并或者引入第三方中间件。

考虑到单库分表比较复杂，所以决定使用分区特性，而且容量评估分区表方案128个分区（每个分区数据量kw级别）完全能保证业务至少稳定运行15年（图中橙色部分是比较贴合自身业务实际增长情况）：

另外，由于RANGE, LIST, HASH分区都不支持VARCHAR列，所以决定采用KEY分区，官方介绍它的原理是以MySQL内置hash算法然后对分区数取模。

选定分片键为image_no，并且决定分区数为128后，就要灌入数据进行可行性和性能测试了。分区数选择128的原因是：11亿/1kw=110≈128，另外程序员情节，喜欢用2的N次方，你懂的。然而， 这个分区数128就是一切噩梦的开始 。

我尝试先插入10w数据到128个分区中，插入后，让我惊讶的现象出现了： 所有奇数编号分区（p1, p3, p5, ... , p2n-1）中居然没有一条数据 ，同时，任何一个偶数编号分区却有很多的数据，而且还不是很均匀。如下图所示：

说明 ：奇数编号分区的ibd文件大小都是112k，这是创建分区表时初始化大小，实际并没有任何数据。我们可以通过SQL： select partition_name, partition_expression, table_rows from information_schema.partitions where table_schema = schema() and table_name='image_subpart'验证，其部分结果如下图所示：

难道10w条数据还不够说明问题？平均下来每个分区可是有近800条数据！好吧，来点猛的：我再插入990w条数据，总计1kw数据。结果还是一样，奇数编号分区没有数据，偶数编号都有分区。

我们再来回想一下KEY分区的原理： 通过MySQL内置hash算法对分片键计算hash值后再对分区数取模 。这个原理也可以从MySQL官网找到，请戳链接： 22.2.5 KEY Partitioning: https://dev.mysql.com/doc/refman/5.7/en/partitioning-key.html ，截取原文如下：

这个世界上不会有这么渣渣的hash算法吧？ 随便写个什么算法也不至于这么不均匀吧？这时候我怀疑是否有一些什么配置引起的。但是 show variables 中并没有任何与partition相关的变量。

这个时候，一万匹马奔腾而过。会不会是文档和源码不同步导致的？好吧，看MySQL的源码，毕竟， 源码才是最接近真相的地方 。KEY分区相关源码在文件 sql_partition.cc 中，笔者截取部分关键源码，如下所示，初略观察，并没有什么不妥，先计算分区字段的hash值然后对分区数取模：

怀着绝望的心情，请出搜索引擎搜索："KEY分区数据不均匀"，搜索结果中的CSDN论坛（ https://bbs.csdn.net/topics/390857704 ）里有个民间高手 华夏小卒 回答如下：

这个时候，又是一万匹马奔腾而过。不过F**K的同时，心里也是有点小激动，因为可能找到解决办法了（虽然还不知道MySQL内置hash算法为毛会这样），最后笔者再次对KEY分区测试并总结如下：

如下图所示，是笔者把分区数调整为127并插入100w数据后的情况，通过SQL证明每个分区的数据量几乎一样：

MySQL的KEY分区这么大的使用陷阱，居然在官方上没有任何说明，这让笔者感到非常震惊。笔者还尝试Google搜索 mysql partition key uneven ，也有很多结果，例如 stackoverflow：https://stackoverflow.com/questions/38454354/mysql-uneven-distribution-of-data-into-partitions-when-using-key-partitioning ，此外还有MySQL bug： Bug #72428 Partition by KEY() results in uneven data distribution

正在看此文并有很强烈兴趣的同学，可以尝试更深入这个问题。笔者接下来也会找个时间，根据MySQL源码深入挖掘其hash算法的实现为什么对分区数如此敏感。

华为彭立勋是湖南衡阳人。彭立勋并非一开始就对MySQL数据库感兴趣，他是在机缘巧合下接触MySQL，进而自学研究，从做DBA（数据库管理员）开始，然后做DA（数据库架构师），再到做内核研发、内核架构工作，经过刻苦钻研，最终成为MySQL领域大牛。

彭立勋有着光鲜亮丽的履历，他曾荣获Oracle ACE Director(for MySQL) 的极高荣誉（Oracle ACE是Oracle授予Oracle公司之外的技术人员的荣誉称号，目前MySQL领域的ACED全球仅有5人）。社区贡献方面也极具影响力，他是为数不多的 MySQL 源码贡献者，并积极参与了 ACMUG（MySQL 中国用户组）的发起和组建，担任该组织的副主席及杭州地区的组织者。同时作为MariaDB 基金会第一位亚太成员，他是国内唯一的MariaDB提交组成员，向官方提交了 Multi-Source Replication，Thread Memory Usage Monitor 等功能补丁，并积极推进MySQL/MariaDB在中国的普及。

谈及MariaDB，彭立勋还分享了自己与MySQL之父、MariaDB 公司创始人兼 CTO Michael Widenius（又名Monty）的一段不解之缘。有一天他收到一封标题为<Can we use your MySQL patches in MariaDB>的邮件，发件人竟然是MySQL之父Monty。Monty在网上看到了他开源出来的一些补丁，希望他能够授权自己合并到主干。Monty称“这些Patch的想法quite impressed（印象深刻），其中几个补丁的实现思路how talented（很有才华）”。这对一个刚毕业工作两年的新人来说，非常受鼓舞，也坚定了彭立勋一直在MySQL领域继续深入工作下去的决心。

---