最近计划写一套书目，也就是关于mysql的优化的，那么首先在博客上写写，然后整理成pdf的文档的形式，当然也期待各位的关注了。对于mysql的优化是一个比较大的话题，可优化的地方也很多，大致想了一下，可以从这些地方下手。

首先就是硬件层次，包括选择合适的操作系统、选择合适的硬件，然后就是源码层次，不过虽然mysql是开源的，但是能够修改其源代码的公司虽然不少，但是也没有那么多，但是我们可以选择更加合适的编译器重新编译其源代码，然后就是设计到表的设计，也就数据库建模。

其次可以考虑使用一些其他技术，比如读写分离和分表技术，或者使用集群技术，这要求我们从整体上去构架。对于具体的内容，我们可以采用设置索引、优化sql查询语句、定期表修复、使用存储过程等等。

这里我们先说说数据库建模这部分，这部分往往和和业务逻辑有关系，通常来说新手都喜欢死扣第三范式或者BC范式，如果更要求完美，可能会死扣第五范式，其实高手也都是这么一步步过来的，那么我们先介绍一下什么是第三范式。

第一范式就是对属性的原子性约束，也就是说表的列具有原子性，不能再次分割，它的约束性真的很低，只要数据库是关系型数据库，就会自动满足第一范式了，那么哪些可能会不满足第一范式呢？如果我们存储了一个集合，存储了一个数组，那么这就不满足第一范式了，但是对于关系型数据库，不可能出现这种情况，我们无法向里面存储一个数组。注意，这里说的是存储了一个集合，而不是集合中的元素。

第二范式就是属性完全依赖于主键，举个例子，加入我们创建一个People表，它里面可以写一个字段是身份证号，那么由于每个人的身份证号都不是不重复的，这个人的信息也会由这个人的身份证号唯一决定，这就可以可以理解为一个主键，这里的身份证号是主键，但是姓名并不是主键，因为重名的情况还是挺多的。它的目的是为了防止数据的重复，因此我们使用一个主键来唯一的标识一条记录。需要注意的是，主键并不一定必须是一个字段，比如说有时候两个信息才能确定一条记录，比如在一个文件夹下面的文件名和后缀名这两个才能确定一个唯一的文件名，我们分开来存放信息的话，这两个字段就构成了它的主键。值得注意的是，我们通常用一个数字类型的自增的id来作为主键，但它不是必须的。

第三范式的要求就更加苛刻了，它要求表中不要有冗余数据，那它的规范就是说：任何非主键的属性都必须依赖于主键，但是不能传递依赖于主键。举个超经典的例子，这也是我在学习第三范式的时候的例子，因为它太经典了，我可能一辈子都忘记不了。比如说我建立了一个表，它的字段信息如下：（学号，学生姓名，学生所在系名，学生所在系的地址）,猛一看这个表也没什么问题，但是它会产生冗余信息，那就是学生所在系的地址这一个属性也是由学号唯一确定的，但是它不是直接依赖的，它是传递依赖的，它直接依赖与系名，而不是学生的学号，因此，我们会发现，对于不同的学号，会导致存储很多一样的系名，这就是所谓的冗余信息。

那么我们怎么修改呢，答案就是分表，注意，我们还必须遵循第二范式，我们可以增加一个系的编号这么一个字段，即第一个表信息（学号，学生姓名，所在系编号），第二个表（系编号，系名，系的地址），这么一来，我们就不会存储冗余信息了，这就是第三范式所带来的效果。

除了第三范式之外，还有一个也很重要，叫做BC范式，也就是著名的巴斯-科德范式，它的要求是什么呢？它是对主键的要求，也就是主码，它要求，主码的任何一个真自己都不能唯一的确定这个主码，什么意思。比如说我把学生的身份证号和学号这两个合起来 设计为主键，它并不违反第三范式，但是它违反了BC范式，原因何在呢？因为在一个学校里，任何两个学生的身份证号和学号都不相同，也就是说，我们使用学号作为主键或者身份证号作为主键都可以，但是使用这两个一起作为主键，没必要。

我不知道读者是否晕了，大体思路就是这样，其实这些范式都是人做出来的，也不难理解，我这里并没有引入太多的逻辑符合和专业术语，算是用比较平常的语言来叙述，也是希望更好理解，如果您有什么问题，可以在下面留言给我。