本文是《深入浅出MySQL--数据库开发、优化与管理维护》的读书笔记，其中也包含了我自己的一些理解，不一定全对，先记录下来再说。
最近做新项目，使用MySQL作为数据库，之前只有Oracle的使用经验。刚开始使用MySQL的时候，感觉十分不习惯，现在回想起来，如果项目刚启动时可以读到这本书，想必我会轻松许多。

数据类型的选择

数据库里的数据最终需要持久化到硬盘上，而硬盘的I/O效率通常都比较低，那么提高I/O效率可以有效的改善应用的性能表现。虽然硬盘价格很低，但考虑到I/O效率，存储数据时务必要依据业务需求，寻求占用空间最省的方式来保存数据，以期提高I/O的效率。

• 对于字符串，要根据存储引擎来进行选择。如果使用InnoDB，则推荐使用varchar，效率未必会比char低。
• 对于精度要求比较高的应用，建议使用定点数来保存数值，另外从编程的角度来看，对精度有要求的业务，应当避免使用浮点类型。
• 对于含有TEXT或者BLOB的表来说，如果经常会做删除和修改操作，则建议经常使用optimize table命令来对表做碎片处理，优化存储；另外，假如TEXT或者BLOB字段不经常被检索，从优化I/O效率的角度考虑，可以把对应字段抽取出来，用单独的表来存储数据。
• 日期类型要根据实际需要选择能够满足应用的最小存储的日期类型。DATETIME和TIMESTAMP相比，都可以存储年、月、日、时、分、秒，但DATETIME表示的范围比较大，而TIMESTAMP可以支持时区，各有所长。

字符集

MySQL的字符集包含字符集（CHARACTER）和校对规则（COLLATION）两个概念。字符集用来定义MySQL存储字符串的方式，校对规则则定义了字符串比较的方式；字符集和校对规则是一对多的关系，即一种字符集可以支持多种校对规则。
校对规则的命名方式，以字符集的名称开头，以_ci/_cs/_bin结束，_ci表示大小写不敏感，_cs表示大小写敏感，_bin表示基于字符编码的值来比较、与存储的语言自身无关。比如对于字符集utf8，对应的校验规则有utf8_ci、utf8_cs、utf8_bin。
MySQL数据实例可以在服务器级别、数据库级别、表级和字段级设置字符集和校对规则，作用范围不同。
注意点：

• 从已有经验看，使用utf8作为默认的字符集，开发过程会比较轻松加愉快，因为这样可以简单的搞定中文和英文。
• 修改已存在的数据库、表的字符集或者校对规则时，不会对已存在的数据产生影响。如果系统运行一段时间之后期望调整字符集和校验规则，同时期望修正已有的数据，那么需要将数据导出，调整字符集之后重新导入数据库实例。
• 应用和MySQL通信时，当前MySQL提供了三个参数来控制字符集，character_set_client、character_set_connection、character_set_results，三者如无明确设置，一般是一样的；三者假如不同，写入的数据和最终读出的数据可能会存在差异，因此开发过程中应当避免设置这三个参数。

索引的设计和使用

索引用于快速找到在某个列中有一特定值的行，如果没有索引，那么就需要从第一行开始、到最后一行结束，遍历表的全部记录才能提到相关行，那么I/O的代价就太高，效率低就是自然了。
设计索引或者创建索引的原则

• 索引可以有效的提升查询数据的效率，但索引数量不是多多益善，索引越多，维护索引的代价自然也就水涨船高。对于插入、更新、删除等DML操作比较频繁的表来说，索引过多，会引入相当高的维护代价，降低DML操作的效率，增加相应操作的时间消耗。另外索引过多的话，MySQL也会犯选择困难病，虽然最终仍然会找到一个可用的索引，但无疑提高了选择的代价。
• 索引字段的选择，最佳候选列应当从where子句的条件中提取，如果where子句中的组合比较多，那么应当挑选最常用、过滤效果最好的列的组合。
• 使用唯一索引，区分度越高，使用索引的效率越高。
• 使用短索引，索引创建之后也是使用硬盘来存储的，因此提升索引访问的I/O效率，也可以提升总体的访问效率。假如构成索引的字段总长度比较短，那么在给定大小的存储块内可以存储更多的索引值，相应的可以有效的提升MySQL访问索引的I/O效率。
• 利用最左前缀，N个列组合而成的组合索引，那么相当于是创建了N个索引，如果查询时where子句中使用了组成该索引的前几个字段，那么这条查询SQL可以利用组合索引来提升查询效率。

