近期计划写一套书目，也就是关于mysql的优化的。那么首先在博客上写写，然后整理成pdf的文档的形式，当然也期待各位的关注了。对于mysql的优化是一个比較大的话题。可优化的地方也非常多，大致想了一下，能够从这些地方下手。
首先就是硬件层次，包含选择合适的操作系统、选择合适的硬件，然后就是源码层次，只是尽管mysql是开源的，可是可以改动其源码的公司尽管不少，可是也没有那么多，可是我们可以选择更加合适的编译器又一次编译其源码，然后就是设计到表的设计。也就数据库建模。
其次能够考虑使用一些其它技术，比方读写分离和分表技术，或者使用集群技术，这要求我们从总体上去构架。对于详细的内容，我们能够採用设置索引、优化sql查询语句、定期表修复、使用存储过程等等。
这里我们先说说数据库建模这部分，这部分往往和和业务逻辑有关系，通常来说新手都喜欢死扣第三范式或者BC范式。假设更要求完美，可能会死扣第五范式，事实上高手也都是这么一步步过来的，那么我们先介绍一下什么是第三范式。
第一范式就是对属性的原子性约束。也就是说表的列具有原子性，不能再次切割。它的约束性真的非常低。仅仅要数据库是关系型数据库，就会自己主动满足第一范式了，那么哪些可能会不满足第一范式呢？假设我们存储了一个集合。存储了一个数组。那么这就不满足第一范式了，可是对于关系型数据库。不可能出现这样的情况，我们无法向里面存储一个数组。注意，这里说的是存储了一个集合。而不是集合中的元素。
第二范式就是属性全然依赖于主键，举个样例，增加我们创建一个People表。它里面能够写一个字段是身份证号。那么由于每一个人的身份证号都不是不反复的，这个人的信息也会由这个人的身份证号唯一决定，这就能够能够理解为一个主键，这里的身份证号是主键，可是姓名并非主键。由于重名的情况还是挺多的。它的目的是为了防止数据的反复，因此我们使用一个主键来唯一的标识一条记录。
须要注意的是。主键并不一定必须是一个字段，比方说有时候两个信息才干确定一条记录，比方在一个目录以下的文件名称和后缀名这两个才干确定一个唯一的文件名称，我们分开来存放信息的话，这两个字段就构成了它的主键。值得注意的是，我们通经常使用一个数字类型的自增的id来作为主键。但它不是必须的。
第三范式的要求就更加苛刻了，它要求表中不要有冗余数据，那它的规范就是说：不论什么非主键的属性都必须依赖于主键，可是不能传递依赖于主键。
举个超经典的样例，这也是我在学习第三范式的时候的样例。由于它太经典了，我可能一辈子都忘记不了。比方说我建立了一个表。它的字段信息例如以下：（学号。学生姓名，学生所在系名。学生所在系的地址）,猛一看这个表也没什么问题。可是它会产生冗余信息。那就是学生所在系的地址这一个属性也是由学号唯一确定的，可是它不是直接依赖的。它是传递依赖的，它直接依赖与系名，而不是学生的学号，因此，我们会发现，对于不同的学号，会导致存储非常多一样的系名，这就是所谓的冗余信息。
那么我们怎么改动呢，答案就是分表。注意。我们还必须遵循第二范式，我们能够添加一个系的编号这么一个字段。即第一个表信息（学号，学生姓名，所在系编号）。第二个表（系编号。系名，系的地址），这么一来，我们就不会存储冗余信息了，这就是第三范式所带来的效果。
除了第三范式之外，另一个也非常重要，叫做BC范式，也就是著名的巴斯-科德范式，它的要求是什么呢？它是对主键的要求，也就是主码，它要求，主码的不论什么一个真自己都不能唯一的确定这个主码，什么意思。比方说我把学生的身份证号和学号这两个合起来 设计为主键，它并不违反第三范式，可是它违反了BC范式。原因何在呢？由于在一个学校里，不论什么两个学生的身份证号和学号都不同样，也就是说，我们使用学号作为主键或者身份证号作为主键都能够，可是使用这两个一起作为主键，不是必需。
我不知道读者是否晕了，大体思路就是这样。事实上这些范式都是人做出来的。也不难理解。我这里并没有引入太多的逻辑符合和专业术语。算是用比較寻常的语言来叙述，也是希望更好理解，假设您有什么问题，能够在以下留言给我。