Hash索引的特点

• 只能作=或者!=/<>的比较。
• 优化器无法使用索引来加速order by操作。
• 无法确定两个值之间有多少行。
• 使用关键字检索时，一次只能检索到一行。

如果觉得不好理解的话，对照java.util.HashMap的使用方法就好懂了。
BTree索引可以使用的操作符相对要多一些，比如可以使用>、=、<=、between、!=或者<>、like，相应的适用范围会广一些；在特定场景下，相比于Hash索引，效率会有所损失。

视图的使用

相比于普通的表，视图的优势

• 简单，使用视图的用户完全不需要关注视图背后的表的结构、关联条件和筛选条件，站在视图定义者的角度来看，用户访问到的是过滤好的结果集。
• 安全，通过视图可以方便的控制用户可以访问到的行与列的集合，但普通的表则无法做到。
• 数据独立，或者可维护性好，通过提供视图，开发者可以屏蔽表结构、表名对用户的影响，相关的变动不会影响到视图的用户。

不过视图也有缺点，比如对视图返回的结果集做过滤时，无法使用索引，假如视图返回的结果集比较大，而需要的结果集比较小时，查询的效率其实是比较低的。
我印象里，通过视图是不允许修改数据的，但现在这个观念要改改了。通过使用MySQL和Oracle提供的视图是可以修改原表中的数据的，只不过有些限制，使用时需要详细阅读官方文档。我平日的工作里，视图都很少用到，所以这部分资料看看就过了，假如以后有机会用的话，那时再来仔细研究也不迟。

锁定语句

使用mysqldump命令导出数据时，会发现lock table和unlock table的命令，这不同于Oracle，初次看到时感觉蛮还蛮神秘的。
lock table，用来锁定当前线程使用的表，如果表被其它线程锁定，则当前线程将会等待；同一线程中重复执行lock table会使用前一次锁定的表被释放锁定。
unlock table，用来释放当前线程获得到的任何锁定；与DB的通信连接对象关闭时，当前线程中锁定的表将会自动释放锁定。
使用lock table和unlock table的意义在哪里？大批量数据短时间内加载至表内时，为了减少冲突，提高效率，这应该是一种场景，其它场景我暂时还想不到。

事务控制

MySQL提供了set autocommit、start transaction、commit和rollback等命令来实现事务的控制。

• start transaction或者begin用来开启新的事务。
• commit和rollback用来提交或者回滚事务。
• set autocommit可以修改当前连接的提交方式。

Oracle只需要设置set autocommit，即可以用手动方式控制事务，但MySQL可能会有所不同，需要在办公室尝试下。
分布式事务，目前还没有用到过，待后续有机会使用的时候再仔细阅读资料。

SQL Mode

相比于Oracle，这个东东是MySQL独有的特性。应该兼顾数据库移植性、性能和效率、开发正确性和业务场景几方面考虑，选择合适的模式。

分区

分区表是一个非常强大的特性，利用这个特性，可以带来如下好处

• 透明的管理存储有海量数据的大表，由数据库来管理对不同分区的访问，使用者完全不必关心。
• 可以有效的提升数据的访问效率和吞吐量，对不同分区的访问可以并发进行，互不影响。
• 简化表的管理，当部分分区的数据不需要时，可以通过删除相关的分区来快速清理数据，而不必使用传统的delete语句，引入不必要的复杂性。
• 。。。

之前的项目使用Oracle来存储数据，应用了Oracle的分区技术；现在的项目由于数据量及业务复杂度的原因，暂时还没有应用MySQL的分区，所以没有什么使用经验可以分享。